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.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
In a world of containers and stateless applications, fuck SQLite.
You can always use sqlite cloud
/s?
… 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.
If you don’t care about persistence, why are you even using a DB in the first place?
Just learn how to configure your containers.
Please teach me how to configure my containers so SQLite can scale horizontally.
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.
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.
You misunderstood. I’m not talking about scaling the DB horizontally, I’m talking about scaling the application using the DB horizontally.