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

321–330 of 349 posts

Re: It's 2026, Just Use Postgres

#321

Post by delish »

tim-- wrote: post #278
delish wrote: post #263

Earlier quoted context omitted.

Apart from the style of the prose, which is my subjective evaluation: This blog post is "a view from nowhere." Tiger Data is a company that sells postgres in some way (don't know, but it doesn't matter for the following): they could speak as themselves, and compare themselves to companies that sell other open source databases. Or they could showcase benchmarks _they ran_. Them saying: "What you get: pgvectorscale use…

For what it's worth, TigerData is the company that develops TimescaleDB, a very popular and performant time series database provided as a Postgres extension. I'm surprised that the fact that TigerData is behind it is not mentioned anywhere in the blog post. (Though, TimescaleDB is mentioned 14 times on the page).

The cynical take is: the AI doesn't know you-the-blog-post-author made TimescaleDB unless you tell it!

Re: It's 2026, Just Use Postgres

#322

Post by spdionis »

MonkeyClub wrote: post #316
tomhow wrote: post #290

Earlier quoted context omitted.

> You are seemingly overriding the wishes of the community That's false. The overwhelming sentiment of the community is that HN should be free of LLM-generated content or content that has obvious AI fingerprints. Sometimes people don't immediately realize that an article or comment has a heavy LLM influence, but once they realize it does, they expect us to act (this is especially true if they didn't realize it initia…

>> You are seemingly overriding the wishes of the community > That's false. The overwhelming sentiment of the community is that HN should be free of LLM-generated content or content that has obvious AI fingerprints. Yeah it is indeed, and for good reason: why would I spend time reading something the author didn't spend time thinking through and writing? It's not that people don't like Postgres articles (otherwise, th…

Likely a lot of medium posts? That's my theory anyway.

Re: It's 2026, Just Use Postgres

#323

Post by kiwicopple »

quotemstr wrote: post #143
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.

There's a fascinating gap between PostgreSQL theory and practice here. Elsewhere in this thread, I complained that PostgreSQL extensions can't do everything yet. One thing they can do, however, or ought to be able to do, is provide alternative storage engines. That's the central thing they're supposed to be especially good at providing. So what did the VACUUM-free, undo-based MVCC storage engine project stall? https:…

> Why is there no InnoDB for PostgreSQL?

(we maintain OrioleDB) Mostly because the TAM API isn't mature enough yet. Hopefully we can upstream more patches so that it's possible

> undo-based MVCC storage engine project stall?

From what I could gather, it ran out of steam simply because of the difficulty of the task. There is a lot of work involved to get the requisite patches into core and the community are (correctly) cautious

Re: It's 2026, Just Use Postgres

#324

Post by zemo »

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

> memcached is multithreaded, so it scales up better per node.

redis i/o is multithreaded, it's just the command loop that's single-threaded. If all you're doing is SET and GET of individual key-value pairs, every time I've seen a redis instance run hot under that sort of load, the bottleneck was the network card, never the CPU.

I ... actually think scaling redis for simple k-v storage is already pretty easy so I dunno that that's much of a concern?

mcrouter ... damn I haven't thought about mcrouter in at least 10 years.

Re: It's 2026, Just Use Postgres

#325

Post by riku_iki »

lima wrote: post #145
bluepuma77 wrote: post #82

Now we only need easy self-hosted Postgres clustering for HA. Postgres seems to need additional tooling. There is Patroni, which doesn't provide container images. There is Spilo, which provides Postgres images with Patroni, but they are not really maintained. There is a timescaledb-ha image with Patroni, but no documentation how to use it. It seems the only easy way for hosting a Postgres cluster is to use CloudNativ…

Postgres is not a CP database, and even with synchronous replication, it can lose writes during network partitions. It would not pass the Jepsen test suite. This is very hard to fix and requires significant architectural changes (like Yugabyte or Neon have done).

> Postgres is not a CP database, and even with synchronous replication, it can lose writes during network partitions.

Argument is that partitioning almost never happens, because of network reliably rerouting traffic.

Re: It's 2026, Just Use Postgres

#328

Post by johnfn »

tomhow wrote: post #277
krick wrote: post #245

No, seriously, people need to be punished for submitting LLM-generated garbage without specifying that it's LLM-generated garbage. 400+ points, oh my god, people, what's wrong with you...

We buried the post for seeming obviously-LLM-generated. But please email us about these (hn@ycombinator.com) rather than posting public accusations. There are two reasons why emailing us is better: First, the negative consequences of a false allegation outweigh the benefits of a valid accusation. Second and more important: we'll likely see an email sooner than we'll see a comment, so we can nip it in the bud quickly,…

Hey Tom! Earnest question here - I am seeing on the order of one AI post a day on HN, sometimes more than that. It's good to know we can email in about these things, but I think most users don't understand that - certainly I didn't for the last few month as this has been going on. It would be nice if there was an affordance on the site to flag these, similar to the existing flag function.

Thanks!

Re: It's 2026, Just Use Postgres

#329

Post by giovannibonetti »

sgarland wrote: post #110
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…

> 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.

You can achieve that with Postgres as well if you accept duplicating the data by adding an index with an include clause containing all the non-key columns you want to return in the SELECT clause. This way, you'll get fast index-only scans.

Re: It's 2026, Just Use Postgres

#330

Post by tovlier »

vagab0nd wrote: post #314
kccqzy wrote: post #273

Earlier quoted context omitted.

But OP never said it's a CRUD app. Maybe OP did some experimentation with OLAP use cases.

OP here. Roughly 50GB in db size. Fairly standard queries (full-text search + filters). Most queries are on the order of 10-100ms. Some more complex ones involving business logic exceeds 100ms. This is well within my budget, but it sounds like there might be room for improvements?

[dead]
Post reply on HN