Comment by eterm
1 day ago
Or you can run postgres on the same machine as the application, which lets you much more easily migrate if the time comes when you need to scale to multiple application servers.
There's a world between "local file" and "network DB server", running a DB server locally has lots of benefits from being able to easily query from outside if needed to forcing you to consider concurrency without the latency overhead of a network hop.
This decision tree doesn't make much sense to me. Why you someone forego performance today in favor of adding a completely unnecessary network layer to every DB query in order to "satisfy" future imaginary "scaling concerns"?
Because you don't add a network layer by running a database locally.
That's still orders of magnitude more complexity for no real benefit. A migration from sqlite to postgres, if really required, is not that hard.
Yes, postgres should support a superset of SQLite functionality.
Now you've added a substantial dependency, and annoying setup requirements. Good luck doing this for a native app on mobile or desktop.
If someone is talking about "spinning up a separate machine" for Postgres, they're not talking about a desktop or mobile app...
Obviously SQLite is the best choice for a mobile or desktop app, that's not what's being discussed here.