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

31–40 of 97 posts

Re: PostgreSQL is enough (2024)

#31

Post by AdieuToLogic »

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.

Re: PostgreSQL is enough (2024)

#32

Post by christophilus »

overflowy wrote: post #23

Moving business logic into database functions is the shortest path to insanity.

I agree with that. You can use Postgres as a message queue / task manager backing store without a database function, though, and it works quite well at the small scale that most sites / SaaS products operate at.

Re: PostgreSQL is enough (2024)

#33

Post by Joel_Mckay »

mikeocool wrote: post #19

I love Postgres. I buy using it for many many things. I really don’t understand why everyone insists that you should use it as a work/message queue. There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS). Your queue is likely to have very different access patterns than the rest of your data, and sticking it in Postgres means you’re probably going to end…

In some ways, Apache Kafka and RabbitMQ can help force better design choices.

A db can be performant, but at a certain point the global locks incremental primary keys create just strangle throughput. What makes a good db design normal form, is almost guaranteed to be inefficient at scale sooner or later. =3

Re: PostgreSQL is enough (2024)

#35

Post by a_conservative »

mikeocool wrote: post #19

I love Postgres. I buy using it for many many things. I really don’t understand why everyone insists that you should use it as a work/message queue. There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS). Your queue is likely to have very different access patterns than the rest of your data, and sticking it in Postgres means you’re probably going to end…

A few hundred jobs a day doesn't seem like it would even be close to what postgres could handle easily, does it?

I'm thinking of the problem as using a small amount of text to represent the work that needs to be done and then using a postgres table where some entries are being added as work that needs to be done, and then a worker is pulling the rows of work out of that table, and maybe putting a completion message somewhere in postgres. I'll concede that is more transient data than probably most of the other tables, it might benefit from vacuuming more often. Does the autovacuuming system not figure out it needs to run more often and do it?

Wouldn't the issue would be more overall queries per second, the amount of writes you're already doing, and the general load on the database. We just added some audit tables that are quickly growing to millions of rows, and it seems like Postgres isn't even breaking a sweat. I'm mostly spit balling here and probably glossing over some details.

But, like you said SQS is pretty easy too.

Re: PostgreSQL is enough (2024)

#36

Post by groundzeros2015 »

clncy wrote: post #30

While I love postgres, I take issue with coupling too much application logic to the DB. It’s much easier to update/rollback stateless containers/cloud functions/VMs than to recover a DB.

Why is it easier?

You don’t need to operate on the entire database. You can backup or roll back individual tables and schemas.

Re: PostgreSQL is enough (2024)

#38

Post by leoqa »

cyberax wrote: post #16
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.

HA is now pretty good on Postgres. As for scale... Just use a larger machine. This works for regular transactional data until you're at something like Amazon scale. Edit: Think about this, suppose that you store 1 megabyte of data for each of your customers. So if you have a million customers, it's just 1Tb. And these days, you can have a server with 10Tb RAM delivered overnight. Although you might have to sell your…

128Gb of RAM is like 1.5k

Re: PostgreSQL is enough (2024)

#39

Post by sgarland »

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…

As the sibling comment from eximius mentions, devs will routinely reach for these long before they’re remotely needed.

A well-tuned Postgres installation on fast hardware and intelligent schema design can scale incredibly far, even if you’re asking it to double as a message bus and full-text search tool.

Re: PostgreSQL is enough (2024)

#40

Post by LPisGood »

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.

Not everything needs to “scale.” I think needing scale is relatively rare, actually.
Post reply on HN