Multi-tenant
One software instance serves many restaurants, each with its own data and settings. MobiTaste runs multi-tenant by design: one server, many isolated tenants, each invisible to the next.
What it means in operation
A tenant on MobiTaste is an organization, which owns one or more restaurants. Every record in the database carries a tenant id, and every query filters by it through row-level security. A staff member who logs in to one restaurant cannot see another restaurant’s menu, orders, or tables, even if the underlying tables are stored side by side. Upgrades, security patches, and feature rollouts happen once across the platform, which keeps the per-restaurant cost low. The alternative model, single-tenant, runs a separate instance per customer and costs ten to twenty times as much to operate.
Why it matters
The buying question is data isolation. A multi-tenant SaaS that does isolation properly is cheaper, faster to patch, and just as private as a single-tenant deployment. A multi-tenant SaaS that does isolation badly leaks data across customers, which has been the source of several public incidents in the last decade. Hotel IT teams ask the question directly: how do you isolate tenants. The honest answer is RLS at the database, plus tenant id on every write, plus tests that try to read the wrong tenant and fail. MobiTaste runs all three.
Related terms
- Row-level security: the database mechanism that enforces isolation.
- Organization: the tenant unit on MobiTaste.
- Audit log: the trail that proves isolation held.