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

101–110 of 349 posts

Re: It's 2026, Just Use Postgres

#101

Post by technion »

SoKamil wrote: post #28

This post is discussing more specialized databases, but why would people choose Oracle/Microsoft DB instead of Postgres? Your own experience is welcome.

Easy answer here - nearly every LOB app we have uses MSSQL.

I've had engineers want to talk about syncing it to MySQL using some custom plumbing so that they can build a reporting infra around their MySQL stack, but it's just another layer of complexity over having code just use Microsoft's reporting services.

I'll add, having finance people with Excel really like being able to pull data directly from MSSQL, they do not like hearing about a technican's python app.

Re: It's 2026, Just Use Postgres

#102

Post by jen20 »

cpursley wrote: post #3

Good stuff, I turned my gist into an info site and searchable directory (and referenced this article as well, which seems to pay homage to my gist, which in turn inspired the site) https://PostgresIsEnough.dev

This is a good summary, though I'd love to see a "High Availability and Automated Failover" entry in that table.

Re: It's 2026, Just Use Postgres

#103

Post by rtpg »

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…

> in many cases, sometimes you just want (relative) simplicity, both in terms of complexity and deployment, and should use something like SQLite.

So many times when trying to just go for simplicity with SQLite it takes me like one working day until I run up against enough annoyances to where resolving those is more work than setting up the "set up and forget" postgres instance.

Granted, this is for personal stuff... but "Postgres packaged for low maintenance" is present in a lot of OS package managers! Even for smaller data analysis work SQLite perf leads _loads_ to be desired (once had QGIS struggling with a sqlite DB... pg made everything mostly instant. Indices etc... but stuff I _couldn't easily get with sqlite_)

If SQLite works for you that's great, I do think it's worth it for people to _try_ to do simple pg setups to understand just how painful it is to use pg (for me: not that high)

Re: It's 2026, Just Use Postgres

#104

Post by [deleted] »

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.

[deleted]

Re: It's 2026, Just Use Postgres

#105

Post by stock_toaster »

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

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

Re: It's 2026, Just Use Postgres

#107

Post by sgarland »

DJBunnies wrote: post #95
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'm in the same boat, the idiosyncrasies of postgres are real; mysql / sqlite are far more predictable.

If you think Postgres has idiosyncrasies…

https://sqlite.org/quirks.html

Re: It's 2026, Just Use Postgres

#110

Post by sgarland »

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.

MySQL is definitely easier to use if you don’t want to ever have to think about DB maintenance; on the other hand, you’re giving up a TON of features that could make your queries enormously performant if your schema is designed around them - like BRIN indices, partial indices, way better partition management, etc.

OTOH, if and only if you design your schema to exploit MySQL’s clustering index (like for 1:M, make the PK of the child table something like (FK, some_id)), your range scans will become incredibly fast. But practically no one does that.

Post reply on HN