Of all the invisible decisions your AI tool made while building your app, the most consequential is one you have probably never looked at: the shape of your database. The schema, which tables exist, how they relate, what enforces their correctness, was generated in seconds, in service of whatever feature was being prompted, and it has been quietly load-bearing ever since.
Schemas are a time bomb with a specific fuse: they work perfectly at demo scale and degrade with data volume. Ten users, instant. Ten thousand users, and pages take seconds to load, reports time out, and worst of all, the data itself starts going quietly wrong.
What AI-generated schemas get wrong
Flat, duplicated structure. Prompted feature by feature, AI tools tend to give each feature its own convenient table with its own copy of shared data. The user's name and plan end up stored in four places. It works, until a customer changes their email and it changes in only three of them. Now your app contradicts itself, and which copy is true depends on which page you are looking at. Database design solved this decades ago, normalisation: shared facts live in one place and are referenced everywhere else, so they cannot disagree. It is exactly the discipline a fastest-path generation skips.
No relational enforcement. In a well-built database, the database itself refuses impossible states: an order cannot reference a customer that does not exist (foreign keys), a payment cannot be negative, an email column cannot hold two accounts with the same address (constraints). AI-generated schemas frequently declare none of this, leaving correctness entirely to application code, which, as we cover throughout this series, only handles the paths someone prompted for. The result is orphaned records, duplicates and impossible values accumulating silently, each one a future support ticket or a wrong invoice.
No indexes. An index is what lets a database find rows without reading the entire table. Without one, every "show this user's orders" query is a full scan, unnoticeable at a thousand rows, ruinous at a million. Missing indexes are the single most common reason an app that "just worked" becomes an app that "suddenly got slow", because the slowness arrives with data growth, long after the schema was generated.
No migration discipline. Schema changes in AI-built apps often happen by direct edit: a prompt alters production tables and the previous shape is simply gone. Professional workflows use migrations, versioned, reversible scripts, so every change is recorded, testable on staging, and undoable. The difference is invisible until the day a change goes wrong, which connects directly to the incident we documented in the backups article.
Three checks you can run today
Hunt for duplicated facts. Look at your tables (Supabase and similar dashboards show them plainly) and ask: is any fact, a name, an email, a price, a status, stored in more than one table? Each duplication is a future inconsistency with a date you cannot predict.
Test the guardrails. Try, in a staging copy, to insert an obviously invalid row: an order pointing at a user ID that does not exist, a duplicate email. If the database accepts it, your correctness has no enforcement layer, and only luck has kept the data clean.
Ask the specific question. Ask your AI tool: list every query this app runs against tables that will grow with users, and tell me which of them are supported by an index. Then: list every foreign key relationship in this schema, and every relationship that exists in the logic but not in the schema. The gap between those two lists is the bomb.
Defusing it
The fix is a schema review and a set of migrations, not a rebuild: consolidate duplicated facts, declare the missing foreign keys and constraints (fixing the orphaned data they reveal), add indexes where the query list demands them, and adopt migration files for every change from now on. It is days of focused work, and it is dramatically cheaper before the data grows than after, because every week of new users pours more concrete around the current shape.
If this sounds familiar, you are not alone
Nobody prompts for a data model, which is exactly why it is the layer most worth an expert look before scale arrives.
That is what our Production Readiness Audit is for. We review your database schema and integrity constraints, indexing against real query patterns, row level security, migration and backup practice, access control, and error handling. You get a plain-English report you own outright, every issue prioritised, delivered within 5 business days of getting access.
Book a 20-minute call and we will tell you honestly whether it is worth doing.
