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

71–80 of 349 posts

Re: It's 2026, Just Use Postgres

#71

Post by furyofantares »

ddtaylor wrote: post #45
tallytarik wrote: post #26

Earlier quoted context omitted.

Yes this is clearly verbatim output from an LLM. But it's perfect HN bait, really. The title is spicy enough that folks will comment without reading the article (more so than usual), and so it survives a bit longer before being flagged as slop.

Is HN guidelines to flag AI content? I am unsure of how flagging for this is supposed to work on HN and have only ever used the flag feature for obvious spam or scams.

It might be wrong, but I have started flagging this shit daily. Garbage articles that waste my time as a person who comes on here to find good articles.

I understand that reading the title and probably skimming the article makes it a good jumping off point for a comment thread. I do like the HN comments but I don't want it to be just some forum of curious tech folks, I want it to be a place I find interesting content too.

Re: It's 2026, Just Use Postgres

#72

Post by PunchyHamster »

saisrirampur wrote: post #67
pimlottc wrote: post #59

Earlier quoted context omitted.

I took it to mean “make Postgres your default choice”, not “always use Postgres no matter what”

I personally see a difference between “just use Postgres” and “make Postgres your default choice.” The latter leaves room to evaluate alternatives when the workload calls for it, while the former does not. When that nuance gets lost, it can become misleading for teams that are hitting or even close to hitting—the limits of Postgres, who may continue tuning Postgres spending not only time but also significant $$. IMO…

The point is really that you can only evaluate which of alternatives is better once you have working product with data big enough - else it's just basically following trends and hoping your barely informed decision won't be wrong.

Re: It's 2026, Just Use Postgres

#73

Post by samuelknight »

dry_soup wrote: post #34
samuelknight wrote: post #17

Skeptical about replacing Redis with a table serialized to disk. The point of Redis is that it is in memory and you can smash it with hot path queries while taking a lot of load off the backing DB. Also that design requires a cron which means the table could fill disk between key purges.

From the article, using UNLOGGED tables puts them in memory, not on disk

I the article is wrong. UNLOGGED means it isn't written to WAL which means recovery and rollback guarantees won't work since the transaction can finish before the page can be synchronized on disk. The table loses integrity as a trade off for a faster write.

https://www.postgresql.org/docs/current/sql-createtable.html...

Re: It's 2026, Just Use Postgres

#74

Post by PunchyHamster »

mauritsd wrote: post #18

This kind of thing gets posted every couple of months. Databases like Pinecone and Redis are more cost-effective and capable for their special use case, often dramatically so. In some circumstances the situation favours solving the problem in Postgres rather than adding a database. But that should be evaluated on a case-by-case basis. For example, if you run something at scale and have an ops team the penalty of addi…

Once you have an app, a lot of data, and actual problems, it's far easier to pick the right alternative.

PostgreSQL is good enough to get to medium sized with nearly every use case. Once you are there, you have the use case and the test data to test any alternative for it well, rather than trying to guess beforehand what you actually need.

The advice is basically "PostgreSQL is probably good enough for whatever you're building now, and you should only look for other solution once you are big enough that it stops being that"

Re: It's 2026, Just Use Postgres

#75

Post by olavgg »

zzzeek wrote: post #24

Lots of familiar things here except for this UNLOGGED table as a cache thing. That's totally new to me. Has someone benched this approach against memcached and redis ? I'm extremely skeptical PGs query / protocol overheads are going to be competitive with memcached, but I'm making this up and have nothing to back it up.

Its not only about performance, Redis data structures offer an even more advanced caching and data processing. I even use Redis as a cache for ClickHouse.

Re: It's 2026, Just Use Postgres

#76

Post by jghn »

saisrirampur wrote: post #67
pimlottc wrote: post #59

Earlier quoted context omitted.

I took it to mean “make Postgres your default choice”, not “always use Postgres no matter what”

I personally see a difference between “just use Postgres” and “make Postgres your default choice.” The latter leaves room to evaluate alternatives when the workload calls for it, while the former does not. When that nuance gets lost, it can become misleading for teams that are hitting or even close to hitting—the limits of Postgres, who may continue tuning Postgres spending not only time but also significant $$. IMO…

I think that the key point being made by this crowd, of which I'm one, is somewhere in the middle. The way I mean it is "Make Postgres your default choice. Also *you* probably aren't doing anything special enough to warrant using something different".

In other words, there are people and situations where it makes sense to use something else. But most people believing they're in that category are wrong.

Re: It's 2026, Just Use Postgres

#78

Post by saisrirampur »

PunchyHamster wrote: post #72
saisrirampur wrote: post #67

Earlier quoted context omitted.

I personally see a difference between “just use Postgres” and “make Postgres your default choice.” The latter leaves room to evaluate alternatives when the workload calls for it, while the former does not. When that nuance gets lost, it can become misleading for teams that are hitting or even close to hitting—the limits of Postgres, who may continue tuning Postgres spending not only time but also significant $$. IMO…

The point is really that you can only evaluate which of alternatives is better once you have working product with data big enough - else it's just basically following trends and hoping your barely informed decision won't be wrong.

Agree to disagree here. I see a world where developers need to think about (reasonable) scale from day one, or at least very early. We’ve been seeing this play out at ClickHouse - the need for purpose-built OLAP is reducing from years to months. Also integration with ClickHouse is few weeks of effort for potentially significantly faster performance for analytics.

Re: It's 2026, Just Use Postgres

#79

Post by eikenberry »

otabdeveloper4 wrote: post #6

No thanks. In 2026 I want HA and replication out of the box without the insanity.

Came to say the same thing. Personally I'd only touch Postgres in a couple cases.

1. Downtime doesn't matter. 2. Paying someone else (eg. AWS) to manage redundancy and fail-over.

It just feels crazy to me that Postgres still doesn't have a native HA story since I last battled with this well over a decade ago.

Re: It's 2026, Just Use Postgres

#80

Post by irishcoffee »

bitwize wrote: post #68
kibibu wrote: post #15

Blog posts, like academic papers, should have to divulge how AI has been used to write them.

You're absolutely right! Let's delve into why blog posts like this highlight the conflict between the speed and convenience of AI and authentic human expression. Because it's not just about fears of hallucination—it's about ensuring the author's voice gets heard. Clearly. Completely. Unmistakably.

If nothing else, I sure got amusement from this.
Post reply on HN