4 ms·
Huh? SQLite is designed for application databases. Postgres is designed for client-server. It's not about "power" (what does that even mean?), it's about tot
by crazygringo 9mo ago
Huh?
SQLite is designed for application databases.
Postgres is designed for client-server.
It's not about "power" (what does that even mean?), it's about totally different design choices that are intended for different purposes. It's an architecture question, not a "power" or "visitors" question.
- anonzzzies 9mo agoWe run plenty of money making SaaS on sqlite without issues. And have been for over a decade. By power I meant all the complex features postgres has. But yes, it's an architecture question; my point being, most people pick many bulldozers while they need a 1 shovel.
- crazygringo 9mo ago> But yes, it's an architecture question; my point being, most people pick many bulldozers while they need a 1 shovel. Again, huh? Client-server vs locally embedded does not map to "many bulldozers vs 1 shovel". SQLite and Postgres aren't even really competitors. They serve extremely different use cases. I'm not aware that "most" people are picking Postgres when they "need" SQLite. What are you even basing this on? SQLite is already an extremely popular choice.
- riku_iki 9mo agohow did you handle HA/replication story with sqlite?
- casey2 9mo agoI'm glad we agree that "just use postgres" is horrible advice. Would you except "Just use postgres for client-server" as a reasonable change?