Tenant Isolation

Rime is a multi-tenant SaaS platform where each customer (tenant) is fully isolated from every other tenant. This page explains the isolation architecture, what happens during tenant provisioning, and how data residency and deletion work.

Database-per-tenant architecture

Every Rime tenant gets its own dedicated PostgreSQL database. There is no shared tenant data — each tenant’s configuration, credentials, pipeline definitions, audit logs, and operational data live in a separate database.

The architecture has two layers:

Control plane database

A single shared database stores:

• Tenant metadata (name, subdomain, creation date, tier)
• User accounts and their tenant associations
• SSO configurations
• Licensing and billing information

The control plane database does not contain any tenant-specific business data, pipeline configurations, or credentials. It exists only to route users to the correct tenant database and manage platform-level concerns.

Tenant databases

Each tenant database contains:

• Snowflake connection credentials (encrypted at rest)
• Connector configurations and credentials
• Infrastructure resource definitions and Terraform state
• Pipeline and orchestration configurations
• dbt project configurations
• Data classifications and masking policies
• Alert rules and notification channels
• Audit logs
• All other tenant-specific operational data

Because each tenant has its own database, there is no risk of a query or bug in one tenant’s context accidentally returning another tenant’s data. The isolation is enforced at the database level, not through application-level row filtering.

Pool routing

When a request arrives at Rime, the system determines which tenant it belongs to and routes it to the correct database connection pool.

How routing works

1. A user visits {tenant}.rimedata.io or makes an API call with a tenant identifier in the subdomain
2. Rime’s middleware extracts the tenant identifier from the subdomain
3. The middleware looks up the tenant in the control plane database to verify it exists and is active
4. Rime retrieves or creates a connection pool for that tenant’s database
5. The request proceeds with a connection from the tenant-specific pool

Connection pool lifecycle

• Lazy creation — connection pools are created on first request, not at startup. A tenant that has not been accessed recently does not consume database connections
• Caching — once created, a connection pool is cached in memory for subsequent requests. The pool is reused across all requests for the same tenant
• Pool limits — each tenant pool has a maximum connection count to prevent any single tenant from exhausting database resources
• Isolation — connection pools are independent. A slow query in one tenant’s database does not block connections for another tenant

Subdomain assignment

Each tenant receives a unique subdomain at creation time (e.g., acme.rimedata.io). The subdomain:

• Must be unique across all Rime tenants
• Contains only lowercase letters, numbers, and hyphens
• Cannot be changed after creation (to prevent URL instability)

Custom domains are supported for tenants that want to use their own domain (e.g., data.acme.co.nz). See Encryption for TLS certificate details.

No shared data

The database-per-tenant model ensures:

• No co-mingled credentials — each tenant’s Snowflake passwords, API keys, and connection strings are stored in a separate database. A compromise of one tenant database does not expose another tenant’s secrets
• No shared configuration — pipeline definitions, infrastructure state, and transformation configurations are tenant-specific
• No shared audit trails — each tenant’s audit log is in its own database. One tenant cannot see another’s activity
• Independent migrations — database schema changes can be applied per tenant, allowing staged rollouts

Tenant provisioning

When a new tenant is created, Rime runs the following sequence:

1. Database creation — a new PostgreSQL database is created with a name derived from the tenant identifier
2. Schema migration — all migrations are applied to bring the database to the current schema version
3. Default roles — Rime creates default application roles within the tenant (administrator, member, viewer)
4. Encryption key setup — the tenant database is configured to use the platform encryption key for credential storage
5. Initial user — the user who created the tenant is assigned the administrator role

The entire provisioning process takes a few seconds. The tenant is accessible immediately after provisioning completes.

Data residency

Rime offers data residency options to meet regulatory and organisational requirements:

Region	Cloud provider	Availability
Auckland, New Zealand	AWS (ap-southeast-2)	Available
Sydney, Australia	AWS (ap-southeast-2)	Available
Auckland, New Zealand	Azure (australiaeast)	Planned

For NZ Privacy Act 2020 and NZISM compliance, tenants can be provisioned in the New Zealand region to ensure that all Rime-managed data (configuration, credentials, audit logs) remains within NZ borders.

Data residency applies to Rime’s own databases and storage. Your Snowflake account’s data residency is determined by the Snowflake region you selected when creating your Snowflake account — this is independent of Rime.

To request a specific region during onboarding, specify the preferred region in your sign-up form or contact Rime support.

Deletion and right to deletion

The database-per-tenant architecture simplifies data deletion:

• Tenant deletion — when a tenant is deleted, the entire tenant database is dropped. This is a complete and irreversible deletion of all tenant data. No manual column-by-column purge is needed
• Right to deletion — under the NZ Privacy Act 2020, individuals have the right to request deletion of their personal data. Because tenant data is isolated in its own database, identifying and deleting user-specific data is straightforward. Rime provides a data export and deletion workflow in Settings > Data Management
• Credential cleanup — when a tenant is deleted, all encrypted credentials (Snowflake connections, connector credentials, SSO secrets) are destroyed along with the database. Encryption keys are not reused for new tenants
• Audit trail preservation — if required for compliance, audit logs can be exported before tenant deletion. Once the database is dropped, the logs are unrecoverable

Tenant deletion is a two-step process with a confirmation period:

1. An administrator requests deletion from Settings > Tenant > Delete Tenant
2. A 7-day grace period begins, during which the request can be cancelled
3. After 7 days, the tenant database is dropped and all data is permanently deleted

Next steps

• Review Encryption for how data is encrypted within each tenant database
• Understand Network Security for network-level isolation
• Check Compliance for how tenant isolation supports regulatory requirements
• Set up Audit Logging to track access within your tenant