Shared responsibility
Tested with: Published matrix as of 2026-09 (docs/10 §7)
Published so customers, and HIPAA customers in particular, know exactly where the line is.
| Area | Databasezy | Customer |
|---|---|---|
| Physical and cloud infrastructure | Yes | — |
| Kubernetes, operators, gateway, patching | Yes | — |
| Encryption at rest and in transit | Yes (per-tier keys; TLS 1.2+/1.3 everywhere) | Enable mTLS or a customer-managed key if required |
| Backups and restore tooling | Yes (engine-native, verified weekly) | Choose a policy within the plan; test restores |
| Access control to the instance | Yes (credentials, allow-lists, MFA enforcement) | Manage members, rotate credentials, least privilege in database roles |
| Application-level PHI handling, de-identification | — | Yes |
| Audit log review | Yes (platform) | Yes (your org’s log, via export) |
| Breach notification | Yes (to you within 60 days, target 72 hours) | Yes (to individuals and HHS) |
| Data at rest on end-user devices | — | Yes |
| Secrets in your platform (env vars, secret managers) | — | Yes |
What we commit to in the architecture
Section titled “What we commit to in the architecture”- Isolation by tier is a hard boundary: separate clusters, buckets, keys and gateway fleets for free, standard and HIPAA cells.
- The control plane never touches customer data; backups are streamed by an agent inside your namespace.
- Compliance is a property of the architecture: audit logs, encryption, access reviews and retention are enforced mechanically. See Compliance.
- Only the customer can read or manage their data. See Data confidentiality.