Tenants: How Data Gets Scoped (and When to Use Data Silos)

When you see that tenant dropdown in our app (StrongStart, MODAL, YTexas, etc.), that’s not just a menu — it’s the control that maps everything you do to the right company’s world.

What’s a Tenant?

• A tenant is just a company (or organization) that uses our platform.
• Each tenant has its own data bubble — clients, bookings, invoices, staff, content.
• Tenants share the same app but never see each other’s data.

Think of it like:

• One giant apartment building (the app)
• Each tenant gets their own locked apartment (their data)

How the Dropdown Works

When you pick a tenant in the dropdown:

• You’re telling the app: “Scope everything I see/do to this company.”
• If you choose MODAL, then all services, invoices, and staff shown = MODAL’s only.
• If you switch to StrongStart, you’ll see StrongStart’s world instead.

👉 This prevents data from mixing between companies.

Why This Matters

• Clarity – You’re always working in the right company’s data.
• Security – Tenants can’t see each other’s information.
• Scaling – We can serve multiple companies from the same platform without spinning up a new system for each one.

Example: Adding a Booking

1. Tenant dropdown = YTexas
2. You add a new booking.
3. That booking is automatically tagged as “YTexas-owned.”
4. If you later switch to MODAL, that booking disappears (because MODAL shouldn’t see YTexas data).

The Big Picture

Multi-tenancy (fancy word) = “One app, many companies, each in their own lane.”

The tenant dropdown is the steering wheel that makes sure all the data stays in the right lane.

What About Big Tenants?

Most of the time, all tenants share the same main database, and we just scope their data with tenant IDs. But sometimes a tenant gets so big or demanding that it makes sense to give them their own database. This is called a data silo.

Why create a silo?

• Performance: A large tenant (say, 100k+ bookings a week) could slow down the shared system.
• Compliance: Some industries (finance, healthcare, government) require stricter isolation.
• Control: Big tenants may want their own backup schedule, analytics, or even to own the database outright.

Analogy

Instead of an apartment in the building, these tenants get their own townhouse next door. They still use the same community pool and clubhouse (the app code), but their living space is fully separate.

How It Works in Practice

• Default: Tenants share one database (efficient, easy to maintain).
• Enterprise mode: Certain tenants get their own secondary database.
  • The app still routes through the same tenant dropdown.
  • But when it sees a “siloed tenant,” it connects to their private DB instead of the shared one.

The App Still Works the Same

• You log in, pick the tenant, add bookings, etc.
• Behind the scenes, the app decides:
  • Small tenant → shared DB
  • Large tenant → dedicated DB

Trade-Offs

• Pros of silos: isolation, performance guarantees, easier to hand off ownership.
• Cons: more infrastructure to manage, more backups, more chances for configs to drift.

That’s why most tenants stay in the shared DB until they really outgrow it.

Key Takeaway

• Dropdown = scope → all your work belongs to the selected tenant.
• Shared DB = apartments → efficient, secure, everyone together.
• Siloed DB = townhouse → heavier tenants get their own space, but same neighborhood.

Either way: One app, many tenants, each with their data safe and separate.