Blog

Postgres runs your query fast exactly five times. Then it changes its mind.

One prepared statement, twelve EXPLAIN ANALYZE runs on one connection, a plan change on run six, and why a single run could never have shown it.

A prepared statement ran in 274 ms for five executions and 2,319 ms from the sixth, on the same connection in the same minute. One EXPLAIN ANALYZE is a sample of size one and cannot see this; twelve in a row, with the plan kept per run, can. The plan cache mechanism behind it, why psql cannot reproduce it, which drivers trigger it, and the one-line fix. Measured on PostgreSQL 17 using ExoBench with twelve repetitions per connection.

JOIN FETCH May Not Save You

Seven things JPA developers believe about N+1, checked against the SQL that Hibernate and EclipseLink actually prepared

We ran a JPA N+1 detector over Shopizer, Apache Fineract, and Spring PetClinic, then used it to check the standard fixes. A second JOIN FETCH query left the N+1 at 12 statements. Fetching the parent collection left 25. setMaxResults silently lost its LIMIT. Seven beliefs, measured, with the transcripts.

I ran the same query twice and Postgres disagreed with itself

Two EXPLAIN ANALYZE runs on statistically identical data produced opposite plans, 73 heap blocks against 3,449. The margin was 1.5%. Here's the mechanism, measured with ExoBench, and the index shape that takes the coin out of the planner's hand.

The Cheapest Model Per Run is the Most Expensive Per Real Fix

I gave twelve AI models the same slow query, then read the SQL they actually wrote

Twelve AI models, one slow five-table join, and a real Postgres benchmark they could call as often as they liked. Priced with a flat cost per tool call, a 135x spread in token price collapses to a 1.93x spread in what a run actually costs. Then I read the SQL: 37 of 45 runs from the newest models never sped up the query at all, they precomputed the answer into a materialized view. Divide spend by the runs that actually sped up the query and a mid-tier model from the previous generation wins by 2x.

How Fast Are Postgres 19 Graph Queries?

Part 1: What Are They Actually Doing?

Postgres 19 adds SQL/PGQ graph queries. Measured against a PostgreSQL 19beta1 build, the fixed-depth graph query compiles to the exact same plan as a hand-written join, and the variable-depth traversal that graph databases were built for still falls to a recursive CTE. Apache AGE runs the same indexed traversal under a Cypher wrapper. Numbers from ExoBench in local mode.

Your Cheap AI Model Isn't Cheap Once It Starts Calling Tools

When you give an agent something it can check, the cheap ones just keep checking

The usual advice is that a cheaper model saves money. I gave seven models the same slow SQL query, a verifiable benchmark to hit, and counted the tool calls. The cheap chatty models made 10 to 12 calls each stumbling toward a fix; the frontier models found a cleaner one in 3 to 5. Once each tool call carries a real, model-agnostic cost, the cheap model's price advantage erodes, and past a break-even point the expensive model is the cheapest thing in the room.

ExoBench Now Runs in Your Browser

No install, no setup. Paste a slow query at exobench.ai and watch it spin up a real Postgres at 100K, 1M, and 3M row and find a good index.

How One Extra JOIN Reliably Breaks Postgres

Adding a 5-row lookup table to a 9-table billing query flips the plan from 0.3ms nested loops to 467ms hash joins. The cause is join_collapse_limit = 8, a default Postgres has shipped since 2005. SQL Server and MySQL don't have this cliff. Measured across three engines using ExoBench.

Why is my Whale Query 1000x Slower in Prod?

Databases hate skew, each hates it differently

Ten enterprise customers own 80% of the orders. On uniform test data the query runs in ~1ms; on that real skew it runs ~1,000x slower. The fix doesn't transfer between engines: Postgres is rescued by one free session setting, SQL Server can't be touched by it and needs a completely different access-path fix. Measured on Neon and Azure SQL Database using ExoBench.

The Curious Columnstore of SQL Server

Clustered columnstore beats rowstore on inserts and bulk updates. The penalty is dead-row bloat that wrecks reads until you REORGANIZE.

What Does a Covering Index Cost You?

'Covering indexes hurt your writes' is an architectural maxim with no number attached. Here is the number: +28% on INSERTs, +25% on UPDATEs, 1.26x faster reads, and covering wins below ~4,300 writes per analytical read. Measured on PostgreSQL 17 at 2M rows.

Why Does PostgreSQL Skip My Index?

...because your vendor's Cost Model Is from 2002. Since random_page_cost = 4.0 is for spinning disks and hasn't changed in 25 years, setting it to 1.1 cuts this query from 125.98ms to 68.69ms.

JSONB Paths or GIN or Columns?

Columns beat JSONB+GIN at everything except multi-key containment on PostgreSQL 17

The Query Too Simple to Fix

There's a query in every codebase that everyone knows about and nobody fixes. We benchmarked it at five data scales and found a 1,007x improvement hiding behind one composite index.