PostgreSQL extension · pre-optimizer rewrite engine

The query you wrote. The plan you wanted.

HyperQuery/PG sits in front of the planner and rewrites known SQL anti‑patterns into provably equivalent queries — same rows, same order — before the optimizer ever sees them. No ORM changes. No query rewriting in your code.

Request access See how it works

300+

rewrite rules in the library

100×–1000s×

faster, typical for affected queries

lines of application code changed

rule: not_in_nullable → not_exists

▾ incoming query

SELECT o.id, o.total FROM orders o WHERE o.customer_id NOT IN ( SELECT customer_id FROM blocked_customers );

Seq Scan on orders cost=0.00..482910.44

▾ submitted to the optimizer

SELECT o.id, o.total FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM blocked_customers b WHERE b.customer_id = o.customer_id );

Index Scan using idx_orders_customer cost=0.43..1204.81

Same rows. Same order. Verified before it shipped. 401× lower planner cost

Clean data center corridor with glass-panel racks extending to vanishing point — The infrastructure HyperQuery/PG operates on — 0 application changes required

The problem

Most slow queries aren't unique. They're the same handful of mistakes, over and over.

ORMs, query builders, and well-meaning developers produce the same anti-patterns across thousands of codebases. Each one quietly turns a 4ms lookup into a sequential scan — and nobody notices until production is on fire.

Generated SQL hides the cost

ORMs produce technically-correct SQL that the planner can't optimize — a NOT IN here, a wrapped column there.

It works fine in dev

Anti-patterns are invisible at low row counts. They become incidents at production scale, usually during peak traffic.

Fixing it means a deploy

The real fix lives in application code, behind code review, a sprint, and a release — for a query that's costing you right now.

Reviewers can't catch everything

Hundreds of anti-pattern shapes, scattered across every team's queries. No reviewer holds the whole catalog in their head.

The signal

Anti-patterns look like this — every codebase, every ORM, every sprint.

They accumulate silently: a NOT IN here, a wrapped column there. Each one harmless in development. Each one a sequential scan in production.

Dense tangle of colorful network cables representing accumulated SQL anti-patterns

How it works

Five steps, entirely inside Postgres.

HyperQuery/PG runs as a standard extension. It never leaves the database, and it never changes anything your application sends — only what reaches the optimizer.

Colorful programming code syntax highlighting on a dark screen — HyperQuery/PG intercepts every query at the planner hook — before cost estimation begins

Intercept

A planner hook sees every query immediately after parsing — before the optimizer builds a plan.

Match

The parse tree is checked against a compiled library of 300+ known anti-pattern signatures, spanning predicates, subqueries, joins, pagination, and aggregation.

Rewrite

Each match is replaced with the canonical, index-friendly form for that pattern. Several rules can apply to a single query.

Verify

Every rule carries a proof of relational equivalence and a regression suite confirming identical rows, in identical order, before it's allowed into the library.

Submit

Only the rewritten SQL reaches the standard PostgreSQL optimizer. Your driver, your ORM, and your application never know.

The rule library

A sample from the catalog.

Representative rewrites HyperQuery/PG ships with today. Figures below are illustrative order-of-magnitude examples, not a benchmark of any single workload.

PatternBeforeAfterΔ

NOT IN (nullable) → NOT EXISTSpredicate · subquery 482,9101,204401×

text = integer literal → typed literalpredicate · implicit cast 754,210888,570×

OFFSET pagination → keyset paginationpagination 940,4476121,537×

correlated scalar subquery → LEFT JOIN LATERALjoin 1,208,5563,310365×

DISTINCT masking a JOIN fan-out → pre-aggregated subqueryaggregation 322,1081,855174×

UNION (no duplicates possible) → UNION ALLset operation 51,2069,8405×

Costs shown are PostgreSQL planner cost units from representative EXPLAIN output, not wall-clock time. See the full catalog →

Correctness

Same rows. Same order. Every time.

A rewrite that's merely fast but occasionally wrong isn't a rewrite — it's a bug waiting for the right input. HyperQuery/PG treats correctness as the constraint, not an afterthought.

✓Every rule is proven to preserve the result set and row order of the original query.
✓Edge cases — NULL handling, ORDER BY ties, duplicate rows — are part of each rule's proof, not an afterthought.
✓If a rule can't be proven equivalent for a given query shape, it doesn't fire. The original query passes through untouched.

Close-up of server rack hardware with blinking status LEDs

Drop-in

Works with what you already run.

HyperQuery/PG installs as a standard PostgreSQL extension. There's no new SQL dialect, no application redeploy, and nothing for your ORM to know about.

✓One line to install: CREATE EXTENSION hyperquery_pg;
✓Supports self-managed PostgreSQL 13 and later.
✓Every rewrite is logged — see exactly which rule fired, on which query, and why.

Neatly organised blue network patch cables in a server cabinet

See what HyperQuery/PG would rewrite in your workload.

Send us a slow query. We'll tell you which rule catches it.

Request access View pricing