DBLab Engine 4.2 is out! Main thing: you can now pg_upgrade a clone with just one click or in CLI call: ==> dblab clone upgrade my-clone => automation stops the clone, "pg_upgrade --link" runs in place, then clone comes back on a new Postgres major version. As usual, prod and every other clone untouched. Didn't like the result? ==> dblab clone reset No more excuses to avoid full-fledged testing before production Postgres gets upgraded. Also in 4.2: - paste a source URL, DBLab figures out provider, image, databases, settings - branches and snapshots expire on policy (off by default) - secrets from env vars (not plain-text in configs anymore) - clone creation ~2x faster

traditional reminder that simple ALTER TABLE that felt instant on your laptop can put your production Postgres down it needs to be cooked properly in production – use lock_timeout and retries postgres.ai/blog/20210923-ze…

PgQue got a website with docs – pgque.dev

Working on this is a lot of fun. Here I shared how it all started, what original PgQ already has and what didn't, and what v0.2 brings (RC1 stamped yesterday)

What a nice blog post by Christophe Pettus PgQue: Two Snapshots and a Diff thebuild.com/blog/2026/05/03…

Precise (not sampled) wait even analysis is something I didn't expect to have for Postgres - but here we go Being able to zoom into concrete millisecond (!) and see the exact chain of wait events opens new possibilities for RCA, benchmarks, and performance studies links 👇

PgQue v0.1.0 is out. PgQ -- the Postgres queue system built at Skype 20 years ago for 1B-user-scale workloads -- repackaged for the managed-Postgres era. One SQL file. No C extension. No external daemon. pg_cron to tick. Why bother reviving a 2007 architecture? Every major Postgres queue in production today uses some flavor of SKIP LOCKED + UPDATE/DELETE. It works under light load. When you have more data and higher load, it degrades predictably. Then you get posts like these: - Brandur at Heroku, 2015: 60k job backlog in one hour from a single open transaction - PlanetScale, 2026: death spiral at 800 jobs/sec - River issue #59, awa issue #169 and so on, Oban's partitioning work, PGMQ's autovacuum tuning guide and duct-taping with pg_partman The core issue is how Postgres MVCC is implemented and how we deal with it. Dead tuples in the hot path, xmin horizon pinned, vacuum falling behind, query performance quickly degrades. This happens every time you run pg_dump, execute an analytical query, or have a lagging/unused logical replication slot. PgQ solved this in 2007 with snapshot-based batching and TRUNCATE rotation -- zero dead tuples in the event path, by design. But PgQ needed a C extension and an external daemon. Which means it doesn't run on RDS, Aurora, Cloud SQL, AlloyDB, Supabase, or Neon -- i.e., where most Postgres lives now. PgQue closes that gap. 💎 Pure SQL + PL/pgSQL (PgQ engine) 👩‍💻 \i sql/pgque.sql -- you're done 🕑 pg_cron replaces pgqd (optional, recommended) 💻 Python, Go, TypeScript client examples shipped 💙 Apache 2.0 Trade-off: end-to-end event delivery latency is up to a second, it depends on ticking frequency. If you need sub-3ms job dispatch, use River, Oban, or graphile-worker (and avoid anything that blocks xmin horizon). If you need high-throughput event streaming with fan-out inside Postgres -- Kafka-shaped, without Kafka and dealing with transactional outbox implementation -- this is the right shape of tool. Kudos to Marko Kreen and Skype engineers who implemented this decades ago, for the original PgQ, and to Alexander Kukushkin whose recent "Rediscovering PgQ" talk brought this quiet corner of the Postgres ecosystem back into view. Stars, issues, PRs, and honest criticism all welcome. Link 👇

PG18 preserves planner statistics on upgrade — even from PG14 postgres.ai/blog/20260324-pg…

For fun, I rewrote psql in Rust and integrated it with AI meet "rpg" -- an experimental CLI maybe, at some point, it will bring ideas to psql itself thoughts? link in the 1st comment

pg_ash v1.3 released -- Active Session History for Postgres, pure SQL. New in 1.3: - pg_cron now optional -- works with external schedulers - set_debug_logging() -- RAISE LOG per sampled session - pgss-dependent functions fail fast with clear errors - Azure Flexible Server compatibility - PG14-18 tested Install: \i sql/ash-install.sql No extensions, no restart. Works on RDS, Cloud SQL, AlloyDB, Supabase, etc.

it was a fun session -- prototyped command tag customization at protocol level: github.com/NikolayS/postgres…

pg_ash is out Postgres has no session history. When something was slow an hour ago, there's nothing to look at. pg_ash fixes that -- pure SQL, one file install, works on RDS/Cloud SQL/Supabase/self-hosted, anywhere where you have pg_stat_statements and pg_cron. No extension, no restarts, no provider approval. Just \i one file.

I like how easy it is now to get the new @postgres_ai copilot for any @PostgreSQL database: One-click deployment in three modes – PaaS, BYOC, BYOM Easy access to dashboards at xxxxxx.pgai.watch by default – in case you need to dive into all the details "Resolve in Cursor" for issues that can be solved via code changes (or you can use Claude Code, Codex, etc.)

Your Postgres TODO list has been the same for 6 months: □ Drop unused indexes □ Eliminate bloat □ Tune autovacuum □ Set up proper monitoring Today we're launching @postgres_ai – automated Postgres maintenance so your team can focus on shipping. PR/MR-based approvals. Zero-downtime operations. Built by the team with deep Postgres expertise, trusted by GitLab, Supabase, Gadget, and many others. Early access: postgres.ai

this repo deserves more stars github.com/postgres-ai/postg… gitlab.com/postgres-ai/postg… we aim to have the most detailed and advanced monitoring for Postgres -- and it's FOSS because it's just a foundation of something bigger (after 20 years with Postgres, next month will be the most exciting announcement of my career)