Hacker News Reader

Comment by jl6 | Hacker News Reader

Here’s an algorithm which I believe to be 95% accurate:

If only a single user/device needs to access the data: use SQLite. In all other cases: use PostgreSQL.

Not sure how much sarcasm is built into your statement but as a long time user & supporter of Postgres I have to disagree. Postgres is fantastic at many things but there are times when it's not the best choice. An example would be high-scale OLAP. I've tried to use PG for those cases but ingesting thousands+ of events per second into PG and then trying to perform rollups on them in an online capacity (near real-time availability) requires a TON of extra legwork to get it going and near continuous maintenance thereafter. Other purpose-built DB's for OLAP such as Druid, Clickhouse, etc are much better suited for this type of use-case. The main advantage these systems have over Postgres is their column-oriented nature vs. row-oriented of PG and other RDMS.

> Postgres is fantastic at many things but there are times when it's not the best choice.

To be fair, that would be the 5% :).

Glib perhaps but no sarcasm intended. I do agree that there are use cases where PG loses out to more specialized tools, but that’s the 5%, and if you are in that zone you probably know you are and are likely to be capable of doing your own more robust evaluation.

on the similar MS stack of SQL Server it breaks down hard when you start trying to max its throughput. You have to start tearing down all the features, turning off indexes, foreign keys, etc. Otherwise what could take hours will take days or even weeks.

If provisioning and maintaining MS SQL Server is more of a happy path for your IT department, that's not a bad choice either.

At Amazon level you start needing specialized databases. For most other people Postgres is fine.

Reply on news.ycombinator.com