N+1 elimination
The loop that queries once per row becomes one join or one batched load — usually the single biggest win in an AI-generated app.
Database & queries
Queries that stay fast once the table gets big
AI tools write queries that work. They don't write queries that work at a million rows. We find the ones that will melt first and fix them at the source.
In short
Database optimization means finding the queries that dominate your load — usually N+1 loops, unindexed filters, and unbounded selects — and fixing them at the source with batching, indexes and pagination rather than papering over them with caching. In AI-generated apps the same handful of patterns appear almost every time. Gen2Prod profiles your real query log, fixes the expensive paths, and adds the constraints and row-level security a prototype schema is usually missing.
- Typical timeline
- 3–5 days
- Common stacks
- Postgres, Supabase, Prisma, Drizzle, MySQL
- Also covers
- Indexes, RLS policies, constraints, migrations
- Best for
- Apps slowing down as the data grows
You probably need this if…
- One page fires two hundred queries to render a list.
- It was instant at a hundred rows and it crawls at fifty thousand.
- Nobody has ever run EXPLAIN on the slow query.
- There are no indexes beyond the primary keys.
- Row-level security is switched off because turning it on broke the app.
What database & queries covers
Indexes that match your filters
Chosen from the query plan rather than from guesswork, and benchmarked before and after on production-shaped data.
Pagination & limits
Unbounded selects get cursors and caps, so one power user with a lot of data can't take the app down.
Schema & constraints
Foreign keys, unique constraints and sane defaults — the guardrails that stop bad rows from ever being written.
Row-level security done properly
Policies that genuinely enforce tenant isolation, tested with the roles they're meant to stop rather than switched off to make things work.
Safe migrations
Reversible, reviewed, and run without a maintenance window.
How we run it
- 1
Profile the real load
We pull the slow-query log and the plans behind it, so the work is ranked by measured cost rather than by suspicion.
- 2
Fix at the source
Batching, indexes and pagination first. Caching only where the query genuinely cannot be made cheap.
- 3
Prove the difference
Benchmarks on production-shaped data, before and after, attached to the pull request.
What you get back
- The slow-query list, ranked, with plans before and after
- Indexes, constraints and migrations shipped and reversible
- RLS policies that pass a test written to break them
- A short schema note your next developer can actually read
Tools we reach for
- PostgreSQL
- Supabase
- Prisma
- Drizzle ORM
- EXPLAIN ANALYZE
- Connection pooling
- SQL migrations
Database & queries — questions we get asked
How do I know if I have an N+1 query problem?
If rendering one list page fires one query for the list and then one more per row, that's an N+1. It's invisible at ten rows and fatal at ten thousand. The query log makes it obvious in about a minute, and it's the first thing we look for.
Do you work with Supabase specifically?
Yes — it's the stack we see most often from Lovable and Bolt projects, and we cover the parts those tools skip: row-level security policies, indexes, and edge functions. We build on Supabase ourselves.
Will you need access to our production database?
No. We work from a schema dump plus an anonymised or synthetic dataset of production shape. Read-only access to a replica is welcome if you'd rather, but it's never a requirement.
Do we need to switch to a different database?
Almost certainly not. Postgres handles far more than most apps ever ask of it — the problem is nearly always the query, not the engine.
Often paired with
All servicesSecurity hardening
An API key in the browser bundle. Authorisation checked only in the UI. It's the same short list nearly every time, and every item on it is exploitable in an afternoon.
Learn moreDeploy & CI/CD
Deploys should be boring: push, watch it go green, roll back in one click if it isn't. We set that up once and you stop thinking about it.
Learn moreMonitoring & alerts
The worst way to learn about an outage is a support email. Monitoring is a couple of days of work and it changes how the whole thing feels to run.
Learn more