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

181–190 of 349 posts

Re: It's 2026, Just Use Postgres

#181

Post by tovlier »

vagab0nd wrote: post #155

I recently started digging into databases for the first time since college, and from a novice's perspective, postgres is absolutely magical. You can throw in 10M+ rows across twenty columns, spread over five tables, add some indices, and get sub-100ms queries for virtually anything you want. If something doesn't work, you just ask it for an analysis and immediately know what index to add or how to fix your query. It…

"sub-100ms queries" is not a high bar to clear. Milliseconds isn't even the right measurement.

Re: It's 2026, Just Use Postgres

#182

Post by SOLAR_FIELDS »

olivia-banks wrote: post #164
eek2121 wrote: post #152

Earlier quoted context omitted.

Standardizing on one single tiny little project is always a bad idea. Why? Some examples (which are admittedly not related to postgres, because I don't know their structure): 1) A single person, doing a ton of heavy lifting, leaves, or worse, turns it over, or silently sells out to a nefarious person. 2) A severe security vulnerability is found. If everyone is using postgres, everyone is vulnerable. Bonus points if t…

I'm not sure I would call either PostgreSQL or SQLite "tiny."

Op calling the de jure database solution (pg) in the world “tiny” is pretty laughable. It’s one of the most popular solutions for databases in general and RDBMS specifically. SQLite is also massive in terms of its adoption and use

Re: It's 2026, Just Use Postgres

#185

Post by SOLAR_FIELDS »

pimlottc wrote: post #59
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 took it to mean “make Postgres your default choice”, not “always use Postgres no matter what”

This is my philosophy. When the engineer comes to me and says that they want to use NotPostgres, they have to justify why, with data and benchmarks, Postgres is not good enough. And that’s how it should be

Re: It's 2026, Just Use Postgres

#186

Post by rendang »

johnfn wrote: post #174

This is just AI slop. The best tell is how much AI loves tables. Look at "The Hidden Costs Add Up", where it literally just repeats "1" in the second column and "7" in the third column. No human would ever write a table like that.

Agree. Very unprofessional and disrespectful to prospective customers to not even have a human edit your blog copy

Re: It's 2026, Just Use Postgres

#187

Post by rrdharan »

stock_toaster wrote: post #105
zemo wrote: post #60

Earlier quoted context omitted.

is there anything memcache gives you that a redis instance configured with an eviction policy of allkeys-lru doesn't give you

memcached is multithreaded, so it scales up better per node. memcached clients also frequently uses ketama consistent hashing, so it is much easier to do load/clustering, being much simpler than redis clustering (sentinel, etc). Mcrouter[1] is also great for scaling memcached. dragonfly, garnet, and pogocache are other alternatives too. [1]: https://github.com/facebook/mcrouter

Both Redis (finally) and Valkey addressed the multithreading scalability issues, see https://oneuptime.com/blog/post/2026-01-21-redis-vs-memcache... and/or https://news.ycombinator.com/item?id=43860273...

Re: It's 2026, Just Use Postgres

#188

Post by SOLAR_FIELDS »

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.

Postgres is widely used enough with enough engineering company blog posts that the vast majority of NotPostgres requests already have a blog post that either demonstrates that pg falls over at the scale that’s being planned for or it doesn’t.

If they don’t, the trade off for NotPostgres is such that it’s justifiable to force the engineer to run their own benchmarks before they are allowed to use NotPostgres

Re: It's 2026, Just Use Postgres

#189

Post by WorkerBee28474 »

antirez wrote: post #57
WorkerBee28474 wrote: post #21

Earlier quoted context omitted.

IIRC there was a pre-edit version with snark.

Yes, but the downvotes came later too, I edited it with the same exact content but without the asshole that is in me. Still downvotes received.

Delaying votes may be one of HN's anti-manipulation tactics.

Re: It's 2026, Just Use Postgres

#190

Post by cies »

No more ORMs, not even query builders, ... When it comes to Postgres I want to write the sql myself! There is so much value.

Supabase helps when building a webapp. But Postgres is the powerhouse.

Post reply on HN