A multi-tenant SaaS serves several customers (the "tenants") with a single application. The question comes up on day one: where should each customer's data live?

Option 1: a shared database

Every table has a tenant_id column and every query is filtered on the current customer. With Laravel, a global scope applied automatically prevents oversights.

protected static function booted(): void
{
    static::addGlobalScope('tenant', function (Builder $query) {
        $query->where('tenant_id', tenant()->id);
    });
}

Pros

  • A single database to back up, migrate and monitor.
  • Low hosting cost, ideal to get started.
  • Global statistics are easy to produce.

Watch out for

  • A missing filter can expose another customer's data: tests are essential.
  • A very large customer can slow down the others.

Option 2: one database per customer

Each customer gets its own database. The application picks the connection at the start of each request, often from the subdomain.

Pros

  • Strong data isolation, valued by demanding customers (health, finance, institutions).
  • Backup and restore customer by customer.
  • Ability to host a customer in a specific region.

Watch out for

  • Migrations must run on every database.
  • More databases to monitor, so heavier operations.

How to choose?

  • You are starting out and your customers are SMEs: shared database, with solid isolation tests.
  • Your customers require contractual data separation: one database per customer.
  • In between: start shared, and design a data-access layer from day one that lets you move large customers to a dedicated database.

The common ground: authentication

Whatever you choose, a serious SaaS needs single sign-on (SSO) and fine-grained role management (RBAC) per customer. That is often where the real security of the platform is decided.

The right choice is not the most technically elegant one: it is the one that fits your customers and your ability to operate it.

Designing a SaaS? I can help you lay down a sound architecture from day one.