Live data from Hacker News

Do you need separate systems when you already have Postgres?

postgresisenough.dev

41–50 of 90 posts

Re: Do you need separate systems when you already have Postgres?

#41

I'll do you one better: do you really need Postgres and all these extensions when you already have a filesystem? > only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative I love Postgres as a DB but, really, this is ridiculous. No doubt these extensions can do the job well-enough but you might as well invest in learning the right tool for t…

Filesystems aren't efficient for small bits of data.

Like right now I am thinking about a system that has a password reset process and you need to keep track of a user id and a reset token, one or two timestamps, maybe a state variable and a flag or two. That's well under 100 bytes and the cluster size for a typical fs is 4kb or more plus there is the cost of the directory entry. If the OS is Windows it has to ask the Security Manager when ever you open it or delete it which is even more heavyweight.

It's common now for applications that handle lots of little "files" to store them as blobs in SQLlite! See https://sqlite.org/fasterthanfs.html

Re: Do you need separate systems when you already have Postgres?

#42
post #13

I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of "use Postgres for everything" articles and they imply a difficulty in running other software that I just don't see. I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange g…

Yeah I've found this quite odd. Even the LLMs want to pressure you to not use Redis and go all in on Postgres. Postgres is great, and I usually use it. But Redis is so trivial to add to your stack and it does what it does really well. Why not use the right tool for the job?

because if you already have postgres, and dont need thousands of k/v per second, then postgres can do the same ?

Re: Do you need separate systems when you already have Postgres?

#43
post #38

Postgres sucks. It does a little bit of everything, but badly and with much manual intervention.

Wild statement, imo. There is no better open source database, so I'm very curious what you prefer and what your use cases are...

It's boring but the last thing you want is excitement over data that's important to your business!

All the eng. managers I've worked with in the last decade have sworn by Postgres, in the decade before that they were swearing at mongo and getting betrayed by Arangodb switching to a restrictive license and seeing other innovative databases going down the same path means for new side projects I go postgres.

Re: Do you need separate systems when you already have Postgres?

#44
For context, I am mainly talking about my personal projects, ideas I am trying out, MVPs/prototypes for potential new businesses, etc.

I have started just using Postgres to back queues. It is simpler (although I have spun up new apps with Redis so many times it is only a small improvement) but more importantly it is cheaper. I really do try a lot of stuff out, so completely removing a infrastructure piece is a nice money saver. Again, not massive but it's cheaper.

The downsides of doing this in the prototype/MVP context are minimal. At the scale of prototype and MVPs, I certainly don't see any difference in performance.

I did note in the graphic it listed Kafka but in the lower table graphic I did not see any Postgres replacement for Kafka. If I am at the scale where I really want Kafka, it is probably for performance and I just can't believe there's anyway Postgres could provide that.

So, I love the flexibility and all-in-one abilities of Postgres for prototyping and making MVPs. But at my job, nobody is proposing exclusively using Postgres for persistence.

Re: Do you need separate systems when you already have Postgres?

#45
post #13

I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of "use Postgres for everything" articles and they imply a difficulty in running other software that I just don't see. I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange g…

And Redis has auto-delete rows (aka TTL). In Postgres you need a cron job to clear stale rows.

Re: Do you need separate systems when you already have Postgres?

#46
post #42

Earlier quoted context omitted.

Yeah I've found this quite odd. Even the LLMs want to pressure you to not use Redis and go all in on Postgres. Postgres is great, and I usually use it. But Redis is so trivial to add to your stack and it does what it does really well. Why not use the right tool for the job?

because if you already have postgres, and dont need thousands of k/v per second, then postgres can do the same ?

If you're stressing your database, offloading some work to Redis can buy you a lot of Postgres headroom. But sure, start with YAGNI.

Re: Do you need separate systems when you already have Postgres?

#47

I'll do you one better: do you really need Postgres and all these extensions when you already have a filesystem? > only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative I love Postgres as a DB but, really, this is ridiculous. No doubt these extensions can do the job well-enough but you might as well invest in learning the right tool for t…

I don't understand why the answer is to always bloat the system with more specialized software and technical debt, instead of optimizing the existing system. If Postgres can truly handle all of these situations, then mastery of that one tool should be focused on.

I guess its more the rapid start-up mindset to get it up and running fast to sell the company, and leave the problem for someone else which is why a lot of our world is falling apart...

Re: Do you need separate systems when you already have Postgres?

#48

I'd love the ability to mark a table as "read committed" to prevent long running transactions from keeping old versions of a tuple alive, or even "read uncommitted" to enable in-place updates. Or perhaps instead of downgrading isolation, those serializable/snapshot transactions could simply fail when reading a value from such a table that was modified after they started. An example of a table that would benefit from…

Surely the last place you'd want to use those weaker consistency guarantees is a concurrency limiter?

The limiter itself should be able to ensure consistency via pessimistic row level locking, even at lower isolation levels.

What I don't want is long running unrelated transactions keeping old tuples alive just it case they're needed. My third suggestion where transactions attempting to read old versions fail is probably better than the first two where isolation gets silently downgraded, since it avoid that problem.

Re: Do you need separate systems when you already have Postgres?

#49

I love postgres, but the complexity of using it for everything starts to get pretty high, compared to more tailor-suited tools. We should probably use it for _more_, in general, but the cost of "everything in postgres" is generally higher than I see acknowledged in articles like these.

These specialized tools are likely the cause for the increased complexity within Postgres. I would imagine that if we had more individuals focused solely on Postgres, there would be more discussions, articles, and solutions for a lot of the problems "solved" by adding more tools to the problem.

Re: Do you need separate systems when you already have Postgres?

#50
Fun fact for people whose scaling plan anticipates moving from Postgres to CRDB:

SELECT FOR UPDATE SKIP LOCKED works great for turning Postgres into a job queue. It does not work the same way on CRDB and you will likely have to rewrite those queries or use an external job queue.

Post reply on HN