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

211–220 of 349 posts

Re: It's 2026, Just Use Postgres

#211

Post by spudlyo »

dimgl wrote: post #87

I've actually started moving away from Postgres to MySQL and SQLite. I don't want to have to deal with the vacuums/maintenance/footguns.

I have a lot of respect for Postgres' massive feature set, and how easy it is to immediately put to use, but I don't care for the care and feeding of it, especially dealing with upgrades, vacuuming, and maintaining replication chains.

Once upon a time, logical replication wasn't a thing, and upgrading major versions was a nightmare, as all databases in the chain had to be on the same major version. Upgrading big databases took days because you had to dump and restore. The MVCC bloat and VACCUM problem was such a pain in the ass, whereas with MySQL I rarely had any problems with InnoDB purge threads not able to keep up with garbage collecting historical row versions.

Lots of these problems are mitigated now, but the scars still sometimes itch.

Re: It's 2026, Just Use Postgres

#213

Post by rzerowan »

dimgl wrote: post #87

I've actually started moving away from Postgres to MySQL and SQLite. I don't want to have to deal with the vacuums/maintenance/footguns.

Major change for us to replace postgresql was replication and HA across geographies - i think on the Postgres side greenplum and cockroachdb are/were an option.

With MySQl variants like percona xtradb setup can go from 1 instance to cluster to geo replicating cluster with minimal effort.

While vanilla postges for an equivalent setup is basically pulling teeth.

Re: It's 2026, Just Use Postgres

#214

Post by avmich »

sbayeta wrote: post #177
avmich wrote: post #153

I have two fundamental problems with Postgres - an excellent piece of technology, no questions about that. First, to use Postgres for all those cases you have to learn various aspects of Postgres. Postgres isn't a unified tool which can do everything - instead it's a set of tools under the same umbrella. As a result, you don't save much from similarly learning all those different systems and using Postgres only as a…

Never heard about postgresql being written for hdds. Could you provide a source?

Well, take a look at the dates of when Postgres was created and when SSDs become available. Better, find articles about internal algorithms, B-trees, times of operations like seeks etc. The Postgres was initially written with disk operation timings in mind, and the point is that's changing - and I haven't heard of Postgres architecture changing with that.

Re: It's 2026, Just Use Postgres

#215

Post by dimgl »

avmich wrote: post #153

I have two fundamental problems with Postgres - an excellent piece of technology, no questions about that. First, to use Postgres for all those cases you have to learn various aspects of Postgres. Postgres isn't a unified tool which can do everything - instead it's a set of tools under the same umbrella. As a result, you don't save much from similarly learning all those different systems and using Postgres only as a…

SSD-native RDBMS sounds good in theory! What's in mean in practice? What relational databases are simpler and more performant? Point me in their direction!

Re: It's 2026, Just Use Postgres

#216

Post by dimgl »

teraflop wrote: post #171
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…

I don't mean this as a knock on you, but your comment is a bit funny to me because it has very little to do with "modern" databases. What you're describing would probably have been equally possible with Postgres from 20 years ago, running on an average desktop PC from 20 years ago. (Or maybe even with SQLite from 20 years ago, for that matter.) Don't get me wrong, Postgres has gotten a lot better since 2006. But most…

20 years ago was 2006? Oh no...

Re: It's 2026, Just Use Postgres

#217

Post by TacticalCoder »

teraflop wrote: post #171
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…

I don't mean this as a knock on you, but your comment is a bit funny to me because it has very little to do with "modern" databases. What you're describing would probably have been equally possible with Postgres from 20 years ago, running on an average desktop PC from 20 years ago. (Or maybe even with SQLite from 20 years ago, for that matter.) Don't get me wrong, Postgres has gotten a lot better since 2006. But most…

> Don't get me wrong, Postgres has gotten a lot better since 2006.

And hardware has gotten a lot better too. As TFA writes: it's 2026.

Re: It's 2026, Just Use Postgres

#218

Post by fragmede »

dimgl wrote: post #216
teraflop wrote: post #171

Earlier quoted context omitted.

I don't mean this as a knock on you, but your comment is a bit funny to me because it has very little to do with "modern" databases. What you're describing would probably have been equally possible with Postgres from 20 years ago, running on an average desktop PC from 20 years ago. (Or maybe even with SQLite from 20 years ago, for that matter.) Don't get me wrong, Postgres has gotten a lot better since 2006. But most…

20 years ago was 2006? Oh no...

Don't get me started on when the 90's were.

Re: It's 2026, Just Use Postgres

#219

Post by direwolf20 »

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…

Postgres is infinitely extensible, more than MariaDB. But it's very painful to write or configure extensions and you might as well use something different instead of reaching for an extension mechanism.

Re: It's 2026, Just Use Postgres

#220

Post by stouset »

teraflop wrote: post #171
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…

I don't mean this as a knock on you, but your comment is a bit funny to me because it has very little to do with "modern" databases. What you're describing would probably have been equally possible with Postgres from 20 years ago, running on an average desktop PC from 20 years ago. (Or maybe even with SQLite from 20 years ago, for that matter.) Don't get me wrong, Postgres has gotten a lot better since 2006. But most…

And 20 years ago people were making the exact same kinds of comments and everyone had the same reaction: yeah, MySQL has been putting numbers up like that for a decade.
Post reply on HN