Make every database query faster.
Without changing a line of code.
QueryMesh is an intelligent proxy that sits between your application and your database. It rewrites slow queries, caches repeated reads, and catches N+1 patterns before they reach production - all by pointing your DATABASE_URL at it.
A proxy that thinks before it forwards.
QueryMesh terminates the database connection from your app, runs every statement through a pipeline, and re-issues the optimized version to your real database. Your app sees a normal Postgres connection. Your database sees fewer, faster queries.
Statements are parsed into an AST. The wire protocol is preserved end-to-end.
N+1 patterns become JOINs, redundant SELECTs collapse, missing index hints surface.
Read results are cached with row-level invalidation triggered on writes.
Every plan, every regression, every slow query - exported as OpenTelemetry.
Four things, done well.
No dashboards to learn. No SDK to import. Concrete behaviors that show up the moment you change your connection string.
Auto-rewrites N+1 into JOINs
The most common ORM performance bug, fixed at the wire. QueryMesh detects the pattern across a request boundary and folds N round-trips into one.
-- 1 + N queries from your ORM SELECT * FROM users WHERE active = true; SELECT * FROM posts WHERE user_id = 1; SELECT * FROM posts WHERE user_id = 2; SELECT * FROM posts WHERE user_id = 3; -- ... 47 more
-- What the database actually receives SELECT u.*, p.* FROM users u LEFT JOIN posts p ON p.user_id = u.id WHERE u.active = true;
Read caching with row-level invalidation
Repeated reads served from memory in microseconds. Writes invalidate exactly the rows they touch - no TTL guessing, no stale-read windows.
-- 14,000 identical reads/min hitting Postgres SELECT * FROM feature_flags WHERE org_id = $1 AND name = $2;
-- After QueryMesh [cache HIT] 13,847 served from memory (avg 0.4ms) [cache MISS] 153 forwarded to db (avg 12ms) [invalidate] 2 on UPDATE feature_flags
Pre-prod regression detection
Run QueryMesh in your CI environment and it flags any query that got slower, any new N+1, any plan change - before the PR merges.
# In your CI logs ✗ users#index introduced N+1 (47 queries, was 1) ✗ orders.summary plan changed (Index Scan → Seq Scan) ⚠ products.search p99 +180% (12ms → 34ms)
# After fix ✓ users#index 1 query (no regression) ✓ orders.summary Index Scan restored ✓ products.search p99 11ms
Drop-in: change one env var
No client library. No migration. QueryMesh speaks the native Postgres wire protocol, so every driver, every ORM, every language already works.
# .env (before) DATABASE_URL=postgres://user:pw@db.internal:5432/app
# .env (after) DATABASE_URL=postgres://user:pw@querymesh:6543/app # That's the entire integration.
Numbers from a real workload.
Measured on the open pgbench TPC-B variant against Postgres 16. Workload: 64 connections, 30-minute run, EU-Central. Reproduce it yourself - the harness is open source.
Two minutes. One env var.
QueryMesh is a wire-protocol-level proxy, so the integration is identical regardless of language or framework. Pick yours below.
# 1. Run QueryMesh docker run -d --name querymesh \ -p 6543:6543 \ -e UPSTREAM_DATABASE_URL=$DATABASE_URL \ ghcr.io/acadable/querymesh:alpha # 2. Point your app at it export DATABASE_URL=postgres://user:pw@localhost:6543/app # That's it. No SDK, no migrations.
Why not just pgBouncer?
pgBouncer is excellent at one thing: pooling. QueryMesh assumes pooling and adds the things you currently bolt on with five tools and a Grafana dashboard.
Things people ask first.
Join the QueryMesh alpha.
We're onboarding teams one at a time so we can actually help when things break. Tell us where to send the binary.