It's 2026, Just Use Postgres • Hacker News Board

Re: It's 2026, Just Use Postgres

#231

Post by direwolf20 » Fri, Feb 06, 2026, 2:35 AM UTC

KlayLay wrote: post #191

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 agree that SQLite requires less maintenance, but you still need to vacuum to prevent the database file from accumulating space (for apps, I run VACUUM at startup).

SQLite vacuum is only needed to shrink the database after you remove a lot of data. It's not needed in routine operations like postgres does. Postgres has autovacuum usually on by default so I'm not understanding the complaint much

Re: It's 2026, Just Use Postgres

#232

Post by direwolf20 » Fri, Feb 06, 2026, 2:37 AM UTC

NuclearPM wrote: post #115

sgarland wrote: post #107

Earlier quoted context omitted.

If you think Postgres has idiosyncrasies… https://sqlite.org/quirks.html

Which one is an issue?

No types, no foreign key enforcement, double–quoted string literals

Re: It's 2026, Just Use Postgres

#233

Post by direwolf20 » Fri, Feb 06, 2026, 2:38 AM UTC

groundzeros2015 wrote: post #90

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.

Materialised views don't work well in postgres. They don't incrementally update and have to be manually triggered to rebuild from scratch

Re: It's 2026, Just Use Postgres

#234

Post by direwolf20 » Fri, Feb 06, 2026, 2:40 AM UTC

benjiro wrote: post #100

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…

The problem is that Postgres uses something like 24B overhead per row. That is not a issue with small Tables, but when your having a few billion around, each byte starts to add up fast. Then you a need link tables that explode that number even more, etc ... It really eats a ton of data. At some point you end up with binary columns and custom encoded values, to save space by reducing row count. Kind of doing away with…

Yeah postgres and mariadb have some different design choices. I'd say use either one until it doesn't work for you. One of the differences is the large row header in postgres.

Re: It's 2026, Just Use Postgres

#235

Post by esafak » Fri, Feb 06, 2026, 2:44 AM UTC

The only thing postgres lacks is a distributed option.

Re: It's 2026, Just Use Postgres

#236

Post by cbdevidal » Fri, Feb 06, 2026, 2:45 AM UTC

fragmede wrote: post #218

dimgl wrote: post #216

Earlier quoted context omitted.

20 years ago was 2006? Oh no...

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

Twenty years ago? You mean 1982, right? Right!?

Re: It's 2026, Just Use Postgres

#237

Post by deeviant » Fri, Feb 06, 2026, 2:50 AM UTC

I have problem pulled out postgres 10 or more times for various projects at work. Each time I had to fight for it, each time I won, it did absolute everything I needed it to do and did it well.

Re: It's 2026, Just Use Postgres

#238

Post by Kuyawa » Fri, Feb 06, 2026, 2:51 AM UTC

> Over 48,000 companies use PostgreSQL, including Netflix, Spotify, Uber, Reddit, Instagram, and Discord.

I hope all of them donate to the PostgreSQL community in the same amount they benefit from it

https://www.postgresql.org/about/donate/

Re: It's 2026, Just Use Postgres

#239

Post by mixmastamyk » Fri, Feb 06, 2026, 2:52 AM UTC

exabrial wrote: post #210

The real problem is, I'm so danged familiar with the MySQL toolset. I've fixed absolutely terrifying replication issues, include a monster split brain where we had to hand pick off transactions and replay them against the new master. We've written a binlog parsing as an event source to clear application caching. I can talk to you about how locking works, when it doesn't (phantom locks anyone?), how events work (and w…

Start learning on the side. Know one well, the time to learn another is much shorter. Bet you could be well on your way in just a few weeks. Not to mention getting away from the Oracle stink.

Re: It's 2026, Just Use Postgres

#240

Post by natnat » Fri, Feb 06, 2026, 2:52 AM UTC

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…

This really isn't true. You should use different parameters (specifically, you can reduce the random_page_cost to a little over 1) on a SSD but there isn't a really compelling reason to use a completely different DBMS for SSDs.