ClaudeBuild a SaaSLevel 4: Multi-tool systems

How Do You Design a SaaS Database With Claude?

Before any screens, have Claude draft the schema from your spec, including who owns each row. Then ask it to attack the design with changes you might make next year. You review and approve the schema before generating code on top of it, since this is the part of a SaaS that's hardest to change later.

Prompt to copy 
Read SPEC.md. Design the database for v1 in [Postgres / your database].

Give me:
1. A table list, with columns, types, keys and constraints
2. Which table each customer's data hangs off, and how one customer is kept from seeing another's rows
3. Which columns need indexes, and for which query from the spec
4. Money and time rules: how amounts and time zones are stored

Then attack your own design. For each of these future changes, say what would break and how hard the migration would be: [add team accounts], [add annual billing], [let a user delete their account].

Don't write migrations yet. Stop for my review.
Cheap to change laterCostly to change later
  • A screen
  • An empty table
  • A table with live data
Rule of thumb, not a vendor figure: a screen change is only code, while live data needs migrations and backfills.
  1. 1List entities from the spec
  2. 2Claude drafts the schema
  3. 3Attack it with future changes
  4. 4Write migration, then build
Rule of thumb, not an Anthropic chart: the schema is the expensive thing to change later, so it gets reviewed before any screens.

Try it now

  1. 1In Claude Code, paste the prompt above and name two changes you think might really happen.
  2. 2Read the attack section first. Decide which of those changes you'd pay to make easy now, and which you'd leave.
  3. 3Approve the design, then ask for one migration and a test showing one customer can't read another's rows.
  4. 4You'll know it worked if that test fails when you remove the isolation rule. If it still passes, it isn't testing isolation.

Use it when

Use it after the spec and before the first feature, and again before any change that adds a new relationship, such as moving from single users to teams.

Skip it when

Don't spend time on it for a prototype with fake data, or for a small internal tool with one table. Also don't over-design for scale you don't have. Ask Claude to justify each extra table against a feature in your spec.

Why it works

Rule of thumb, not a vendor figure: once data is live, a schema change means migrations and backfills, while a screen change is only code. Claude is useful here because it can quickly list what a design makes hard, but it'll accept what you give it, so you have to ask. Tenant isolation is the point not to leave for later. PostgreSQL's row security docs say that once it's enabled on a table, normal access must be allowed by a policy, and with no policy the default is deny, so no rows are visible or changeable.

Example

For an invoicing tool, Claude drafts accounts, clients, invoices and invoice_lines. You ask what happens if you add teams next year. If invoices hangs off a user instead of an account, every row has to be reassigned later. So you change that now, while the table is empty, and store amounts as integer cents with a currency code.

Going further

Row security has a trap that AI-generated tests often miss. PostgreSQL's docs say table owners normally bypass it, and superusers and roles with BYPASSRLS always do. If your app or test connects as the owner, your policies may never run, and the test still passes. Use ALTER TABLE ... FORCE ROW LEVEL SECURITY to subject the owner to policies, and test with a normal role. To keep Claude away from production while it works, add a deny rule, such as Bash(psql *). Claude Code's docs say deny rules hold in every permission mode.

Common mistakes

  • Letting the schema grow as a side effect of building screens, with no point where you review it.
  • Adding a tenant column later, when every query and existing row has to change.
  • Testing isolation while connected as the table owner, so row security is bypassed and the test proves nothing.
  • Asking Claude "is this schema good?" Name specific future changes instead, or it has nothing concrete to test against.

Sources

Checked 6 November 2026. Products change often, so confirm details with the vendor.

Related

Workflow How Do You Build a SaaS With Claude, One Slice at a Time? Best practice Should Claude Write Your SaaS Login and Billing Code? Best practice How Do Types Make Claude's Code More Accurate? Technique How Do You Build Something in a Claude Artifact?

Beyond the course

Glossary AI agent Pricing guide Claude pricing, plans and models