Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think "dead simple" is not doing anyone any favors when it is being used to try to equate the simplicity of things.

It's obviously a lot simpler to just have a file, than to have a server that needs to be connected to, as long as we're still talking about running things on regular computers.



I guess that's really my point here.

They difference in setup time is negligible so I'm not sure why people keep bringing it up as a reason to choose sqlite over PostgreSQL.

For instance, "deployable inside a customer application" is an actual requirement that would make me loath to pick PostgreSQL.

"Needs to be accessible, with redundancy, across multiple AWS zones" would make me very reluctant to pick sqlite.

Neither of these decisions involve how easy it is to set up.

It's like choosing between a sportbike and dump truck and focusing on how easy the sportbike is to haul around in the back of a pickup truck.


I'm not sure its neglibile, I suppose once you know what you're doing.

But postgres setup, at least the package managers on Linux, will by default, create a user called postgres, and lock out anyone else who isn't this user from doing anything. Yeah you can sudo to get psql etc. easily, but that doesn't help your programs which are running as different users. You have to edit a config file to get to work, and I never figured out how to get to work with domain sockets and not TCP


That's interesting... my experience (almost all on RHEL/CentOS/Fedora) is that it is trivial to have unix domain socket with local Postgres clients and a pain to setup any remote clients.

You just have to call the basic "createuser" CLI (or equivalent CREATE ROLE SQL) out of the postgres superuser account to create database users that match local Linux usernames. Then the ident-based authentication matches the client process username to the database role of the same name.


> Needs to be accessible, with redundancy, across multiple AWS zones

How many projects start with these requirements?


Anything with real customer data in the cloud? Certainly you need replication.


Litestream can handle realtime replication.

But most projects don’t even have customers when they start, let alone large quantities of their data and legal requirements for guaranteed availability.


I think it's reasonable for a business, even a freshly starting one, to expect to grow to the point where it does have enough customers to outgrow SQLite fairly soon. Between that and PG offering more features in general (which often simplifies app code, because you can do more with queries), it's still not clear why not start with PG in the first place.

PG, on the other hand, can scale enough to cover foreseeable future needs for most businesses, so aiming for something more complex than that is almost always premature.


> outgrow SQLite fairly soon

That would be the result of either vastly overestimating their business plan or vastly underestimating SQLite.


> How many projects start with these requirements?

In a world fueled by cheap money and expensive dreams, you'd be surprised.


I’m not counting on a cheap money future. Not near future at least.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: