As of 13 August 2026, AI can only partly create a database schema for your business app.

What to actually do

1. Hand it to a person

   The route this page recommends

   A person who owns the outcome does this end to end, worth it when the failure is dear.

2. Use a tool built for this

   Second choice

3. Do it yourself

   The distant third

   A chat interface, chat-fluent skill, and roughly 1 hour until you can act on the result.

   How to actually do it

   1. Open a requirements document and write the app description, user roles, workflows, records, business rules, expected scale and data types listed in the prompt.
   2. Check the current application technology and database engine in the project documentation, then paste those details into the prompt or mark them as undecided.
   3. Paste the completed prompt into an AI chat and ask it to produce the schema, unanswered questions, SQL, permissions outline and test cases in the requested order.
   4. Open the generated entity relationship overview beside the requirements document and mark every entity, relationship, status and rule that is unsupported or unclear.
   5. Paste each unresolved item back into the chat with your decision and ask for the SQL, indexes, constraints, permissions and migration steps to be regenerated without changing unrelated parts.
   6. Run the SQL in a disposable development database using your chosen database engine, then run the generated tests for duplicates, invalid transitions, deletion, concurrent updates and unauthorised access.
   7. Ask a developer or technical lead to compare the final schema and migration plan against the application code, backup and recovery plan, security model, privacy requirements and expected workload before production use.
   8. Commit the approved schema and migration files to version control, apply them first to a staging database, and record the rollback plan before sending them to production.

   Prompt

   Design a production-ready relational database schema for this business app. Use the requirements below and do not invent business rules. Where a requirement is missing or ambiguous, list a clear question instead of choosing silently.
   
   App description: [describe the app]
   Users and roles: [list each user type and what it can do]
   Core entities: [list customers, orders, bookings, products or other records]
   Workflows: [describe how records are created, changed, cancelled and deleted]
   Important rules: [state uniqueness, status changes, ownership, payment, retention and audit requirements]
   Expected scale: [give known or expected users, records and growth, or write unknown]
   Personal or sensitive data: [list any data stored, or write none]
   Technology: [database engine and application framework, or write undecided]
   
   Return:
   1. A short assumptions and unanswered-questions section.
   2. An entity relationship overview in plain English.
   3. The complete SQL DDL for the chosen database engine, including primary keys, foreign keys, data types, NOT NULL rules, unique constraints, check constraints and indexes.
   4. A migration strategy for applying this schema to an empty database and to an existing database.
   5. A permissions and data-access outline for each role.
   6. Seed data only where it is clearly labelled as example data.
   7. Test cases covering normal records, duplicate records, invalid state changes, deletion, concurrent updates and access by the wrong role.
   8. A section called "What a developer must verify" covering performance, backups, recovery, security, privacy, retention, audit logging and future migrations.
   
   Prefer simple designs over unnecessary abstraction. Explain every non-obvious choice. Do not include secrets, real personal data or fabricated performance figures.

   Open it prefilled in ChatGPT or Claude, or copy it into Gemini, which takes no prefill link.