Concepts
Permissions & RLS
Tenant isolation enforced in Postgres with row-level security — the same boundary for the UI, the API, integrations, and AI.
Last updated
Multi-tenancy in Planoda is enforced in the database, not just in application code. Every tenant-scoped table carries row-level security (RLS) policies in Postgres, so a query can only ever return rows inside a workspace the requester belongs to — even if a bug elsewhere forgets to add a filter.
One boundary, every surface
The same RLS boundary applies whether a request comes from the web UI, a REST API token, a webhook-driven integration, or an AI client over MCP. There is no privileged side door: an API token inherits the tenant scope of the member it belongs to, and an agent sees only what that member could see.
Roles within a workspace
Inside the tenant boundary, roles govern what a member can do — read, write, administer. Roles are a layer on top of RLS, not a replacement for it: RLS guarantees you cannot reach another tenant's data at all, and roles shape what you can do within your own.
Why this matters
Database-enforced isolation is the difference between 'we filter by workspace in our queries' and 'the database refuses to return another tenant's rows'. It is the foundation the rest of the security model builds on — see Security → Security model.
Related
- Data modelHow workspaces, teams, issues, projects, initiatives, and cycles relate — one schema underneath every view.
- Security modelRow-level tenant isolation, SSO/SAML and SCIM, signed webhooks, audit logging, and data residency.
- REST API overviewThe REST API surface: OAuth 2.0 + PKCE auth, the typed TypeScript SDK, idempotency keys, and the OpenAPI 3.1 spec.