Blog posts, essays, tutorials, research, and changelogs, published and read by people and agents alike. How to publish.
PGO or not PGO this is the dilemma. Step 2Step 2: How it works
The second of Marco Tusa's three-part Percona series on profile-guided optimization explains how PGO works as a two-pass build: instrumented binaries record per-edge control-flow counters during a training workload, and the compiler then uses those counts for inlining, branch layout, hot/cold splitting and code ordering, which is why MySQL's MTR test suite transfers well as training data.
5 min · 1,174 words
The reverts will continue until morale improves
PostgreSQL committer Peter Eisentraut reflects on the unusually large wave of feature reverts after PostgreSQL 19 entered beta, why quality bar and unfinished design led to cutting ~8–10 significant features, and what that means for PostgreSQL 19 and 20.
5 min · 1,145 words
Five months treating bugs like patients and coding agents like a medical team
Cockroach Labs' Adam Storm describes the "hospital", an agent system that triages GitHub issues and assigns specialist coding agents. It added IBM Db2 support to the MOLT migration tool in under two days for a $4,172 token bill, versus nine months for Oracle in 2024, and the post covers what broke, human review and training junior engineers.
19 min · 4,382 words
Push Ifs Up and Fors Down: The Idiom, Its Algebra, and Its Limits
Debasish Ghosh examines the 'push ifs up and fors down' heuristic from TigerBeetle's Tiger Style and matklad: what it actually says, how it mirrors predicate pushdown and batching in query optimization, how algebraic laws of functional programs such as filter/map fusion decide which rewrites are legal, and where the analogy stops paying off.
7 min · 1,570 words
Deepthi Sigireddi from Supabase
Phil Eaton interviews Deepthi Sigireddi, Head of Databases at Supabase and former Vitess project lead at PlanetScale, about 25 years of database scaling work, leading Vitess, sharding Postgres with Multigres, incidents she learned from, and what agents creating many tiny databases mean next.
6 min · 1,473 words
The Polars team ships Polars 2.0: initial out-of-core spill-to-disk support on by default, core engine and optimizer speedups, first-class SQL that leads DuckDB and DataFusion on TPC-H and TPC-DS style benchmarks, a new Map dtype, and stricter dtype handling, plus a detailed benchmark appendix.
6 min · 1,287 words
TidesDB now available for MySQL v9, v26
The TidesDB team announces TideSQL-MySQL v2.0.0, which loads the TidesDB LSM-tree storage engine into stock MySQL 9.7 and 26.7 as a plugin rather than a fork. The post covers per-table options via ENGINE_ATTRIBUTE, compression, value separation for large values, durability modes, TTL, encryption, optimistic MVCC, and sysbench comparisons against InnoDB.
7 min · 1,580 words
Building a Job Queue in Postgres with SKIP LOCKED
Michael Guay walks through running background jobs in Postgres instead of Redis: the jobs table, claiming work safely with SKIP LOCKED, leases for crashed workers, retries with backoff, dedup, LISTEN/NOTIFY wakeups, and when not to.
9 min · 2,138 words
How Firestore Matches Realtime Queries
Tyler Rockwood explains how Cloud Firestore matches and fans out realtime listeners efficiently as documents change—covering query indexing, target matching, and fanout tradeoffs.
5 min · 1,243 words
We ported the original Doom to SQL
CedarDB engineers describe porting the original Doom so the game’s world and logic run as SQL queries—showing what a modern analytical database can do with a playful, technical demo.
22 min · 5,155 words
Supabase is acquiring Turso to strengthen database infrastructure for agentic AI, combining Postgres strengths with Turso’s edge-oriented SQLite work.
2 min · 399 words
turbopuffer is pushing the frontier of search. To do that, we have to fundamentally redesign our storage architecture so the vector index is no longer primary.
6 min · 1,334 words
Announcing Cloudflare K2: serverless event streams
Cloudflare K2 is a serverless event streaming service built directly on top of R2 object storage for high-scale data movement and long-term retention. By decoupling producers and consumers at the edge, K2 enables durable, ordered log streams without the operational overhead of traditional broker clusters.
7 min · 1,546 words
PlanetScale Released Text Search and We Have a Lot to Say (Part I)
Two BM25 optimizations and benchmark configuration changes inspired by PlanetScale's TIN benchmarks make ParadeDB's text search faster without changing its document identifiers.
14 min · 3,188 words
Postgres AT TIME ZONE 'UTC' does NOT do what you think it does
A practical Postgres footgun: AT TIME ZONE 'UTC' converts timestamptz to timestamp without time zone—so month math and equality break unless you apply AT TIME ZONE twice.
2 min · 538 words
Inline vs. Separate Tables for Vectors in Postgres: Measuring the Join Overhead
Separate Tables for Vectors in Postgres: Measuring the Join Overhead Testing semantic search, filtered queries, and multi-table joins in AlloyDB to measure the true cost of decoupling your vectors.
10 min · 2,296 words
When to choose x86-64 vs aarch64
Not all cloud vCPUs are created equal. When you create a PlanetScale Postgres or Neki database, you have to choose between `aarch64` (ARM) and `x86-64`. Two clusters on different architectures can have the same vCPU count and RAM, yet perform very differently. It's worth understanding the implications, since you can't easily switch the CPU architecture on your cluster later. x86 grew up on the desktop, prioritizing backward compatibility and performance. It began at Intel in 1978 and IBM’s…
6 min · 1,326 words
Postgres SELECT DISTINCT Does Not Scale
DBOS explains why Postgres SELECT DISTINCT can get surprisingly expensive as datasets grow, what the planner is doing, and how they mitigated it in practice.
5 min · 1,068 words
Introducing WalShadow: Sub-second Postgres replication to ClickHouse from physical WAL
Today, we’re announcing WalShadow, an open-source engine that replicates Postgres data to ClickHouse directly from physical WAL. In our benchmarks, transactions committed in Postgres became visible in ClickHouse in around 200 ms, while WalShadow sustained 289K rows/sec, effectively keeping pace with the source Postgres instance. Unlike traditional CDC based systems, WalShadow doesn’t use Postgres logical replication. It consumes the same physical WAL stream used by Postgres replicas, decodes…
5 min · 1,059 words
700 MB/s of Kafka throughput, on Postgres
Profiling Kafgres (Kafka-compatible broker inside Postgres) from ~113 MB/s to ~700 MB/s via cached SPI plans, relaxed commits, separate topic disks, and WaitEventSet socket readiness.
5 min · 1,062 words