Workload Twin

Your production planner, without your production data.

The twin is an empty copy of your schema loaded with production's statistics. QueryInsights tries index changes on it and asks your database's own optimizer what every top query would cost.

Productionyour database, untouchedReal dataReal trafficStatistics viewsread-onlyschema · sizescolumn statsrepeats until no change helpsWorkload Twin0 rows · production's statistics1Plan your top N queries2Try a change set3Re-cost the whole workload4Reject any regressiononly if provenProven change setCREATE INDEX …−97.7% workload cost0 queries slowerplans before / after

Swipe to see the whole diagram →

  1. 01

    Snapshot, read-only

    QueryInsights reads the schema with constraints, table and index sizes, column statistics and planner settings from production. It never writes there and never copies a row.

  2. 02

    Load the twin

    An empty database on a server QueryInsights runs, at production's major version, receives those statistics. Table files are sized to production's page counts without using disk, so the planner sees a database as large as yours.

  3. 03

    Plan the real workload

    Your top patterns by total time and by calls are planned on the twin, weighted by how often each one actually runs. That is the baseline.

  4. 04

    Search change sets

    Candidate indexes come from what the planner does with each query: its filters, join keys, and sort and group keys. A search adds, merges and prunes them, and an AI agent can experiment through tools that only the twin answers.

  5. 05

    Prove or reject

    A change set is proven only if total cost falls, no query's plan gets more expensive, and every new index is used. Anything else is discarded, whatever the AI suggested.

Accuracy

Measured, not promised.

Each engine was tested against a seeded production database and its twin, query by query. The scripts that produce these numbers ship with QueryInsights.

PostgreSQL 16–18

Available

20/20 plans, 20/20 costs within 10%

Hypothetical indexes via HypoPG on the twin only. Nothing is installed on production.

CockroachDB 24.3

Validated, in progress

8/8 costs identical

Production statistics injected with INJECT STATISTICS into an empty twin cluster.

MySQL 8.4

Validated, in progress

4/9 costs within 10%

Full scans match. Indexed lookups read the twin's empty index, so MySQL reports plan shape until a correction ships.

Then we applied it to production.

Average workload latency went from 176 ms to 1.01 ms under the same load.

QueryTwin predicted (planner cost)Production measured (mean time)Faster
Events for a user, newest first36,416.84.5118.3 ms0.073 ms1,621×
Orders for a user22,743.789.973.6 ms0.052 ms1,415×
Pending orders, newest first41,4125,420.450.8 ms0.022 ms2,309×
Users by country and plan4,8702,196.433.3 ms2.3 ms14×
Order by id (already indexed)8.2unchanged0.089 ms0.020 msno change predicted
Update order status8.2unchanged0.13 ms0.063 msno change predicted
Seeded PostgreSQL 16 (1.5M orders, 2M events, skewed user activity), same pgbench load before and after applying the four indexes the twin proved. The two queries the twin predicted would not change stayed under a millisecond. The predicted ranking of savings matched the measured ranking (Spearman 0.89).
Why not a data sample?

Statistics beat a 1% copy of your data.

The optimizer chooses a plan from how big a table is and how its values are spread. A 1% sample looks like a small database, so the optimizer plans for a small database. The empty twin believes it is production-sized, because its statistics say so.

PostgreSQL 16, same dataEmpty twin + statistics1% data sample
Plan shape matches production20 of 20 queries1 of 7 queries
Costs comparable to productionYes, within 10%No, about 70× smaller
Copies production rowsNoYes, real customer rows
Load on productionCatalog reads, millisecondsScans 1% of every table
Disk on the twinAbout zero1% of production
Growth forecasts (2×, 10×)Edit the statisticsNot possible
Setup

One more field per database.

Run the twin image at your production major version and point QueryInsights at it. Workload advice for that instance is then found and proven on the twin. Production keeps its existing read-only role.

  • • PostgreSQL 16 or newer, with pg_stat_statements
  • • The twin runs Postgres plus HypoPG; nothing is installed on production
  • • Statistics include sample values, so the twin is kept as private as production
Read the setup guide
podman build --build-arg PG_MAJOR=16 \
  -t queryinsights-twin:16 local/twin

QUERYINSIGHTS_POSTGRES_INSTANCES='[{
  "name": "orders-db",
  "dsn": "postgres://queryinsights:…@orders-db:5432/app",
  "twin_dsn": "postgres://postgres:…@qi-twin:5432/postgres"
}]'
Early access

Want to see what's slowing your database?

QueryInsights is in early access. Tell us a little about your workload and we'll be in touch.

Request Early AccessSee Why It Matters

Or email us at bhargav.akhani@queryinsights.dev