undefined | Better HN

0 pointscrazygringo1mo ago0 comments

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.

0 comments

anonzzzies1mo ago

We 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.

riku_iki1mo ago

how did you handle HA/replication story with sqlite?

crazygringoOP1mo 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.

casey21mo ago

I'm glad we agree that "just use postgres" is horrible advice.

Would you except "Just use postgres for client-server" as a reasonable change?

j / k navigate · click thread line to collapse