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

91–100 of 349 posts

Re: It's 2026, Just Use Postgres

#91

Post by nazgul17 »

zemo wrote: post #60
dgxyz wrote: post #32

Earlier quoted context omitted.

Neither. Just use memcache for query cache if you have to. And only if you have to, because invalidation is hard. It's cheap, reliable, mature, fast, scalable, requires little understanding, has decent quality clients in most languages, is not stateful and available off the shelf in most cloud providers and works in-clusetr in kubernetes if you want to do it that way. I can't find a use case for Redis that postgres o…

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

I imagine the answer here is: less complexity.

Re: It's 2026, Just Use Postgres

#92

Post by christophilus »

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’ve thought of doing this myself. Upgrades also seem easier in MySQL. That said, it does seem to be stagnating relative to Postgres.

Re: It's 2026, Just Use Postgres

#93

Post by groundzeros2015 »

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…

In my experience the functionality of “purpose built systems” is found in Postgres but you have to read the manual.

I personally think reading manuals and tuning is a comparably low risk form of software development.

Re: It's 2026, Just Use Postgres

#94

Post by christophilus »

simonw wrote: post #31
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.

Prove that you need the extra speed. Run benchmarks that show that, for your application under your expected best-case loads, using Redis for caching instead of PostgreSQL provides a meaningful improvement. If it doesn't provide a meaningful improvement, stick with PostgreSQL.

Yep. And often, if you do find a need for a cache, you can get away with an in-app cache before moving to something like Redis.

Re: It's 2026, Just Use Postgres

#97

Post by herpdyderp »

koeng wrote: post #7
olivia-banks wrote: post #5

I do agree, I don’t know why more people don’t just use Postgres. If I’m doing data exploration with lots of data (e.g., GIS, nD vectors), I’ll just spin up a Postgres.app on my macOS laptop, install what little I need, and it just works and is plenty fast for my needs. It’s a really great choice for a lot of domains. That being said, while I think Postgres is “the right tool for the job” in many cases, sometimes you…

I am also a fan of SQLite. One of the best parts during development is how easy it is to spin up and spin down databases for full integration tests without containers or anything. It also simplifies backups, and is probably good enough.

These days I would recommend PGlite for testing purposes when you use Postgres in production. That way you don't need any specific SGQLite vs Postgres behavior switches.

Re: It's 2026, Just Use Postgres

#98

Post by properbrew »

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.

SQLite is awesome, no services to run, ports to open or anything like that, just a nice little database to use as you need.

Re: It's 2026, Just Use Postgres

#99

Post by gavmor »

guelo wrote: post #49

This is the future of all devtools in the AI era. There's no reason for tool innovation because we'll just use whatever AIs know best which will always be the most common thing in their training data. It's a self-reinforcing loop. The most common languages, tools, libraries of today are what we will be stuck with for the foreseeable future.

Is that any different from "we'll just use whatever devs know best, which will always be the most common thing?"

eg Python, react... very little OCaml, Haskell, etc.

Re: It's 2026, Just Use Postgres

#100

Post by benjiro »

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 the benefits of a DB.

Post reply on HN