Blog

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.

Why Does PostgreSQL Skip My Index?

...because your vendor's Cost Model Is from 2002

What Does a Covering Index Cost You?

Architects say 'covering indexes hurt write performance.' How much? Nobody ever has the number. With ExoBench you do!

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.