4 ms·
Most apps never need to scale. Also, worried about scaling? Just use an ORM that allows you to switch from SQLite to Postgres. It’s as simple as that.
by xray2 2y ago
Most apps never need to scale. Also, worried about scaling? Just use an ORM that allows you to switch from SQLite to Postgres. It’s as simple as that.
- mind-blight 2y agoUnless your using database specific features. One of the biggest advantages for Postgres is how incredible the ecosystem is. It doesn't work for everything, but I have an OEM, multiple kinds of text search (vector, inverted indexes, trigrams), recursive and graph-like queries (though that's admittedly less of an issue if n+1 isn't a problem), row-level acls, locks, etc. It's really nice to have all of that power available in one piece of infrastructure.
- victorbjorklund 2y agoNot really a problem if you go from sqlite to postgres. Which sqlite feature is missing from Postgres?
- cnity 2y agoThis is saying: "just don't try to solve hard data storage problems". Not all applications are CRUD.
- dns_snek 2y agoYou're missing the point. Most software doesn't need to scale or solve hard data storage problems, and if it ends up having to, you can always upgrade to Postgres with minimal effort. That makes SQLite an attractive option if you won't immediately benefit from Postgres' rich features.
- cnity 2y agoWe're just going to be speaking past each other, I think. GP clearly stated they lean heavily on Postgres technologies (by calling out specifics like pgvector). Stating that the applications that don't need those technologies, indeed don't need them, is tautological!
- SJC_Hacker 2y agoAll SQLite queries are not just going to straight up work in Postgres. e.g handling of dates is a big one. In SQLite they are just strings(kludgy IMO), where as Postgres has the timestamp data type.