Tag

PostgreSQL

14 stories

Not just a headline — the discussion unpacked

The top HN threads: facts from the discussions, both sides, insider voices. Email, Telegram, or RSS.

PostgreSQL for everything is a design choice with a price (raphaelbauer.com)

PostgreSQL can cover relational data, full-text search, queues, and extensions in one familiar operational surface, which is attractive to small teams.

The counterpoint is not that Postgres is weak. It is that a default becomes cargo cult when workload shape, scale, or failure modes have not been examined.

🚀Tech ★ 307 · 💬 190 · Aug 20 · #data#dev tools#programming#PostgreSQL

Postgres LISTEN/NOTIFY can scale — if your definition is specific (dbos.dev)

DBOS argues that LISTEN/NOTIFY can serve high-throughput workloads with the right design. The thread accepted the measurement but resisted the headline, noting that its 8KB notification payload limit and delivery semantics define where it fits.

The valuable takeaway is architectural rather than tribal: use notifications to signal durable rows or work, not to pretend they are an unrestricted message bus. A system that handles 60,000 events per second may be excessive for one team and inadequate for another.

A Postgres guide told startups to normalize their schema first. HN said monitoring should come before that (hatchet.run)

Hatchet's Postgres guide walks startups through schema design, query optimization, and scaling, with real thresholds — sequential scans get costly past 20k rows, autovacuum runs over an hour mean tuning is overdue.

A commenter who'd run Postgres at an early-stage startup pushed back: monitoring deserved to rank above schema design, because failure modes like transaction ID wraparound give almost no warning — and the AWS alert email is easy to miss, especially on Boxing Day.

ClickHouse turned PgBouncer's one CPU core into sixteen for 4x throughput (clickhouse.com)

On a 16-vCPU box, one PgBouncer process topped out around 77,000 transactions per second at 256 clients while using under 8 percent of the machine. ClickHouse's Postgres team ran sixteen processes on the same port instead, using a kernel trick called so_reuseport, and throughput jumped to 336,000 — roughly 4x — with a fix for cancel requests that used to vanish into the wrong process. One reply in the thread was blunter: Yandex already ships a pooler built to do this natively, no patch required.

A Postgres pooler that fixes the leak where one client's session bleeds into another (pgdog.dev)

PgDog ships its own SQL parser so it can track SET, LISTEN/NOTIFY and prepared statements per client and restore them before each query, the exact features PgBouncer's transaction mode makes you give up. Kokotov says it's run a year in production at 2M queries/sec.

The thread's war stories agreed the tax is real: one engineer who'd just moved a Django app behind PgBouncer found queryset.iterator()'s server-side cursors didn't survive pooling, and statement_timeout in libpq startup params got silently ignored.

One database for everything: the case against Redis, Mongo, and Pinecone (postgresisenough.dev)

The catalog is specific: UNLOGGED tables instead of Redis, SKIP LOCKED instead of a job queue, pgvector instead of Pinecone, PostGIS instead of your geo stack, with a rule that you may leave Postgres only after documenting why it wasn't enough.

A developer running an email CRM on Redis isn't buying the premise: it's trivial to set up and never crashes, so what difficulty is this genre even describing?

Ubicloud says the Linux OOM killer can drop every Postgres connection at once. Its own co-founder says the post oversells it (ubicloud.com)

The mechanism: Postgres backends share memory segments, so an OOM kill of one can force the postmaster to terminate every backend at once. Ubicloud's answer is strict overcommit (vm.overcommit_memory=2): Linux refuses over-limit allocations with ENOMEM, and Postgres cancels just the offending transaction.

The thread splits. A commenter says the article describes the kernel's overcommit modes wrong and ignores oom_score_adj; the company's own co-founder concedes the framing was too strong.

Postgres 19 finally reorganizes tables without locking, and borrows GROUP BY ALL from DuckDB (snowflake.com)

Snowflake's Craig Kerstiens walks through the Postgres 19 beta: REPACK CONCURRENTLY reorganizes bloated tables without locks (no more pg_repack), partitions can now merge and split in place, autovacuum gets parallel workers, and SQL/PGQ brings graph queries to relational data.

The thread wanted what's still missing more than what shipped. A 15-year Postgres user in science flagged the absent columnar storage as datasets balloon; others miss materialized views and in-place major upgrades. And the top nitpick: GROUP BY ALL was DuckDB's idea first.

The gist that says Postgres replaces Kafka, Redis and Neo4j (gist.github.com)

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.

A solo dev built an ER diagram tool that never sends your SQL anywhere — then a data engineer said it isn't ER (sqltoerdiagram.com)

Tired of tools with paywalls, signups, or servers that swallow your schema, robhati built sqltoerdiagram.com: a client-side canvas where pasted DDL becomes an interactive diagram you can drag, auto-arrange, and export as PNG or SVG.

The engineering flex: tables are rasterized into cached bitmaps with viewport culling, and the SQL parser tracks source spans so a rename stays surgical. The pushback: tables aren't entities, so SQL alone can't give you a real ER diagram.

🚀Tech ★ 340 · 💬 72 · Jun 15 · #data#dev tools#privacy#Azimutt#dbdiagram#MySQL+2

Postgres 19 can finally answer: what did this row look like last Tuesday? (pgedge.com)

Postgres 19 adds native application-time temporal tables: PRIMARY KEY (id, valid_at WITHOUT OVERLAPS) replaces the EXCLUDE-USING-gist dance, FOR PORTION OF lets an UPDATE rewrite just one time slice, and PERIOD foreign keys enforce validity across a duration.

The developer who implemented it joined the thread to say it still lacks system-time, which he hopes to tackle next — and the article's author called it the biggest single release since v10.

A 3-person startup raised $5.5M to make Postgres shard without touching your code (pgdog.dev)

You change only your connection string, not your app. The open-source version has 1.4M Docker pulls; the round is from Basis Set, YC and Pioneer Fund.

Simon Willison's request was the most telling product feedback: ship a plain binary, because he won't fire up Helm or Docker just to kick the tires.

📈Biz ★ 389 · 💬 198 · Jun 11 · #data#dev tools#startups#PgDog#PostgreSQL#Rust+1