Multi-tenancy is how modern SaaS works. Every dental practice management system that calls itself “cloud” is, by definition, sharing infrastructure across many clinics. The question every clinic owner should ask isn't “is this multi-tenant?” — it's “how, exactly, is my clinic's data separated from the next clinic's data?”
This article is for clinic owners, operators, and compliance leads evaluating dental SaaS. Four concrete questions to ask, with the answers that distinguish architecturally sound vendors from vendors relying on application-layer isolation alone.
Why this matters more for dental than for, say, project management
Dental records are health data. In Singapore that puts them under PDPA with an extra duty of care; in other jurisdictions it's HIPAA, GDPR, or local equivalents. The cost of a tenant-isolation failure isn't just legal exposure — it's reputational catastrophe for the affected clinic. A B2B SaaS vendor that leaks one company's pipeline data to another is in trouble; a dental SaaS vendor that leaks one clinic's patient records to another is in a different category of trouble.
Architectural isolation is the one control that, when done right, makes the worst-case outcome (a leak across tenants) genuinely difficult rather than merely unlikely.
The four questions
1. At what layer is per-clinic separation enforced?
Three real answers, in increasing order of robustness:
- Application-layer isolation. Every database query carries a
WHERE clinic_id = ?clause inserted by the application. Works fine until a developer forgets the clause on one query, or a SQL injection bypasses it. Common; not enough. - Row-level security (RLS).The database itself (Postgres, recent SQL Server) enforces per-row access policies based on the connection's tenant context. A query without the right tenant context returns zero rows by default — even if the application's WHERE clause is missing or compromised.
- Schema-per-tenant or database-per-tenant. Each clinic gets its own schema or database. Strongest isolation; most operationally expensive (per-tenant migrations, per-tenant backups, slower onboarding).
For dental SaaS at clinic-scale (hundreds to low-thousands of clinics), Postgres row-level security is the modern default. Schema-per-tenant is acceptable but expensive at scale; application-layer-only is no longer acceptable for health data.
2. Show me the policy.
Vendors confident in their RLS implementation will walk you through the policy. It looks like:
CREATE POLICY clinic_isolation ON patient
USING (clinic_id = current_setting('app.current_clinic')::int);
ALTER TABLE patient ENABLE ROW LEVEL SECURITY;The vendor sets app.current_clinicon every request based on the authenticated user's clinic. From that point on, the database itself enforces that this user can only see this clinic's patient rows. No WHERE clause in the application can accidentally bypass it.
A vendor that can't produce something concrete here is doing application-layer isolation and calling it “multi-tenant.” That distinction matters when something goes wrong.
3. What about backups, exports, and reports?
RLS protects live queries. Backups, batch exports, and admin tooling often run with elevated database connections that bypass RLS. The question becomes: how does the vendor segment those paths?
Reasonable answers include: backups are encrypted and segmented per clinic; exports are scoped to a single clinic ID and audit-logged; admin tooling has separate roles for clinic-scoped vs cross-clinic access; the cross-clinic role is used rarely and every use is logged.
Unreasonable answers include: “we trust our admins,” “exports run as the admin user,” and any answer that doesn't mention what happens at the elevated-connection layer.
4. What does an audit log show me?
A clinic should be able to query: “Show me everyone — including vendor staff — who accessed patient X's record in March.” The log should include user, clinic, resource, action, timestamp. Vendor admin actions should be logged the same way clinic actions are.
For a deeper treatment of dental audit logs and what regulators actually look at, see the dental audit logs article.
What good looks like
For dental SaaS in 2026, “good” tenant isolation has the following structure:
- Postgres row-level security policies on every patient-bearing table. The policies reference a tenant context set per-request; the application never composes raw
WHERE clinic_id = ?filters as the only protection. - Per-clinic backup segmentation. Backups can be restored to a single clinic without exposing other clinics' data.
- Cross-tenant admin access is a separate role, requires a specific break-glass workflow, and is fully audit-logged.
- Every patient-record access is logged with user, clinic, resource, and timestamp — including vendor admin access. The log is queryable by the clinic.
- Region-pinned data residency. For Singapore clinics, this means asia-southeast1 (or equivalent) with no replication outside the region without explicit per-patient consent.
What we do
Oralstack uses Postgres row-level security per clinic, with the tenant context set on every request from the authenticated session. Backups are encrypted and segmented per clinic; cross-clinic admin access is a separate role with break-glass logging. Every read and write is audit-logged. Data sits in asia-southeast1 with no cross-region replication. The full posture is documented at /security.
If you're evaluating dental SaaS — Oralstack or anyone else — these four questions are the ones that distinguish architecturally sound vendors from vendors relying on marketing language. Send them in writing. Compare the written answers side-by-side. The vendors that answer with policy code and concrete examples are the vendors to take seriously.