Get things done, without drama.

boringSQL stands for core belief: truly reliable tech stack. Databases? They've been around for decades and they're battle-tested. SQL? Over 50 years old and still one of the most in-demand programming languages^[1].

PostgreSQL is a universe of its own - decades-tested, still the workhorse. Around it, a generation of analytical and embedded SQL engines is extending the same boring foundations: the relational model, SQL, query planners you can reason about. Master them through practical, hands-on learning that prepares you for real-world challenges.

Want to stay in the loop? Subscribe to the newsletter.

Row locks at the page level

What SELECT FOR UPDATE, FOR SHARE, and a foreign key check actually write into the tuple header. t_xmax as a locker, the infomask bits that say so, MultiXactIds when two sessions lock the same row, and the pg_multixact files that grow behind them.

The unbearable lightness of one more index

Thirty PostgreSQL schemas written by coding agents, loaded and measured. The indexes are competent; the cumulative cost is not.

Read your own writes, off the primary

WAIT FOR in PostgreSQL 19 lets a reader block until the replica has replayed a specific LSN. Measured against sticky routing, sleeps, and synchronous commit, on a replica that misses the write 99% of the time.

The curious case of Google's AlloyDB

AlloyDB offers Postgres wire compatibility with a divergent storage engine. A deep-dive review into HTAP claims, ScaNN limits, adaptive autovacuum, and costs

The DISTINCT in your COUNT

COUNT(DISTINCT) has no combine function, so PostgreSQL can't merge per-worker results: the whole statement drops to one core and a disk-spilling sort. Push the distinctness into a GROUP BY instead and parallel query comes back.

PostgreSQL's MVCC is bad. So is everyone else's.

The critics are right: PostgreSQL's MVCC bloats tables and amplifies writes. Oracle, InnoDB, SQL Server, MongoDB, LSM stores, and etcd answer the same four design questions differently, and each pays for it somewhere else.

The tests passed. The plan didn't.

The rows didn't change; the plan did. RegreSQL 2.0 catches queries that return the right rows the wrong way: plan drift, cardinality error, and regressions verified against production's real PostgreSQL statistics.

VACUUM at the Page Level

Watch a VACUUM cycle with pageinspect, pg_freespace, and pg_visibility: how a dead tuple loses its storage, then its index entry, then its slot, and how the freed space gets reused.

Same rows, different SUM

Same query, same rows, different SUM totals in PostgreSQL. The culprit is parallel aggregation over double precision floats, not a bug. Here is the mechanism and the fix.

The NULL in your NOT IN

A single NULL turns NOT IN into a query that silently returns zero rows, and the planner couldn't optimize around it for as long as anyone can remember, until a PostgreSQL 19 patch.