• abhibeckert@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 year ago

      … you know you can put SQLite in a container right? It doesn’t even need to be persisted to disk - it can just live in RAM.

        • tgv@programming.dev
          link
          fedilink
          English
          arrow-up
          5
          arrow-down
          1
          ·
          1 year ago

          Are you Larry Ellison? Because then your remarks would suddenly make sense.

          It’s really simple: if you can’t avoid spreading your database over many machines, sqlite is not the tool to use. Pick another one. Even if you can run it on a single server, but need authorized network access from multiple backends, it’s not for you (although there are some services built around sqlite that might help). Pick something else. But don’t hate a perfectly fine, well defined tool for existing.

        • nothacking@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 year ago

          Other databases have the same issue, try having multiple database containers (without massive speed losses). If application is bound by the performance of the front end, this is a problem, but those really are not what SQLite was intended for.

          In the case of database bound applications, SQLite is just as good as any other database, which despite having a client server model can typically only handle a single operation at once.

          • Obsession@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            1
            arrow-down
            1
            ·
            1 year ago

            You misunderstood. I’m not talking about scaling the DB horizontally, I’m talking about scaling the application using the DB horizontally.