Multi-tenant security: how Venora isolates every venue's data
Row-level security, organization-scoped queries, server-side RBAC, audit logging. The four layers that keep tenant data separate in a shared SaaS platform.
Multi-tenant SaaS is the cheapest way to deliver software, but it is also the easiest way to leak data if you get the isolation model wrong. Here is how Venora handles it.
Four layers of isolation
1. Authentication. Every request carries a verified user identity. We never trust client-supplied user IDs or roles.
2. Organization scoping at the application layer. Every query is filtered by organizationId (and venueId where applicable). This is enforced in the application code, not in the UI.
3. Row-level security at the database layer. Even if an application bug accidentally drops the organizationId filter, row-level security policies on tenant-scoped tables block cross-tenant data access.
4. Role-based access control. Within a tenant, RBAC controls who can do what. Roles are stored in the database, validated on every privileged action, and never trusted from the client.
Audit logging
Sensitive actions — authentication events, payments, session lifecycle, stock changes, permission grants, access-denied attempts — are logged to an audit table keyed by tenant. If something looks wrong, the trail is there.
What we do not do
We do not run a single shared database table without RLS. We do not let the browser tell us which tenant the user belongs to. We do not store payment card numbers — those go directly to PCI-DSS certified providers (Razorpay, Stripe).
Enterprise isolation
For customers with stricter requirements, the Enterprise plan provides a dedicated database per tenant, optional custom domain, and branding overrides. Application code stays the same; only the data layer changes.
For more detail, see our Security overview.