Comment by IshKebab
20 hours ago
The article talks about this. If you have a project that starts small and an in-process DB is fine, but you end up needing to scale up then you don't have to switch DBs.
20 hours ago
The article talks about this. If you have a project that starts small and an in-process DB is fine, but you end up needing to scale up then you don't have to switch DBs.
That's a valid, but very tiny, use case.
After all, if you can tell in advance that you might hit the limits of SQLite, you'd simply start with postgresql on day one, not with a new unproven DB vendor with a product that has been through the trial by fire of existing DBs.
So the usecase is: I started with SQLite, but now I have too many terrabytes to fit on one server? That seems.. very uncommon.
And since moving it out of process, and even to another network, is going to make it much much much slower. You're going to need a rewrite anyway
I think it's more like you started with SQLite and now you need concurrent writes, replication, sharding, etc. etc. - all the stuff that the "big" databases like PostgreSQL provide.
Thanks. Serves me right for commenting without reading the article.