Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL is enough (2024)

gist.github.com

Post reply on HN
Print view View original

41–50 of 97 posts

Re: PostgreSQL is enough (2024)

#41

Post by frollogaston »

Postgres as a relational DBMS is enough, a point worth making against people trying to abstract it away with stuff like ORMs.

Besides that, you usually won't need nosql thanks to jsonb, and other special types like in Postgis cover other use cases. SQL is better than dealing with various DSLs like you'd see for timeseries. Then there are things you may want separate tooling for but can also do in Postgres if you want to avoid more infra: pubsub/queues, search w/ pgvector, graph DBs, KV stores, caches.

A lot of the other examples here look ridiculous though, like no I'm not hosting a webserver on Postgres. Database functions should be used sparingly too. Never touched triggers since I normally have a general-purpose language driving DB changes, but could see why someone else might use them.

Re: PostgreSQL is enough (2024)

#42

Post by nine_k »

AdieuToLogic wrote: post #31

The first two linked resources: Simplify: move code into database functions Just Use Postgres for Everything Are disqualifying enough to not warrant further reading. A relational database is one form of persistent storage. They are great for managing persistent representations of key abstractions and their relationships. They are not application frameworks nor scalable messaging systems by design.

Did you see that implementation of Quake in CSS? Or Tetris in awk? You can do a similar thing with Postgres, and it will be much less insane. Should you run your entire app stack in Postgres? Likely not. Can you? Likely you can.

Re: PostgreSQL is enough (2024)

#43

Post by brianwawok »

SwellJoe wrote: post #13

I'd go further, and say that most of the time, "SQLite is enough". But, yes, PostgreSQL is all I ever use for anything that needs to be big. I ported a big old web app that had ScyllaDB, Elastic Search, Redis, and probably some other stuff I've forgotten. It got PostgreSQL+PostGIS (it's a mapping app), that's it. I'm sure there's some situation where it would be worth looking at all that other stuff, but it's ridicul…

Redis is basically free and nothing like the other tools you mentioned. Anytime I need a quick cache that will survive reboots it’s a winner. Agree on the other stuff though.

Re: PostgreSQL is enough (2024)

#44

Post by ronbenton »

I have worked some places where a significant amount of business logic lived in database functions and triggers and, hoo boy, that was really hard to reason about. If you're disciplined enough to have migrations around that implemented all that stuff, you're still going to have an unpleasant time piecing all of it together when debugging. But often you're in a state where you don't even have those breadcrumbs and you're pulling out your hair trying to figure out what's going on.

Re: PostgreSQL is enough (2024)

#45

Post by sgarland »

fastball wrote: post #5

> But the bar should be high: only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative Why do I need to push Postgres to its limits before using a different solution? Throwing a hosted Redis in front of some hot-path API calls is very straightforward and easier to reason about than materialized views or UNLOGGED tables.

Those examples are all equally difficult to reason about. Cache invalidation is equivalent to refreshing a materialized view, and UNLOGGED tables bring about new and exciting ways lose data.

Re: PostgreSQL is enough (2024)

#46

Post by frollogaston »

danpalmer wrote: post #21

Lots of the alternatives that this site claims Postgres will do are things you'd only consider well past the point that Postgres would be viable. Kafka? No one wants to operate Kafka, if it's a serious contender it's because you need things only it can do. Same with Elasticsearch, it sucks to operate, sucks to build a second stack just for search, so you'd only consider it at the point that Postgres is no longer suit…

Never used Kafka, mostly cause I've been afraid to learn something called Kafka.

Re: PostgreSQL is enough (2024)

#48

Post by nine_k »

anitil wrote: post #29
bitlad wrote: post #6

PostgreSQL is good enough until it's not good enough, when you realize all the bad design decisions that were made before it hits scale. It is the decisions people make around not partitioning, HA, replication that makes it not good enough.

I feel like any problem that Postgres can't handle is a good problem to have. Either you've got so many customers that you're hitting sharp edges, or you're working on such an interesting problem that you're out of the domain where Postgres is helpful. That I should be so lucky

A moderate-size queue is already a problem that Postgres struggles to handle %) But fortunately such problems are rare, and relatively well-known, like, say, doubly-linked lists in Rust.

For most other problems, Postgres works well, or at least well enough.

Re: PostgreSQL is enough (2024)

#49

Post by green_wheel »

busymom0 wrote: post #20
SwellJoe wrote: post #13

I'd go further, and say that most of the time, "SQLite is enough". But, yes, PostgreSQL is all I ever use for anything that needs to be big. I ported a big old web app that had ScyllaDB, Elastic Search, Redis, and probably some other stuff I've forgotten. It got PostgreSQL+PostGIS (it's a mapping app), that's it. I'm sure there's some situation where it would be worth looking at all that other stuff, but it's ridicul…

I recently built a site that aggregates top posts from various sources and am using both SQLite and Swift for my backend. Was a pleasant experience mostly. https://limereader.com/

Why'd you go with swift for the backend?

Re: PostgreSQL is enough (2024)

#50

Post by fastball »

sgarland wrote: post #45
fastball wrote: post #5

> But the bar should be high: only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative Why do I need to push Postgres to its limits before using a different solution? Throwing a hosted Redis in front of some hot-path API calls is very straightforward and easier to reason about than materialized views or UNLOGGED tables.

Those examples are all equally difficult to reason about. Cache invalidation is equivalent to refreshing a materialized view, and UNLOGGED tables bring about new and exciting ways lose data.

Cache invalidation on Redis is setting a TTL of 60s on the kv I just set, in a single atomic operation.
Post reply on HN