The database stories enterprise IT leaders actually read.
Volume 342, Issue 4 · 6 articles from 2 issues
PostgreSQL 19, in beta, adds REPACK CONCURRENTLY to make routine database maintenance far less disruptive.
LinuxInsider reports that PostgreSQL 19, still in beta with a fourth beta scheduled for September 24, introduces improvements aimed at making routine database maintenance, table repacking, and logical replication less disruptive.
Vacuum operations, which clean up obsolete row versions, free storage, and prevent transaction ID wraparound, remain essential but disruptive maintenance routines.
The new REPACK CONCURRENTLY functionality allows normal reads and writes to continue during most of the repacking operation. Together, these capabilities should help organizations recover wasted storage, manage large database installations, and make infrastructure changes with fewer interruptions.
Volume group snapshots bring back the storage-array consistency group that CSI's one-PVC-one-snapshot model discarded.
Restoring a PostgreSQL cluster whose data directory and write-ahead log live on separate PersistentVolumeClaims can fail even when every snapshot reported success, because the WAL references pages never captured in the data files.
The backup was not corrupted in transit; it was inconsistent the moment it was taken. Enterprise storage arrays solved this decades ago with consistency groups that froze a set of LUNs at the same instant, but the Container Storage Interface standardized snapshots around a single VolumeSnapshot scoped to one PVC.
Backup tools enumerate PVCs and snapshot them in sequence, so multi-volume applications lose point-in-time coherence. Most teams never notice, because the gap only surfaces at restore time after an incident, when it is far too late to act.
PostgreSQL can run durable workflows using SKIP LOCKED queues, idempotent checkpoints and lease-based recovery.
Instead of deploying an external orchestrator such as Temporal, teams can use PostgreSQL itself as the workflow engine. SELECT ... FOR UPDATE SKIP LOCKED builds a concurrent work queue where each row is claimed by exactly one worker.
Idempotency comes from primary-key constraints on step checkpoints, so a crashed worker can safely re-execute without duplicating side effects.
Recovery uses a lease-and-sweeper pattern: workers heartbeat to extend leases, and a periodic sweeper re-enqueues expired ones. Durable sleeps and human approvals become persisted database state, observability collapses to ordinary SQL queries, and the architecture removes an additional stateful component from the stack.
A proposal to replace linear RAM addressing with Z-order layout to cut cache-coherency snoop traffic on many-core servers.
Analytical workloads on modern servers routinely fall short of peak theoretical performance because cores sit idle waiting on RAM.
The author argues the root cause is a forty-year-old architectural assumption that memory is a rigid one-dimensional array, while software deliberately clusters data by column and region.
When 128 cores request scattered 64-byte cache lines, maintaining coherency floods the interconnect with millions of broadcast snoop queries, gridlocking the bus exactly when it should be maximizing data throughput.
The piece models what changes if memory addresses are translated natively into Z-order, or Morton, layout, using the AMD Turin Epyc 9005 with 128 cores across 16 core complexes as the reference topology.
Vector databases enable efficient similarity search for AI applications by storing and querying embeddings.
Vector databases solve the problem of finding semantically similar content by storing embeddings, numerical representations of text, images, and audio, and performing fast similarity searches.
Unlike traditional databases optimized for exact matches, these systems use algorithms like HNSW to enable approximate nearest neighbor search at scale.
Popular open source options include Qdrant, Milvus, Weaviate, Chroma, and pgvector, each suited to different use cases. The technology powers modern AI applications including retrieval-augmented generation, semantic search, and recommendation systems.
Iteration-heavy agent workloads caught database vendors off guard, and requirements for a purpose-built engine remain unclear.
Percona CEO Peter Farkas argues AI caught the database industry off guard and that agentic workloads may eventually need a new kind of database, once anyone works out what those workloads actually require.
He points to iteration-focused patterns in which an agent might make 150 attempts before a person or another system picks the best result, something no human workflow would produce. Of today's options he says plainly that they are not the best we can have, just what exists right now.
MySQL and PostgreSQL are mature and stable, which suits the conservative world of database administration, but they were not designed around these access patterns. His practical advice is to pick technology that can handle the workload today without assuming that choice will remain the right fit.