Why ClickHouse fits customer-facing analytics in a SaaS product
SaaS customers now expect in-product dashboards and usage views that answer in seconds, and the product team needs each tenant's data kept apart from every other tenant's. Self-managed ClickHouse handles both by keeping the analytical store inside infrastructure you control, where you decide how tenants share tables, how queries are throttled and where the evidence for your audit comes from. The ClickHouse server is licensed under Apache-2.0, and ClickHouse Inc. sells a managed service separately, so choosing to self-host is a control decision about data placement, operations and audit scope rather than a licensing one.
Running analytics for internal staff is a different problem from serving customers. Internal users are few, known and forgiving of slow queries. Customers are many, unknown to your analysts and sensitive to every slow chart, so isolation and fairness become product features. Tenant isolation is enforced with users, roles and row policies, per-tenant limits come from settings profiles and quotas, and each of those objects becomes part of your system description. Confirm in a pre-production environment that a tenant's query cannot read another tenant's rows through a shared table, and that the default user, which starts with all permissions, is restricted before any customer traffic reaches the cluster.
Customer-facing analytics also pulls the platform into the scope of your SOC 2 examination. The security common criteria apply to every SOC 2, and the controls over logical access, change management and system operations will need evidence drawn from ClickHouse configuration, access logs and upgrade records. Ask your auditor early which Trust Services categories are in scope, because availability and confidentiality add criteria that change what you must show. Decide with your team which ClickHouse access controls and change records will be produced for a Type 1 report and which must run over a period for a Type 2 report.
What SaaS customers and auditors expect from the analytics layer
This table maps the SOC 2 criteria and ClickHouse documentation to the requirements a SaaS analytics layer must meet. Read each row as a requirement, the evidence an assessor will ask for, and what it means for the build. The main takeaway is that tenant isolation, access control and tested restores are the points most likely to be questioned, and each needs a control you can show, not only a configuration.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| CC6 logical access (common criteria) | Access to the analytics system is restricted to authorized users and limited to what each role needs. Assessors look for documented access decisions and evidence they are applied. | Create named users and roles, restrict the default user, and enforce tenant boundaries with row policies. Confirm your own access review process, since the criteria turn on your control design. |
| CC6 tenant isolation (design choice) | Customers should only see their own rows. The TSC does not prescribe a method, so the design must be justified and tested. | Use row policies keyed to tenant identity, and test them with queries run as each tenant role. Confirm whether your customer contracts require physical or logical separation. |
| CC7 system operations | Monitor the system for anomalies, detect failures and respond. Assessors expect monitoring records and documented incident handling. | Collect ClickHouse system tables and metrics, alert on replica lag, Keeper health and failed merges, and keep the alert and response records. |
| CC7 change management (related practice) | Changes to the platform are tested and approved before production. ClickHouse docs recommend a pre-production environment and reading changelogs. | Test each ClickHouse upgrade against representative data and tenant queries, and keep the change record. Check the security policy for which versions receive security updates. |
| A1 availability | Availability commitments and capacity are defined and monitored. The criteria apply only when availability is in scope for your report. | Use ReplicatedMergeTree with ClickHouse Keeper, which the replication guide recommends with at least three nodes on dedicated hosts. Confirm your own uptime commitments before promising any figure. |
| C1 confidentiality | Confidential information is identified and protected. The criteria apply only when confidentiality is in scope. | Classify tenant data, apply TLS and restricted network exposure, and confirm retention and deletion steps per tenant. Confirm the classification rules with your legal team. |
| Backups and restore evidence (ClickHouse backup docs) | Backups exist and restores work. The docs warn that a backup never test-restored will probably not restore properly. | Schedule BACKUP and RESTORE runs to storage you control, and perform regular restore tests on a spare cluster. Keep restore test records as evidence for availability and change criteria. |
| Replication limits (ClickHouse backup docs) | Replication does not protect against human error or corruption, so a separate recovery path is needed. | Pair replicas with independent backups, and document how a tenant deletion or bad migration would be reversed. |
| Authentication integration (ClickHouse external authenticators) | Customer and workforce identities should map to database roles through a controlled source. | Use LDAP, Kerberos, X.509 certificates or JWT where your identity provider supports them, and confirm the mapping with your identity team. |
How tenant isolation is built in ClickHouse
All tenants share the same tables, and each tenant's rows are separated by a tenant identifier column. ClickHouse row policies restrict which rows a given user or role can read, so the application connects with a database user bound to one tenant's policy rather than relying only on the application to add a filter. This option has the lowest operating cost, because there is one schema, one set of migrations and one set of background merges to watch. The cost shows up in three places: every tenant shares CPU, memory and disk I/O, so one heavy query can slow others; row policies must be created, reviewed and tested for each tenant; and access administration grows with the tenant count unless you template it.
- Row policy coverage: Define policies on every table that holds tenant data, including materialized views and any table a query can reach through a join.
- Settings profiles and quotas: Attach settings profiles and quotas per role so one tenant cannot consume the cluster's memory or query time.
- Restricted default user: Disable the default user's broad permissions so no session can read across tenants by accident.
- Schema changes: A single migration touches every tenant, so the change process must be tested on representative data.
- Access administration: Automate user and policy creation from your tenant lifecycle, since manual grants drift.
Before committing, confirm with a load test how far a single tenant's heaviest queries can move p95 latency for others on your hardware.
Tenants are grouped by tier, for example a standard tier and an enterprise tier, and each tier gets its own database with its own table set. This separates schema and storage for groups of tenants without the cost of one cluster per customer. Operations gain some isolation, since a tier can be migrated, retained or sized on its own, but each database still lives on the same servers and shares their resources. Within a tier, row policies or other controls still separate individual tenants, so this option usually combines with the first one rather than replacing it.
- Tier-level retention: Different tiers can carry different TTL rules, which fits contractual retention promises.
- Shared resource pools: Settings profiles can give each tier its own memory and thread limits, but the underlying hosts are still common.
- Grant scope: Roles can be granted per database, which keeps a tier's administrators away from another tier's data.
- Migration path: A tenant can be moved to a new tier by copying its rows into another database, which requires careful sequencing.
- Operational overhead: Each database adds objects to back up, monitor and upgrade, so review the count against your backup window.
Ask your team to document which controls differ by tier and which are identical, because auditors will ask for the difference.
Large or regulated tenants run on their own ClickHouse cluster, with separate hosts, storage, Keeper nodes and backups. This gives the strongest noisy-neighbor isolation and the clearest data boundary, which some contracts and regulators expect. The price is operational: each cluster needs its own upgrades, monitoring, backup tests and capacity planning, and the cost recurs for as long as the cluster runs. A common pattern is a shared cluster for most tenants plus dedicated clusters for a small number of tenants, with a deployment pipeline that treats both as the same configuration.
- Cost per tenant: Dedicated hosts and replicas are paid for whether the tenant is busy or idle, so size them to the contract.
- Upgrade coordination: Every cluster must be upgraded within the supported version window, which increases the change calendar.
- Backup and restore tests: Each cluster needs its own tested restore procedure and spare environment.
- Access administration: Identity can be centralized through external authenticators, but each cluster still needs its own users, roles and quotas.
- Placement control: Dedicated clusters can run in a chosen region or data center, which supports residency commitments.
Confirm with your largest prospective customers whether they require a dedicated environment in writing, since that requirement determines how many clusters you will operate.
Which ClickHouse access and sizing settings matter for multi-tenant analytics
Serving customer-facing analytics from one ClickHouse cluster means every query must be scoped to a tenant, every tenant must stay within its limits, and every operator and application login must be traceable. The five settings below cover those concerns, plus the replication layer that keeps the service up while tenants depend on it.
Row policies for tenant filtering
Row policies restrict which rows a user can read from a table, so a tenant identifier column can be enforced inside the database instead of only in the application. Define one policy per tenant-scoped table and bind it to the role that application services use. Before go-live, run queries as a test tenant and confirm that aggregates, joins and materialized views on the same data return only that tenant's rows. Check that no role inherits a broader policy by accident.
Roles and settings profiles
Roles group grants, and settings profiles fix values such as maximum memory, execution time and thread counts for each class of user. Give the customer-facing application one role with read access to tenant views, and give the ingestion pipeline a separate role with write access only. Attach a profile to each role so that a single heavy query cannot starve other tenants. Verify the effective settings for each role with a test session before release.
Quotas per tenant
Quotas limit how many queries, rows read or execution seconds a user can consume within a time window. Tie quotas to the identity that represents each tenant or each tier of customer, not to a single shared application account, so that one noisy tenant does not consume the budget of the others. Confirm the quota windows and limits with your product team, then test that a quota breach returns an error the application handles gracefully.
Restricting the default user
The default user starts with all permissions, so an unconfigured cluster can be queried without any tenant scoping at all. Disable or restrict the default user, set a password or external authentication for administrators, and remove any test accounts before production traffic arrives. Verify the change by connecting without credentials and confirming that access is refused, and by listing grants for every remaining user.
External authenticators for applications and operators
ClickHouse can delegate authentication to LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator or JWT tokens issued by your identity provider. Use JWT or certificates for the application service so credentials rotate centrally, and use LDAP or Kerberos for named operator access so every administrative session maps to a person. Before go-live, confirm that expired tokens are rejected, that revoked accounts lose access, and that each role receives the groups it expects.
Replication with ClickHouse Keeper
ReplicatedMergeTree tables coordinate through ClickHouse Keeper, which replaces ZooKeeper, so a tenant's data survives the loss of one replica. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Verify that a recovered replica resyncs missing data from a healthy peer, and rehearse a node failure under simulated customer query load. Replication does not protect against accidental deletes, so pair it with the backup controls described elsewhere on this page.
How latency targets drive sizing and table design
In-product query latency is set by the table design long before it is set by hardware. For customer-facing dashboards, the ordering key of each MergeTree table determines how much data a tenant's query must read, so it should lead with the tenant identifier followed by the most common time and filter columns. Partitioning should match retention and deletion needs rather than query shape, because too many partitions add overhead to every query. Pre-aggregated tables, built with materialized views for the handful of charts each dashboard shows, usually matter more than raw table size. Ask any partner to explain, table by table, which queries each ordering key serves and which queries will fall back to scanning raw events.
Concurrency is the second driver. Many tenants refreshing dashboards at once compete for CPU, memory and disk, so the p95 or p99 latency a customer sees depends on how many tenant queries run in parallel and how the server limits them. Settings profiles, per-user resource limits and the concurrency controls in the server configuration should be sized against the expected peak, not the average. Replicas and shards add capacity only for the queries they can spread, so confirm how the design routes reads before buying nodes. Quotas in the access control layer protect other tenants from a single heavy workload, but they are a fairness control, not a substitute for sizing.
None of these choices can be settled on paper. The production FAQ recommends a pre-production environment with representative data and queries, and for SaaS that means a realistic tenant size distribution, the real dashboard query set and a load profile that reflects peak refresh behavior. Measure latency at the percentile your service level targets, record the query plans and the rows read per query, and repeat the test after every schema change. Ask for the agreed latency target, the test data generator, the load tool configuration and the acceptance results in writing before the production sizing is signed off. Targets stated only as averages will hide the tenants most likely to complain.
How a multi-tenant ClickHouse rollout is phased
The sequence moves from a written tenant model to a tested, replicated cluster and then to tenants added in waves, with a check at each stage so no customer sees data they should not.
Scope the tenant model and data contracts
Your team and the implementation partner agree how tenants map to databases, tables or a shared table with a tenant key, which customer-facing queries and dashboards must be served, and what each customer is contractually promised about data location, retention and deletion. The output is a written tenant model and a list of query patterns with their latency expectations. The step is done when the product owner, data engineering and security have signed the same document.
Build a pre-production cluster with representative data
The team stands up a non-production ClickHouse environment that matches the intended production layout as closely as practical, then loads a representative slice of event data with realistic tenant skew, including your largest tenant. The ClickHouse production guidance recommends a pre-production environment with representative data and queries, and reading the changelog before upgrading, so the version under test should be the one you plan to run. The gate is a benchmark run of the agreed customer-facing queries against the target latency expectations.
Implement row policies and per-tenant quotas
Engineers create users and roles for the application and for each access pattern, restrict the default user, and attach row policies so each tenant identity can read only its own rows. Settings profiles and quotas are then configured to cap query volume and resource use per tenant, so one heavy customer cannot degrade others. The gate is a review of the access-rights configuration against the tenant model, with the default user confirmed as restricted and every application role mapped to a named owner.
Test tenant isolation and restore
Testers run negative tests in which each tenant credential tries to read, aggregate, join and export rows belonging to another tenant, including through materialized views, projections and error messages, and they record the results. In parallel, the team restores a backup into a spare cluster and checks row counts and tenant-level checksums. The gate is a written test report with zero cross-tenant reads and a successful restore, because the backup documentation warns that a backup never test-restored will probably not restore properly when needed.
Replicate the cluster and configure backups
Production is built with ReplicatedMergeTree tables coordinated by ClickHouse Keeper, using at least three Keeper nodes on dedicated hosts as the replication guide recommends. Scheduled BACKUP jobs are set up to a location outside the cluster, and an alert is configured for failed backup runs. The team then simulates a replica failure and confirms the recovered replica resyncs from a healthy peer. Replication alone does not protect against human error or corruption, so the gate is a successful failover drill plus a successful backup restore on the production schedule.
Onboard tenants in waves
Customers move onto the platform in small groups rather than all at once, starting with internal or design-partner tenants whose quotas and query patterns are closely monitored. Each wave is checked against latency, error rate and quota-hit metrics before the next group is added, and any tenant-specific issue is logged against the tenant model. The step closes when all contracted tenants are live, the isolation tests have been repeated on production-like data, and the operations runbook has been handed to the platform team.
What SOC 2 evidence a ClickHouse analytics layer produces
A SOC 2 examination tests whether controls work as described, so the analytics layer has to leave records that an auditor can sample. The cards below map the evidence a self-managed ClickHouse deployment can generate to the security common criteria and availability, and note where the auditor, not DeployOpen, makes the judgment.
Access review records for tenant data
Common criteria CC6 covers logical access. In ClickHouse, access is defined by users, roles, row policies, settings profiles and quotas, so the review should export those objects and compare them with your identity records. Restrict or remove the default user, which starts with all permissions, and keep a dated export of grants that a reviewer can sign. Ask whether your customer-facing service accounts map one-to-one to tenants or are shared, because shared accounts make row policy evidence harder to defend.
Authentication configuration evidence
CC6 also expects authentication to be controlled and documented. ClickHouse supports LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication as external authenticators. Keep the configuration files under version control and record which method each client path uses. Auditors will look for evidence that changes to these settings are reviewed, so store the approval alongside the diff.
Schema and version change management
CC8 covers change management. For an analytics layer, changes come from two sources: schema changes such as new tables, projections or row policies, and ClickHouse version upgrades. Record each change with a ticket, the test run on a pre-production environment with representative data, and the changelog reviewed before the upgrade, since minor backward-incompatible changes can occur. Stable releases ship roughly monthly, so a dated upgrade log is itself evidence.
Backup and restore test records
Availability criterion A1 asks whether you can recover what you have promised to recover. ClickHouse BACKUP and RESTORE cover tables, partitions and databases, and replication alone does not protect against human error or corruption. The documentation warns that a backup never test-restored will probably not restore properly. Keep a dated restore test record on a spare cluster that shows the restore time observed and the row counts checked, because this is the evidence auditors ask for first.
Replica health and monitoring evidence
Availability also depends on whether replication is working. ReplicatedMergeTree tables coordinated by ClickHouse Keeper resync a recovered replica automatically from a healthy one. Keep Keeper on at least three nodes on dedicated hosts for production, and retain the metrics and alert history that show replica lag and Keeper health over the audit period. Confirm with your auditor which retention period they will sample.
Incident records and Type 1 versus Type 2
Incident response and monitoring evidence show that anomalies were detected and handled. Keep tickets that link alerts, investigation notes and any tenant-impact determination. Note the difference in what the report will prove: a Type 1 report describes the system and the suitability of control design as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period. DeployOpen prepares the controls and evidence, but the independent CPA firm issues the report.
What teams ask before hiring help with customer-facing ClickHouse
What drives the cost of a customer-facing ClickHouse build, and what is one-time versus recurring?
Cost follows the written scope, and the main drivers are the number of tenants and data sources, the query latency targets, the depth of row policy and quota design, and how much of the environment you already run. One-time work includes architecture, schema and row policy design, ingestion pipelines, sizing, load testing, backup configuration and the first restore test. Recurring costs include the infrastructure you pay your cloud or data center provider for, the support and upgrade retainer if you choose one, and the time your platform team spends on on-call and evidence collection. Ask any partner to split the quote into these parts, and to state which items are fixed and which are retainer-based.
How long does a fixed-scope ClickHouse build usually take?
Duration depends on the scope agreed in writing, so no single figure applies across customers. The schedule is shaped by how many tenants and event sources are in scope, whether the data model is settled, how many replicas and Keeper nodes must be built, and whether a pre-production environment with representative data and queries is part of the work. Teams with a clear data model and existing infrastructure move faster than teams still deciding how tenants map to tables. Ask for milestones that include load testing against your latency targets and a restore test before go-live, and confirm each milestone with the partner in the written scope.
What must our team provide before a ClickHouse engagement starts?
Before work starts, your team should be ready to supply four inputs. The first is the data model, including event types, the fields each dashboard reads, and the expected growth per tenant. The second is the tenant list and how tenants are identified in each event, because that identifier drives row policies. The third is the service level objectives for query latency, freshness and availability, which set the replica count and sizing. The fourth is the access model: which application services, support staff and analysts need which roles, and how identity is federated. Missing any of these usually extends the discovery phase, so ask the partner for a checklist before signing.
Can our in-house team run customer-facing ClickHouse without outside help?
Yes, many teams do, and the decision depends on skills and staffing rather than on the software itself. The ClickHouse server is open source under the Apache License 2.0, so licensing does not require a vendor purchase to self-host. The harder parts are replication and Keeper operations, multi-tenant access design, backup and restore testing, and upgrades across supported versions. Assess whether you have engineers who have run a stateful distributed database in production and who can own an on-call rotation. An outside partner can cover the build and knowledge transfer, or a retainer can cover ongoing operations. Compare both options on the same written scope.
How should we plan ClickHouse upgrades given the supported version list?
Start from the security policy, which lists the versions that currently receive security updates, and check that your running version is on that list before planning. The production guidance recommends stable releases for most production use, a pre-production environment with representative data and queries, and reading the changelog before each upgrade because minor backward-incompatible changes can occur. Stable releases ship roughly monthly, while LTS releases ship twice a year and are supported for a year after release, so many teams pick an LTS line for slower change. Plan rolling upgrades one replica at a time, keep a tested rollback path, and schedule upgrades as recurring work in the support model. Confirm the current supported list with the vendor before each planning cycle.
What does a SOC 2 Type 2 examination require from the ClickHouse platform team?
A SOC 2 examination is performed by an independent CPA firm, and DeployOpen does not issue audit reports or attestations. The platform team prepares the system and evidence. A Type 2 report covers the system description and an opinion on operating effectiveness over a period, so the team must show that controls ran consistently for the whole period. For ClickHouse, the security common criteria CC1 to CC9 apply, which points toward evidence for access control (users, roles, row policies and quotas), change management for upgrades, system operations such as monitoring and backup restore tests, and risk mitigation. Ask your auditor which criteria are in scope and which evidence they expect, and keep records of access reviews, change tickets and restore test results from day one.
How do we isolate tenants so one customer cannot read another customer's data?
Tenant isolation in ClickHouse depends on design choices you make early, and it should be tested rather than assumed. The access control model supports users, roles, row policies, settings profiles and quotas, and row policies can filter each tenant's rows for the users or roles that query on their behalf. The documentation recommends managing these objects through SQL and restricting the default user, which starts with all permissions. Pair row policies with per-tenant quotas so one tenant cannot exhaust shared resources. Ask the partner to include automated cross-tenant access tests in the scope, and confirm how the application authenticates users to ClickHouse.
What to ask a partner before you sign a SaaS analytics scope
Put these questions to any partner before the scope is signed, and ask for written answers. Start with evidence for tenant isolation. Ask how row policies and per-tenant QUOTA tests are proven: which test queries run as which users, whether the results are kept as dated artifacts, and who reviews them. A partner should be able to show a test where a user from one tenant cannot read another tenant's rows, and a test where a tenant exceeding its quota is throttled without affecting others. Ask whether those tests re-run after every upgrade and every change to the default user or settings profiles.
Next, pin down restore testing and upgrades. Ask how often BACKUP and RESTORE tests run on a spare cluster, which tables and partitions are included, how long a restore takes in the test, and who signs off the result. ClickHouse's documentation warns that a backup never test-restored will probably not restore when needed, so an answer of "we back up nightly" is not enough. On upgrades, ask which release line the partner plans to run, how it maps to the currently supported versions in the ClickHouse security policy, how changelogs are reviewed for backward-incompatible changes, and how a rollback is rehearsed in a pre-production environment with representative data.
Finally, get the boundaries and the handover in writing. Ask what the scope excludes: for example, the SOC 2 auditor relationship, the auditor's sampling, the content of the system description, and the policies your own team must own. A partner prepares controls and evidence; the independent auditor issues the report. Ask for a handover list that names every runbook, dashboard, test script, user and role inventory, and backup schedule, with the owner of each after go-live. If any of these answers is missing from the proposal, treat that as an open item to resolve before signature.
How DeployOpen scopes and delivers ClickHouse for SaaS analytics
DeployOpen plans, implements, hardens, documents and supports self-hosted ClickHouse inside your own cloud accounts, data centers or restricted networks. For customer-facing analytics, we start from your tenant model, query latency targets and SOC 2 evidence needs, then deliver a system you operate. Engagements are fixed-scope, with written scope, deliverables and timelines agreed before work starts.
How we scope
- Map tenant isolation needs, including which customers share tables and which require separate databases or clusters.
- Define latency targets for in-product dashboards and the query shapes they depend on, so sizing is based on real workloads.
- Agree in writing which SOC 2 Trust Services Criteria and control evidence the ClickHouse platform must support.
How we build
- Design users, roles, row policies and settings profiles through SQL-driven access control, with the default user restricted.
- Configure per-tenant quotas and resource limits, then test that a heavy tenant cannot degrade other customers' dashboards.
- Build ReplicatedMergeTree replication with ClickHouse Keeper and a BACKUP and RESTORE schedule, tested on a spare cluster.
How we hand over
- Deliver runbooks for upgrades, replica recovery, restore tests and access reviews, written for your platform team.
- Document the access model, tenant quota configuration and evidence locations so your auditors can trace each control.
- Agree a pre-production validation plan with representative data and queries before any production cutover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped to your ClickHouse versions and release channel.
- Plan upgrades around the changelog and a pre-production environment, since minor backward-incompatible changes can occur.
- Prepare systems and evidence for your SOC 2 examination; independent auditors, not DeployOpen, issue the report.
