Multi-tenant data with rules the code cannot skip
Row level security puts tenant isolation in PostgreSQL, where every client path has to respect it, including the Data API and a direct psql session.
- Isolation
- In the database
- Policies apply to every connection, not just your ORM.
- Access
- Scoped keys
- Per-integration credentials with explicit permissions.
- Evidence
- Audit log
- Control-plane changes are attributed and durable.
Tenant isolation that survives a bug
A missing WHERE clause in application code is a normal mistake. A row level security policy makes it a non-event rather than a data breach.
Policies per command
SELECT, INSERT, UPDATE and DELETE get their own policies, because who may read a row and who may change it are different questions.
Serverless-friendly access
The Data API runs parameterized SQL over HTTPS, so an edge function can query without holding a Postgres socket. RLS applies there too.
Credentials per consumer
Your web app, your worker and your customer's webhook receiver each get a scoped key. Rotation is targeted rather than a coordinated outage.
Background reconciliation
Long-running functions handle the sync jobs, invoice runs and retries that do not fit inside a request timeout.
Answers for the security questionnaire
Scoped keys, row level policies, an audit log and rootless containers with dropped capabilities. Concrete mechanisms, not badges.
Test policies as the application role
A policy that looks correct as a superuser can be wrong for the role your application connects with. Switch roles in the SQL editor and run the exact queries your code issues before you trust the isolation.
What we will not claim
Container isolation is not a dedicated virtual machine. Any assessment of data protection, hosting region or a data processing agreement needs the operator's actual contract documents, not a marketing page. Ask for them.
Build the whole backend in one project
One plan, one dashboard, one command line interface. PostgreSQL, applications, functions, storage and realtime.