The gist that says Postgres replaces Kafka, Redis and Neo4j
A single gist lines up Postgres extensions against Kafka, Redis, Elasticsearch, Neo4j and a dozen other systems, arguing one database covers them all. The thread filled with people who tried that and got paged for it.
The gist sets a deliberately high bar: pick a separate system only after you have pushed Postgres to its limits, documented why it fell short, and accepted the operational cost. PGMQ stands in for Kafka, pgvector and ParadeDB for Elasticsearch, Apache AGE for Neo4j, TimescaleDB for time-series.
Then a Google SRE flips it: you only reach for Kafka or Snowflake at the point Postgres stops being viable, so the comparison runs backwards. And a 20-year ops veteran argues one big database is harder to run than several small ones.
One database, a shrine to it, and a wall of skeptics
The gist is a curated map of how far one database can stretch. Each specialized system gets a Postgres-native answer: PGMQ for Kafka-style queues, pgvector and ParadeDB for Elasticsearch search, Apache AGE for Neo4j graphs, TimescaleDB for time-series, FerretDB for MongoDB, pg_cron for job schedulers. The argument is not that Postgres equals each tool, but that the default should be Postgres until proven otherwise: reach for a separate system only after pushing it to its limits, documenting why it was insufficient, and accepting the operational cost of running two stacks instead of one.
The people who actually ran the second stack
The thread mostly agrees on the small-scale case and then attacks the bar itself. A Google Android SRE argued the whole comparison runs the wrong direction.
"Kafka? No one wants to operate Kafka, if it's a serious contender it's because you need things only it can do… you'd only consider it at the point that Postgres is no longer suitable." — a Google Android SRE
A Supernotes co-founder pushed back on the high bar from the other side, where reaching for an alternative is the cheaper move.
"Why do I need to push Postgres to its limits before using a different solution? Throwing a hosted Redis in front of some hot-path API calls is… easier to reason about than materialized views or UNLOGGED tables." — a Supernotes co-founder
The sharpest reversal targets the gist's premise that one database lowers your maintenance burden. An engineer with two decades in production infrastructure says the opposite was true for him.
"You have pushed your entire infrastructure into a single failure domain… You make it certain that if your database fails, EVERYTHING fails." — an engineer with 20+ years maintaining production infrastructure
A separate fault line opened over the gist's first recommendation, moving business logic into database functions. A Bay Area engineer who inherited such a system called it hair-pulling to debug, and others piled on that triggers and stored procedures bind your product to Postgres forever. The pattern across the whole thread is consistent: nobody disputes that Postgres is enough when load is low, and almost everybody who has felt real infrastructure pressure disputes that it stays enough on the way up.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
OpenAI's first chip, 'Jalapeño', went from design to silicon in nine months
OpenAI says its own inference processor, built with Broadcom and fabbed by TSMC, beats today's state-of-the-art on performance-per-watt. It is still in testing.