Review a database schema before it goes live

Paste your tables and the main queries your app runs, and this prompt reviews the schema like a database architect. It checks keys, types and indexes, and suggests fixes before a painful migration is needed.

text-code-database-schema-review — claude — 92 words

Act as a database architect. Review this schema for [DATABASE, e.g. PostgreSQL].

What the app does: [SHORT DESCRIPTION, e.g. a booking app for clinics]
Schema:
[PASTE CREATE TABLE STATEMENTS OR ORM MODELS]
Main queries it must handle: [e.g. find free slots for a doctor on a date]
Expected size: [e.g. 50 clinics, 2 million bookings a year]

Check keys, relations, data types, nullability, indexes, naming, and anything that will hurt at scale or make migrations painful. Give each issue a severity, and show the corrected SQL. Suggest indexes for the main queries.

Edit in the builder Copy & open Claude ↗Copy & open ChatGPT ↗Copy & open Gemini ↗

List your real queries. A schema can only be judged against the questions it has to answer.

Get a better result

What you will get

A review of your schema with each issue graded by severity, covering keys, relations, types, nulls, indexes and naming, the corrected SQL for each, and suggested indexes for the queries you listed.

Why it works

A schema is only good or bad for a given set of questions, so the prompt asks for your real queries, as the tip says. The expected size changes the advice: a design that is fine at a thousand rows can hurt at millions. Asking for severity and corrected SQL turns a wall of comments into a ranked to-do list you can work through.

Common mistake

It suggests an index on nearly every column.

Fix: Ask it to justify each index with one of your listed queries, and to mention the write cost of every extra index.

Also watch for

Money is stored as a floating point number. Ask for a decimal type or whole numbers of the smallest unit, such as paise or cents, and check every price column.
Times have no time zone. Ask it to check every date and time column and say whether it should store UTC with a zone, especially for bookings.

Try a variation: plan for a big table

Ask what changes when your biggest table reaches ten times its size, and which choices would be painful to reverse then.

Still not right? Reply with this

Write the migration for these fixes, safe to run on a live table, and show EXPLAIN for my main query before and after.