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

It's 2026, Just Use Postgres

tigerdata.com

Post reply on HN
Print view View original

81–90 of 349 posts

Re: It's 2026, Just Use Postgres

#81

Post by PunchyHamster »

lucas1068 wrote: post #8

I've found that Postgres consumes (by default) more disk than, for example, MySQL. And the difference is quite significant. That means more money that I have to pay every month. But, sure Postgres seems like I system that integrates a lot of subsystems, that adds a lot of complexity too. I'm just marking the bad points because you mention the good points in the post. You're also trying to sell you service, which is g…

On flipside, restore from plain postgresql dump is much, much faster than plain mysql backup. There are alternative strategies for mysql but that's extra work

Re: It's 2026, Just Use Postgres

#82

Post by bluepuma77 »

Now we only need easy self-hosted Postgres clustering for HA. Postgres seems to need additional tooling. There is Patroni, which doesn't provide container images. There is Spilo, which provides Postgres images with Patroni, but they are not really maintained. There is a timescaledb-ha image with Patroni, but no documentation how to use it. It seems the only easy way for hosting a Postgres cluster is to use CloudNativePG, but that requires k8s.

It would be awesome to have easy clustering directly built-in. Similar to MongoDB, where you tell the primary instance to use a replica set, then simply connect two secondaries to primary, done.

Re: It's 2026, Just Use Postgres

#83

Post by riku_iki »

ddtaylor wrote: post #47
EvanAnderson wrote: post #27

Earlier quoted context omitted.

Some people do Postgres on compressed ZFS volumes to great success.

I am curious if you know anyone using Btrfs for this too. I like ZFS, but it Btrfs can do this it would be easier to use with some distros, etc. as it's supported in kernel.

I do it.

The big problem for me from running DB on Btrfs is that when I delete large dirs or files (100GB+), it locks disk system, and Db basically stop responding on any queries.

I am very surprised that FS which is considered prod grade having this issue..

Re: It's 2026, Just Use Postgres

#84

Post by cheriot »

saisrirampur wrote: post #55

I’m a huge Postgres fan. That said, I don’t agree with the blanket advice of “just use Postgres.” That stance often comes from folks who haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can create The argument, as in this blog, is that a single Postgres stack is simpler and reduces complexity. What’s often overlooked is the CAPEX and OPEX required to make Postgres work w…

> I don’t agree with the blanket advice of “just use Postgres.”

I take it as meaning use Postgres until there's a reason not to. ie build for the scale / growth rate you have not "how will this handle the 100 million users I dream of." A simpler tech stack will be simpler to iterate on.

Re: It's 2026, Just Use Postgres

#86

Post by LaGrange »

saisrirampur wrote: post #55

I’m a huge Postgres fan. That said, I don’t agree with the blanket advice of “just use Postgres.” That stance often comes from folks who haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can create The argument, as in this blog, is that a single Postgres stack is simpler and reduces complexity. What’s often overlooked is the CAPEX and OPEX required to make Postgres work w…

> At Citus Data, we saw many customers with solid-sized teams of Postgres experts whose primary job was constant tuning, operating, and essentially babysitting the system to keep it performing at scale.

Oh no, not a company hiring a team of specialist in a core technology you need! What next, paying them a good wage? C'mon, it's so much better to get a bunch of random, excuse me, "specialized" SaaS tools that will _surely_ not lead to requiring five teams of specialists in random technologies that will eventually be discontinued once Google acquires the company running them.

OK but seriously, yeah sometimes "specialized" is good, though much less rarely than people pretend it to be. Having specialists ain't bad, and I'd say is better than telling a random developer to become a specialist in some cloud tech and pretending you didn't just end up turning a - hopefully decent - developer into a poor DBA. Not to mention that a small team of Postgres specialists can maintain a truly stupendous amount of Postgres.

Re: It's 2026, Just Use Postgres

#88

Post by Fairburn »

saisrirampur wrote: post #55

I’m a huge Postgres fan. That said, I don’t agree with the blanket advice of “just use Postgres.” That stance often comes from folks who haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can create The argument, as in this blog, is that a single Postgres stack is simpler and reduces complexity. What’s often overlooked is the CAPEX and OPEX required to make Postgres work w…

Exactly. Use cases differ. https://www.geeksforgeeks.org/mysql/difference-between-mysql...

Re: It's 2026, Just Use Postgres

#89

Post by PunchyHamster »

antirez wrote: post #4

The point of Redis is data structures and algorithmic complexity of operations. If you use Redis well, you can't replace it with PostgreSQL. But I bet you can't replace memcached either for serious use cases.

well, redis is a bit of a junk bin of random barely related tools. It's just very likely that any project of non-trivial complexity will need at least some of them and I wouldn't necessarily advocate for trying jerry-rigging most of them in postgresql like the author of article, for example why would anyone want wasting their SQL DB server performance on KV lookups?

Re: It's 2026, Just Use Postgres

#90

Post by groundzeros2015 »

oldestofsports wrote: post #23

Caching is mentioned in the article: What do you guys feel about using PostgreSQL for caching instead of Redis? Redis is many times faster, so much that it doesn't seem comparable to me. A lot of data you can get away with just caching in-mem on each node, but when you have many nodes there are valid cases where you really want that distributed cache.

Materialized views work pretty well in Postgres. But yes at some level of load it’s just helpful to have the traffic shared elsewhere.

But As soon as you go outside Postgres you cannot guarantee consistent reads within a transaction.

That’s usually ok, but it’s a good enough reason to keep it in until you absolutely need to.

Post reply on HN