Sammlung von Newsfeeds

Every AI application built on PostgreSQL hits the same inflection point. You've got pgvector installed, embeddings in a table, a similarity search query that returns surprisingly good results. The prototype works and your team is excited. Someone asks "when can we ship this?" and you suddenly realize that the distance between "it works on my laptop" and "it works in production across three regions" is a lot larger than you thought.The usual answer is to re-platform. Swap Postgres for a purpose-built vector database for the AI parts. Add a separate search service.

PostgreSQL's `DEFERRABLE` transaction mode only works with `SERIALIZABLE READ ONLY` transactions, where it waits for a safe snapshot to eliminate…

#​653 — June 17, 2026

Web Version

Postgres Weekly

Scaling Postgres to 226k TPS: A Christmas Day Retrospective — A meaty post-mortem and tactical walkthrough of how a digital photo-frame company went from having its Postgres deployment crash out during the 2024 holiday season to handling 2025 without a hitch.

Andrew Atkinson

pg_ducklake 1.0 is production-ready: a standalone extension built on a reusable kernel, with broad DuckLake coverage and the fastest ingestion path for the lakehouse.

What's new in pgstream v1.1.0: env vars in YAML config, JSON logs, Kubernetes health probes, custom TLS for OpenSearch, and fixes for composite primary keys.

📌 Overview

Ruby on Rails has helped make it possible to scale out the database layer, meeting the demands of millions of Aura Frames customers enjoying their digital photo frames.

In late 2025, the team added additional primary databases to expand capacity for peak write and read load ahead of Christmas Day, the busiest day of the year for the company. Rails manages queries and schema changes for each primary database within the same codebase, and now with the additional capacity of many primary databases.

📌 Overview

On Christmas Day 2024, Postgres infrastructure powering the Aura Frames API had problems under peak load, being unavailable for three hours and disrupting the experience for new customers. The team knew it would need improvements to handle the surge for Christmas 2025 and beyond.

One year later, much of the resource intensive data access was reworked, the Postgres infrastructure was upsized, and this approach not only survived, but thrived, providing reliable service through the holiday season.

Part 1 was about failures that start one layer below Postgres: the kernel, glibc, the page allocator. This post is about the worse class, where the failure is inside Postgres itself. The logs are clean. Recovery never runs. And a query either returns the wrong answer or drops rows that are still sitting on disk.

On March 8, 2026, British Columbia moved their clocks to a year-round Pacific Daylight Savings Time. In March, they did the spring forward one hour with their clocks to UTC-7, but they won't fall back to UTC-8 in November. Going forward, the UTC offset for America/Vancouver timezone is permanently UTC-7.

Upgrading PostgreSQL in production is not fun. You have real data, real users, and a version of Postgres that’s probably several major releases behind. The obvious approach (dump, upgrade, restore) works fine on a 10GB database on a Saturday night. It doesn’t work when you have TBs of data, applications that can’t afford hours of downtime, and a team watching the monitoring dashboard at 2am.

PostgreSQL 19 switches TOAST compression from pglz to lz4 by default—faster, more efficient, and finally the right call.

I'm lately back from Chicago, where PG DATA 2026 is now in the books! This is the two-day successor to PGDay Chicago, where I've been involved for the past few years volunteering, speaking, and finally organizing (and also volunteering and speaking). Everything went blessedly smoothly with only a few close calls, and we're already starting to plan next year's event.

In distributed database environments, balancing durability and performance is a constant tug-of-war. PostgreSQL’s synchronous_commit parameter sits at the heart of this, giving administrators a dial to choose exactly when a COMMIT returns success to the client.

The Landscape Has Changed

When I was at Turnitin, we were still kind of riding the tail end of the dot-com boom. People were rushing to ship things, and brief outages were not exactly good, but they were considered a normal part of running software on the internet. If the site was down for a few minutes, you’d shrug, dig in, and fix it.

PostgreSQL forbids indexing with the default text search configuration because it's mutable—change the setting, and your index silently disagrees with reality.

A NOT IN query can return the wrong answer without telling you. It is valid SQL, it runs without an error, and it hands back a perfectly well-formed result set that happens to be empty when it should not be. No warning, no hint, nothing in the logs: just zero rows where you expected hundreds, and a database that considers it correct.

Default_tablespace quietly routes tables and indexes to alternate storage — but three quirks can surprise you, and tablespaces themselves are mostly…

Force the use of the partition key and protect your PostgreSQL server from full partition scans

PostgreSQL's table access method interface lets you plug in alternative storage engines.

If you have ever been in the middle of a database migration and suddenly found your logical replication slots missing, you know how unsettling that feeling is. No obvious error. No warning. Just gone. That is exactly what happened to us while migrating data from a Patroni-managed cluster to a standalone PostgreSQL cluster. What started as a smooth operation turned into a debugging session that taught us something important about how Patroni behaves after a restart.