Design a schema on its data, not a hunch — model the entities and relationships, set the constraints that protect integrity, plan indexes around real queries, then document the schema and migration.
A data model is the hardest thing in an application to change later — every query, every feature, and every migration inherits its shape. Get the entities or the relationships wrong and you pay for it in joins, workarounds, and risky migrations for the life of the product. 'Ask AI for a schema' gives you a confident set of tables that ignores your access patterns, skips the constraints that protect integrity, and indexes nothing. This workflow designs the model on its real data: the entities and how they relate, the constraints that keep it honest, the indexes the actual queries need, and a documented migration — before the schema is set in production.
Each step uses an existing NewPrompt tool, pre-filled by a matching resource. Open the resource to read it, or jump straight into the tool with the inputs ready.
Model the entities and relationships
Start with the data, not the tables. Anchor the model as an architect and map the real entities, their attributes, and how they relate — one-to-many, many-to-many, the optional versus the required — before anything becomes a column.
Set the constraints that protect integrity
Decide what keeps the data honest: keys, uniqueness, nullability, foreign-key rules, and the invariants the application must never violate. Work them one decision at a time — the constraints are what stop bad data, not the code on top.
Plan indexes around real queries
Indexes follow access patterns, not guesses. Lay out the queries the app will actually run, then plan the indexes that serve them — and notice the ones missing that would turn a feature into a table scan.
Document the schema and migration
Capture the final model and the reasoning — why the relationships are shaped this way, what the constraints protect — plus the migration plan to get there, so the build and future-you start from a documented design.
A database schema designed on its real data — entities and relationships modeled, integrity constraints decided, indexes planned around the actual queries, and the whole thing documented with a migration plan — so you build on a deliberate model instead of a confident guess you'll be migrating around for years.
SQL optimization speeds up one query against a schema that already exists. This workflow designs that schema first — modeling entities and relationships, deciding integrity constraints, then planning indexes around the queries the app really runs. Optimization is what you do later, inside the model these four steps produce, not a substitute for it.
Usually the schema first — the entities, relationships, and constraints this workflow models are the data your API exposes, so shaping them well gives the interface something honest to sit on. Run this to document the schema and migration, then hand that model to the AI API Design Workflow to design the contract over it.
Only if you let it. The point of the steps is to force the model onto your real entities, access patterns, and invariants — so the schema fits your domain instead of a textbook example. The modeling calls stay yours.
A documented schema built on real data: the entities and relationships mapped to your domain, the keys and integrity constraints decided and justified, indexes planned against the queries the app runs, plus a migration plan and the reasoning behind the shape. Step four captures all of it so the build starts from a deliberate design.
Work the four steps in order in your own AI tool: model the entities and relationships, set the constraints that protect integrity, plan indexes around real queries, then document the schema and migration. Each step links a prompt and resource; you run the prompts and own every modeling decision. Budget 45 to 75 minutes.
The data your application handles and the queries it will run. Step one models entities from that domain, and step three plans indexes against those real access patterns — so the more you know about what the app reads and writes, the sharper the schema. You don't need existing tables; this designs them before the migration.
Complete build journeys that include this workflow as a stage.
The full path from idea to a shipped SaaS MVP — define and scope the requirements, design the architecture, API, and data model, then build it reviewed, tested, secured, cost-controlled, and deployed.
The full path to a backend you can put clients on — define the requirements, design the architecture, API contract, data model, and access control, then build it reviewed, tested, secured, and shipped.
The full path to an applicant tracking system — model jobs, candidates, and hiring stages, generate job descriptions and screening prompts, parse résumés into structured data, design the hiring API, set roles, review security, then ship.
The full path to a booking and reservation system — model resources, availability, and reservations, design the booking API, set customer accounts, wire calendar and notification integrations, design the UI, review security, then ship.
The full path to an inventory management system — model products, stock, locations, and movements, design the inventory API, set roles, plan supplier and POS integrations, design the UI, review data-integrity risks, then ship.
The full path to an internal admin panel — model the operational data it manages, design the management API, define RBAC and admin permissions, design the tables and forms, review risky admin actions, then ship to trusted internal users.
The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.
The full path to a CRM that fits your sales process — define the contacts, deals, and pipeline, model the data that ties them together, then build the roles, integrations, and pipeline UI, and ship.
The full path to a store you own end to end — model the catalog and orders, design the storefront and checkout, add customer accounts and payments, then secure it, test it, and ship.
The full path to a pipeline that moves data without corrupting it — design the ingestion and transforms, extract and structure the sources, gate the quality, store it, then deliver and ship it monitored.
Four sentences of requirements go in, a confident schema comes out — and it quietly decided three things nobody decided. Here's how to turn real domain rules and access patterns into a reviewable database schema, with the modeling gaps named as open questions instead of guessed.
Design access control before you build it, not after a breach — choose the authentication approach, model the roles and permissions, review the design for gaps, then document the identity model.
Design a system's architecture on its real trade-offs instead of a confident diagram — put the model in an architect's seat, work the decisions one at a time, and write down the why.
Design an API on its contract instead of discovering it endpoint by endpoint — model the resources, design the endpoints and payloads, pin the contract, then review it before code locks it in.
Design a pipeline that moves data without corrupting it — map the sources and ingestion, design the transformation stages, set validation and quality gates, then document the pipeline and monitoring.