Tenant isolation at the database
Every table carries row-level security policies. Isolation isn't a filter in application code that someone can forget.
Security
Multi-tenant done properly means another business physically cannot read your rows. Here's how that's enforced, without the marketing fog.
Row-level
Database policies isolate every business's data
Region-pinned
Tenants are pinned to one deployment region
Immutable
Financial records cannot be silently edited
Role-based
Access enforced on the server, not the screen
How it's enforced
Every table carries row-level security policies. Isolation isn't a filter in application code that someone can forget.
Prices, discounts, stock deductions, refunds and commissions are all calculated and authorised server-side.
Owner, manager and staff permissions are checked server-side against a dedicated roles table, never a flag on a user record.
Tax invoices are sequential and non-editable. Corrections are credit notes, and the stock ledger is append-only.
Each business is pinned to a deployment region, and there are no cross-region joins between tenants.
Sensitive reads and administrative actions are logged with the user, the time and the record touched.
Payments
Card data is handled by the payment provider and the terminal, not stored in your account or on your devices.
Your control
Permissions, exports and deletion are yours to run without raising a support ticket.
Questions
Book a call and bring your security checklist. We'd rather answer it now than after you've signed.