Hacker News Reader

Comment by anonzzzies | Hacker News Reader

It's 20xx just use sqlite. Almost no-one needs all that power; they sure do think they do, but really don't. And will never. SQLite + Duck is all you need even with a million visitors; when you need failover and scaling you need more, but that is a tiny fraction of all companies.

View on HN

Having built production apps on SQLite I can say it's not all sunshine and roses, the complexity explodes the moment you need multiple workers that can all write.

You better hope you dont have any big indexes or your writes will queue and you start getting "database is locked" errors. Good luck queueing writes properly at the application layer without rebuilding a full distributed queue system / network interface / query retry system on top of SQLite.

I really really really wish SQLite or PGLite supported multiple writers, especially if the queries are not even touching the same tables.

Oh I didn't say that, but nor is postgres. Use the right tool for the job I agree with, just people are making their lives difficult (expensive as well) by just blindly picking postgres.

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.

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.

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

how did you handle HA/replication story with sqlite?

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?

Reply on news.ycombinator.com