Designing a multi-tenant core for a hospitality SaaS

When you build SaaS for small businesses, an early architectural decision affects development and operations: how do tenants share infrastructure while keeping each company’s data separate?

For Basiq, a hospitality platform now folded into Dawzan, organizing each venue’s data is part of the product design. Here are the trade-offs behind that decision.

The three ways to isolate a tenant

1. Database per tenant — strongest isolation, painful to migrate and operate at scale.
2. Schema per tenant — a middle ground, still heavy once you have hundreds.
3. Shared schema, tenant column — one database, a tenant_id on every row.

The choice depends on isolation requirements, scale, and how the system will be operated. A shared schema can simplify operations, but a query missing its tenant filter can expose one venue’s records to another.

Put isolation rules in a shared layer

Repeating filters by hand makes omissions easier. A shared layer can apply tenant rules consistently, supported by access controls and tests using accounts from different venues.

An Eloquent global scope can help apply query filters, but it is not an isolation guarantee: Laravel explicitly allows scopes to be removed. See the Laravel documentation on removing global scopes.

Background jobs, reports, exports, and files need the same attention. Hiding records in the interface alone does not establish data isolation.

Why this matters to the product

Consistent isolation rules give menu, booking, and accounting modules a shared foundation. They can evolve without inventing a different way to identify the venue in each part of the system.

Before relying on that foundation, test reading, writing, exporting, and switching venues with separate accounts. SaaS architecture is an operational and access-control decision as well as a coding decision.