10 Tables Every SaaS Needs:The Database Blueprint

The 10 tables every SaaS needs power 90% of business apps: organizations, users, organization members, your main entity, categories, relationships, activity log, files, notifications, and settings. You don't reinvent the database — you clone this structure, rename a few things, and ship. This is the full blueprint, how the tables connect, and the copy-paste prompt that makes AI build all of them properly.

A table is nothing scarier than a structured spreadsheet: each row is one thing (a task, a contact, an invoice), each column is information about that thing. If that's news to you, start with databases explained for non-technical founders and come back. The point of this post is simpler: you don't need to understand databases to design one. You need to know which tables to create — and they're almost the same for every SaaS.

The 10 tables every SaaS needs

Bad database design breaks your app when you scale. Good database design means your app just works. Here's the foundation:

Notice how little of this is specific to your idea. 90% of your database is the same as every other business app; 10% is your unique business logic. Start with the 90%, build the 10%, ship your product.

The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →

How the tables connect

Think of an apartment building. Organizations are the building register — the list of tenants. Users are the residents. Organization members is the apartment directory that says John lives in apartment 5 and Sarah in apartment 12. From there, the chain is logical: an organization has many of your main entity (tasks, contacts, invoices), each of those can have files attached, every action generates an activity log entry, and important events create notifications.

A concrete example — a simple CRM needs: organizations (your customers), users (people who log in), organization members (John works at one company, Sarah at another), contacts (the CRM records), contact tags (hot lead, cold lead, customer), an activity log (every interaction), files (documents attached to contacts), notifications (alerts when a contact takes action), and settings (preferences per organization). That's it. Nine tables. A complete CRM.

This is also why designing tables before building screens works so well — the whole argument of database-first development. Screens change weekly. This structure barely changes at all.

The tables you don't need at launch

Just as important as the ten you build: the ones you skip. Add these later, when you actually need them:

• Billing and subscriptions — add when you're ready to charge
• Teams — add when organizations get big
• Integrations — add when connecting to other tools
• Reports — add when users need analytics
• Webhooks — add when building an API
• Audit logs — add for compliance and security requirements

The rule: start small, add tables as you need them. The database is one layer of a bigger picture — the 18 systems every SaaS needs maps the rest — but tables are where you start, because everything else sits on top of them.

The copy-paste prompt that builds all 10

You don't write this SQL yourself. You hand AI the blueprint and the quality requirements in one prompt:

Create these database tables for a multi-tenant [your app type]:

FOUNDATION: 1. organizations (id, name, slug, settings, tier, is_active, created_at, updated_at) · 2. users (handled by Supabase Auth) · 3. organization_members (organization_id, user_id, role)

CORE FEATURE: 4. [your main entity] with organization_id, your specific fields, audit columns

SUPPORTING: 5. categories (for organising [your main entity]) · 6. files (attachments) · 7. activity_log (tracking all actions) · 8. notifications (user alerts) · 9. settings (preferences)

Requirements: every table needs organization_id (except users) · add indexes on all foreign keys · enable Row-Level Security · use soft deletes (deleted_at column) · add audit columns (created_at, created_by, updated_at, updated_by)

Show me the complete SQL migration.

AI will generate the tables, properly connected, multi-tenant, production-ready. The requirements block is not optional decoration — organization_id on every table and Row-Level Security are what stop Customer A from ever seeing Customer B's data.

The minimum to ship

Before you start building features, verify you have: an organizations table, users (Supabase provides this), organization members, your main entity, at least one way to organise items, an activity log, and notifications. With these 7 minimum tables, you can build and ship. Add the rest as you grow.

Most founders spend weeks agonising over database design as if their app were a unique snowflake. It isn't — and that's the good news. The foundation is a solved problem. Clone it, customise the 10%, and spend your energy on the part only you can build.

12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →

Frequently asked questions

Do I really need all 10 tables before launching?

No — 7 are the minimum: organizations, users, organization members, your main entity, one way to organise items (categories or tags), an activity log, and notifications. Files, relationships, and settings can arrive with the features that need them. Billing, teams, integrations, reports, and webhooks come later still.

What does "multi-tenant" mean and why does it matter?

Multi-tenant means many customers share one app while each sees only their own data. It's why the organizations table comes first and why every table carries an organization_id. Combined with Row-Level Security, it guarantees each customer's records stay inside their own walls — like apartments in one building.

Can AI really design my database for me?

Yes — if you give it the blueprint. Paste the prompt above with your main entity filled in and AI produces the complete SQL migration: tables, foreign keys, indexes, and Row-Level Security. What AI can't do is decide what your main entity is. That's your product decision, not a technical one.

What's the "main entity" for my app?

The one thing your app manages. Task manager → tasks. CRM → contacts. Invoicing → invoices. Booking → appointments. E-commerce → products. If you can't name it in one word, you haven't defined your product tightly enough yet — solve that before touching the database.