• 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.