ClickHouse implementation plan and cost

What a ClickHouse implementation covers and who should run it

For most teams that need fast analytical queries over event, log or telemetry data in their own infrastructure, the work is done with an implementation partner, at least for the first rollout. ClickHouse server is open source under the Apache License 2.0, so the software itself costs nothing to obtain. What takes time is designing the tables, sizing the cluster, running replication and coordination, building ingestion, and proving that backups can be restored. Teams with prior ClickHouse operations experience and a flexible timeline often keep the whole effort in-house, while others bring in outside help for part of it.

Several triggers point toward outside help. The first is no prior ClickHouse operations experience, because sort key choices, partitioning and part merging decisions are hard to reverse once data is loaded. The second is a tight go-live date that leaves no room to learn these decisions on production data. The third is a compliance requirement for evidence. Auditors will ask how access is controlled, how backups are tested and how upgrades are approved, and those answers must exist in writing before the assessment begins. DeployOpen prepares these systems, controls and evidence, but independent auditors and certification bodies issue any audit report or attestation.

A rollout and an ongoing operation are different pieces of work, and a quote should separate them. A rollout covers the design of schemas and sort keys, the layout of shards and replicas, the deployment of ClickHouse Keeper nodes, the ingestion pipeline, retention rules, backup and restore procedures, and a pre-production environment loaded with representative data and queries. Operations is what follows: monitoring replica health, applying supported releases, reviewing the changelog before each upgrade, rotating credentials, and running restore tests on a schedule. Some clients hand operations back to their own team after handover, and others keep a retainer in place for upgrades and testing.

Before requesting a quote, the reader should decide who owns each part after go-live. Ask the partner to name the people who will design the schema, operate Keeper and run restore tests, and confirm whether those people are the same ones who build the system. Confirm which ClickHouse release line your organization will standardize on and who approves upgrades. Confirm where the cluster will run, including the cloud accounts, data centers or air-gapped networks involved, because that choice affects network design, object storage for backups and the access paths your security team must review. These answers determine whether the rollout can be scoped as fixed work with a clear handover, or whether it needs an ongoing agreement from the start.

ClickHouse implementation scope and deliverables

A fixed-scope ClickHouse implementation covers the design, configuration and proof of recovery that a production cluster needs before it takes real data. Each card below names a component of that scope and the document, configuration or test record the client keeps at the end, so the quote can be compared line by line against the work an internal team would otherwise do.

Schema and sort key design

We design the MergeTree table definitions for your event, log or telemetry data, including the sort key, partition key, data types and codecs. The main deliverable is a schema design document with the query patterns each table was built for, plus the DDL as version-controlled files. Ask the partner to show which queries drive the sort key choice and how a wrong choice would be detected after go-live.

Shard and replica layout

We set the number of shards and replicas per table based on your ingest rate, retention and query concurrency, and document the cluster topology and placement across failure domains. The deliverable is a topology diagram, the remote_servers and macros configuration as code, and a note on what a single replica loss does to reads and writes. Confirm the placement against your own zones or data centers before the quote is final.

ClickHouse Keeper on dedicated hosts

ClickHouse Keeper coordinates ReplicatedMergeTree replication, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. The deliverable is the Keeper ensemble configuration, host sizing notes and a failover test record showing the cluster continues after one Keeper node stops. Confirm that your infrastructure can provide three separate hosts before the scope is agreed.

Ingestion pipelines

We build the paths that load data into ClickHouse, covering batch sizes, insert patterns, deduplication behavior and handling of malformed records. The deliverables are the pipeline configuration as code, a data contract for each source and a runbook for replaying a failed batch. Ask which upstream systems are in scope and who owns the source-side formats, since changes there drive most of the rework.

Retention policies

We define TTL rules and partition drop schedules per table so that data expires on the timeline your compliance and cost owners agreed. The deliverable is a retention matrix listing each table, its retention period, the rule that enforces it and the owner who approves changes. Confirm which retention periods are legal or contractual requirements, because those set the scope rather than the storage budget.

BACKUP and RESTORE configuration

We configure full and incremental backups with BACKUP and RESTORE to the storage you choose, which can be local disk, S3-compatible storage or Azure Blob Storage. The deliverables are the backup job definitions, retention for backup sets, and a runbook that covers partial and full restores. Replication does not protect against human error or corruption, so confirm the backup target is separate from the cluster's failure domain.

Access control and tested restore

We configure users, roles, row policies, settings profiles and quotas through SQL, restrict the default user, and connect external authenticators where your directory requires it. The final deliverable is a restore test record on a spare cluster, showing the time taken and the row counts checked against the source, because the ClickHouse documentation warns that an untested backup will probably not restore when needed. Ask for the restore test record as a condition of acceptance.

What drives ClickHouse implementation cost and duration

This table lists the main factors that change the effort of a self-hosted ClickHouse rollout, why each one matters and one way to keep it under control. Read each row as a question to answer during scoping, because the combined effect of several drivers usually matters more than any single one.

Driver	Why it changes effort	How to keep it down
Data volume and ingestion rate	Higher volumes need more partition, merge and disk tuning, and high ingestion rates require batching and backpressure design in the pipeline.	Agree a sizing test on representative data before the build, and batch inserts at the source rather than tuning later.
Number of tables and query patterns	Each table needs its own engine, sort key and partitioning choice, and each query pattern must be tested against that design.	Limit the first release to the highest-value tables and queries, and add the rest in later phases.
Replication and shard count	Replicated tables, Keeper nodes and shard layout add failover testing, network design and more operational runbooks.	Start with the replication level your availability target requires and document when a second shard becomes necessary.
Number of source systems	Each source needs its own schema mapping, ingestion path, error handling and data quality checks.	Onboard sources in waves with a shared ingestion pattern instead of building each one as a custom pipeline.
Retention and tiering requirements	Retention rules drive partition expiry, storage tiers, object storage configuration and restore scope for backups.	Confirm retention periods per dataset early, since fewer distinct policies mean fewer configurations to test.
Authentication integration	Connecting LDAP, Kerberos, X.509 certificates or JWT to your identity systems requires directory mapping, service account design and access testing.	Pick one directory integration for the first release and map groups to a small set of roles.
Number of environments	Each environment needs its own cluster, data refresh process, configuration management and upgrade rehearsal.	Keep pre-production small but representative, and automate deployment so each extra environment is a repeat, not a new build.
Compliance evidence needs	Assessors may ask for access records, backup restore test results, change history and configuration baselines, which add collection and documentation work.	Agree the evidence list in writing at scoping and design logging and backup reports to produce it automatically.
Prior ClickHouse experience	Teams new to ClickHouse usually need time to learn sort key design, merge behavior and Keeper operations, which lengthens design and testing.	Plan a knowledge transfer step and have your engineers work alongside the implementation team from the start.

How a ClickHouse implementation moves from design to handover

The sequence moves from workload discovery to a tested, replicated and backed-up production cluster, with each phase closing on a named output that the next phase depends on. Your team reviews each output before the work moves on, so scope changes surface early.

Discover data sources and query workload
DeployOpen interviews your data owners and analysts to list each event, log or telemetry source, its daily volume and its arrival pattern. We also collect the queries users run today, how often they run, the latency they need and how many run at the same time. The output is a written workload inventory that your team signs off, and it sets the boundaries for every later decision. Confirm with your analysts which questions matter most, because those queries drive the design.
Design schema and sort keys against representative queries
The team turns the inventory into table definitions, choosing sort keys, partitioning and data types that match the filters and aggregations in the representative queries. Each design choice is tested by running those queries against sample data and reviewing how much data each one reads. The output is a schema document with the reasoning for each sort key, plus query results that show the design works for the agreed workload.
Build a pre-production environment with representative data
DeployOpen builds a pre-production cluster in your infrastructure and loads a representative data set, which the ClickHouse production guidance recommends before any production upgrade or change. The team runs the agreed queries there and compares results and timings with the design targets. The output is a test report and a pre-production environment that your team can use later to test upgrades and schema changes.
Build Keeper nodes and replicas
The team deploys ClickHouse Keeper and the replicated tables that depend on it. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, and each Keeper node should have about 4 GB of RAM. We then stop one replica during a controlled test and confirm that it syncs missing data from a healthy replica automatically once it returns. The output is a replication test record showing the recovery behavior in your environment.
Configure ingestion and retention
The team builds the ingestion pipelines from the sources identified in discovery and sets the retention rules that remove or move older data on a schedule your data owners agree to. Ingestion is tested at production-like volume to check for merge backlogs, duplicate rows and failed batches. The output is a documented pipeline set with monitoring for lag and errors, and a retention policy that your compliance owner has reviewed.
Configure backups and test a restore on a spare cluster
DeployOpen configures BACKUP jobs to your chosen target, which can be local disk, S3-compatible storage or Azure Blob Storage, and sets full and incremental schedules. The backup documentation warns that a backup never test-restored will probably not restore properly, so the team restores a copy onto a spare cluster and checks row counts and query results. The output is a restore test report and a written restore runbook. Confirm the storage target and retention of backups with your security team before this step closes.
Cut over to production and hand over
The team moves ingestion to the production cluster in an agreed window, restricts the default user and sets up roles, row policies and quotas as your access model requires. Post-cutover checks compare query results, ingestion lag and replication status against the pre-production baseline. The output is the handover package: architecture and configuration documentation, operating runbooks, access records and a list of open items, with your operations team trained to run it.

Which parts of a ClickHouse implementation teams keep in-house

Most teams keep the work that only they can decide. Data ownership, query semantics and business definitions belong to the people who understand what an event, a session or a revenue figure means. Someone inside the organization has to decide which source is authoritative, how late-arriving records are treated, who may read which tables and what a dashboard number is allowed to mean. A partner can help document these decisions, but it cannot make them. On-call acceptance belongs internally for the same reason: the team that will be woken at night needs to agree on alert thresholds, escalation paths and the definition of a recovered service before go-live. The skills behind these decisions are mostly analytical rather than infrastructural. Schema work depends on MergeTree and sort key expertise, because the ORDER BY key and partitioning choices determine which queries stay fast and which scan large parts of the data. Teams that already know their query patterns can own this design, provided at least one engineer has run ClickHouse tables under real load before. Without that experience, the sort key is usually where a rollout quietly loses performance, and it is hard to reverse once billions of rows are loaded.

Other parts of the rollout are often outsourced because they draw on operations skills that many analytics teams do not keep busy. Cluster design, shard and replica layout, and ClickHouse Keeper setup require Linux and network operations, along with an understanding of how replicated tables behave when a node fails. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, so the question for the internal team is whether it already runs quorum-based services and has spare hosts for them. If it does, this work can stay in-house with a documented runbook. If it does not, the work tends to be expensive to learn during an incident.

Backup and restore testing and hardening sit in the gap between platform operations and security engineering. The backup documentation notes that replication alone does not protect against human error or corruption, and it warns that a backup never test-restored will probably not restore properly when needed. Writing backups to S3-compatible or Azure Blob Storage requires object storage administration, including bucket policies, lifecycle rules and credential handling. Hardening requires security engineering for the default user, role design, TLS on native and HTTP ports, and external authentication through LDAP, Kerberos or JWT. Internal teams with these skills, and time to run a restore on a spare cluster, can keep this work. Teams without them should price an external review before committing to a go-live date.

When you compare options, ask a partner to separate its quote into these groups rather than as one number. For each group, confirm who holds the skill today, who will operate the result after handover and which deliverables prove it works, such as a tested restore record or a signed-off access model. A hybrid split is common: the internal team owns data and definitions and the partner builds and documents the platform, then the internal team runs the restore tests itself. Confirm the split with your own staff before the scope is agreed, because the work that is most often underestimated is the operations that continue after the build is finished.

What usually goes wrong in a ClickHouse rollout and how to prevent it

Most ClickHouse rollouts that run into trouble fail on decisions made early: table layout, coordination, recovery, access, upgrades and ingestion capacity. Each card names one pattern, the prevention step and the check that shows the step is in place. Use them as a review list in design sessions and before go-live.

Sort keys chosen without query data

The sort key controls how MergeTree tables store and skip data, so it shapes query speed for the life of the table. Teams that choose it from the schema alone often find that dashboards filter on other columns and scan most of the table. Prevention: collect the most common filters and time ranges from existing query logs and dashboards before finalizing the key. Check: review the query plan for representative queries in pre-production and confirm that the primary key is used.

Keeper undersized or shared with data nodes

ClickHouse Keeper coordinates ReplicatedMergeTree replicas, so its health determines whether replicated tables keep accepting writes. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Running Keeper beside busy data nodes lets query memory pressure delay coordination. Prevention: budget separate hosts for Keeper in the plan and cost. Check: confirm node count, host separation and memory in the design review, then test losing one Keeper node in pre-production.

Replication or untested backups

Replicas protect against hardware loss, but a bad delete or a faulty ingestion job reaches every copy. The backup documentation states that replication alone does not protect against human error or corruption. Prevention: schedule BACKUP runs to storage outside the cluster's failure domain, with full and incremental backups. Check: restore to a spare cluster on a fixed cadence, compare row counts with the source, and treat a failed restore as a release blocker.

Default user left with full permissions

ClickHouse starts the default user with all permissions. If that account stays open, any client that reaches the native or HTTP port can read, alter or drop data. Prevention: create named users and roles through SQL, restrict or disable the default user, and bind service accounts to narrow roles. Check: connect as each role and confirm that out-of-scope statements are denied, then review the grants with the client during handover.

Upgrades applied without changelog review

Stable releases ship roughly monthly, and the production FAQ notes that minor backward-incompatible changes can occur. Upgrading without reading the changelog or rehearsing in pre-production moves that risk into production. Prevention: read the release notes for every version in the upgrade path and confirm the version appears in the security policy's supported list. Check: run the upgrade on a pre-production cluster with representative data before each change window, and keep a written rollback path.

Ingestion that outruns capacity

Each insert creates parts that background merges must consolidate, so a pipeline that writes faster than the cluster can merge builds a backlog that slows queries. Teams often size storage for data volume and overlook insert rate and batch size. Prevention: batch inserts, cap concurrent writers and size CPU and disk for merge work at projected peak rate. Check: load test at peak with the real batch shape and track the parts count and merge backlog against a threshold agreed before go-live.

Recurring ClickHouse costs after go-live

This table lists the costs that continue after a self-hosted ClickHouse cluster goes live and marks which items recur. Read each row as a checklist of who pays, what drives the amount and what to request in a written quote. The main takeaway is that compute, storage, backups, upgrades and staff time recur for as long as the cluster runs, so the quote should price them separately from the one-time build.

Cost component	One-time or recurring	What drives it
Compute for data nodes	Recurring	Shard and replica count, query concurrency and ingestion rate. Confirm sizing in pre-production with representative queries.
Keeper nodes	Recurring	At least three Keeper nodes on dedicated hosts, about 4 GB RAM each per the ClickHouse replication guide.
Storage tiers	Recurring	Retention period, data compression and whether older partitions move to cheaper volumes.
Object storage for backups	Recurring	Backup frequency, incremental chain size and how many backup copies you keep.
Network egress	Recurring where applicable	Cross-zone replication traffic, backup copies leaving your network and restore tests on spare clusters.
Monitoring and logging	Recurring	Metric and log retention, alert volume and the tooling you already run.
Upgrade effort	Recurring	Monthly stable or twice-yearly LTS cadence, pre-production testing and changelog review before each upgrade.
Support agreement	Recurring, if chosen	Covered hours, response expectations, upgrade assistance and restore test support. Confirm scope in writing.
Internal staff time	Recurring	On-call coverage, schema changes, access reviews and periodic restore tests.

How ClickHouse implementation work changes by starting point

When the team already runs ClickHouse, the first question is which version line the cluster is on and whether it is still supported. The security policy lists 26.9, 26.8, 26.7 and 26.3 as supported for security updates, and all other versions as unsupported. An older cluster may need several version steps, and the work changes depending on how far behind it is.

What changes in the design:

The target line is chosen between monthly stable releases and twice-yearly LTS releases, with the production FAQ recommending stable for most production use.
Schema and query changes are reviewed against the changelog, because minor backward-incompatible changes can occur.
The upgrade path is planned around replicas, so each node is upgraded while the others keep serving reads and writes.

Effort drivers that shift:

The number of version steps between the current and target release.
Queries, dashboards and ingestion jobs that depend on behavior changed between releases.
The size of a pre-production environment with representative data and queries.

Confirm in the client's environment: the exact running version on every node, whether any table uses features removed or changed since then, and whether a recent, tested backup exists before the first step.

What the client must provide before a ClickHouse implementation starts

The fastest way to keep a ClickHouse schedule and quote stable is to have the client inputs in hand before design begins. Most overruns in a self-hosted rollout trace back to missing data, undecided infrastructure or unnamed owners rather than to the database itself. The list below is what we need from your side, and each item changes either the calendar or the price of the work. Start with source access and sample data. Schema and sort key design depends on how events actually arrive: column types, cardinality, null patterns, timestamp quality and daily volume. Ask for read access to the source systems and a sample that reflects real volume and skew, not a tidy extract. A sample of a few gigabytes that omits your noisiest tenant will lead to a sort key that fails in production. Confirm who owns each source, how long extracts take to produce, and whether personal or regulated fields must be masked before they leave the source. Next, provide a representative query set with named owners. ClickHouse performance is decided by the queries you run, so we need the dashboards, alerts, scheduled reports and ad hoc analyses that matter, with the person accountable for each. Ask each owner for the expected time range, filters and concurrency. Without this, sort keys and projections are guesses, and acceptance testing has nothing concrete to measure. Expect the query review to run in parallel with schema design, and expect extra cycles if owners are unavailable. The hardware or cloud account decision is the largest single schedule dependency. Decide whether ClickHouse runs on virtual machines, bare metal or Kubernetes, in which account or data center, and with which storage classes. Also confirm the object storage target for backups, including the bucket or container, retention rules, and the service credentials we will use. Backup credentials that are issued late delay restore testing, which is the step most often skipped under pressure. Network and DNS details, identity provider contacts, and the release track decision complete the list. Provide subnets, firewall change windows, DNS zones, certificate authorities and load balancer requirements. Name the identity provider contacts who will support LDAP, Kerberos, X.509 or JWT integration, because directory changes have their own approval queues. Finally, choose between the stable and LTS release tracks, since that choice sets the upgrade cadence and the test effort you should budget for. Name owners for data, security and on-call before kickoff, because each decision needs an accountable signer.

ClickHouse implementation questions buyers ask before hiring help

What drives the cost of a self-hosted ClickHouse implementation?

Cost follows the size and shape of your data and the number of environments you must run. The main drivers are:

Data volume and ingest rate
Number of tables and sort key design
Number of shards and replicas, and the Keeper nodes that coordinate replicated tables
Ingestion pipelines from Kafka, log shippers or batch jobs
Retention rules and tiered storage
Backup storage capacity and restore tests on spare capacity

One-time work covers design, build, migration and testing. Recurring costs include the infrastructure you pay your cloud or data center provider, monitoring, upgrades and any support retainer. When you request a quote, ask for a line-by-line breakdown of what is one-time and what recurs, the environments included, and which of your inputs the estimate assumes.

How long does a ClickHouse implementation take from start to go-live?

Duration depends on scope and inputs, and no single timeline applies to every deployment. The biggest factors are how many datasets and query patterns must be supported, how clean the source data is, how many ingestion paths exist, and whether tables must be redesigned after a first query test. Access integration, network approvals and cloud provisioning often set the critical path more than ClickHouse itself. Testing with representative data and queries in pre-production takes time that you cannot skip if you need predictable performance. Ask for a phased plan with milestones, the inputs you must provide and the dates each one depends on. Your team can shorten the work by providing sample data, query logs, retention requirements and a named owner for approvals before the engagement starts.

Can a ClickHouse implementation be quoted as a fixed-scope project?

Yes. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A fixed scope works best when the inputs are known: the datasets in scope, the expected ingest rate, the query patterns that must perform, the retention periods, the number of environments, and the sources and targets for each pipeline. Changes that add datasets, sources or cluster topology after signing are handled as a written change to scope. Ask the vendor to state the assumptions behind the quote, the acceptance tests, what the client must provide, and what happens if an input turns out different from the assumption. Ongoing support, upgrades and continuous testing are available as separate retainers, so do not mistake the implementation quote for run costs. A quote follows from the written scope.

Can our own team implement ClickHouse without outside help?

Yes, a team with Linux operations, SQL and data engineering skills can deploy ClickHouse. The open-source server is licensed under the Apache License 2.0. The harder work surrounds the server: schema and sort key design that matches actual query patterns, replication with Keeper, backups with restore tests, access control, TLS and upgrade procedures. Teams usually struggle when no one has run a replicated cluster through a failure and a recovery. Check whether you can staff a pre-production environment, a restore test and an upgrade within your normal operating cadence. A partner makes more sense when the timeline is fixed, the data is regulated, or the team needs to build skills during the project. One option is a hybrid model, where DeployOpen builds the platform and your team operates it with documented runbooks.

How many Keeper nodes does a replicated ClickHouse cluster need?

The ClickHouse replication guide recommends at least three Keeper nodes, placed on dedicated hosts in production, with about 4 GB of RAM each. Keeper replaces ZooKeeper for coordinating ReplicatedMergeTree tables, and an odd number of nodes lets the ensemble keep a quorum when one node fails. Three is the documented minimum for production, and it does not size the coordinator for large workloads. Keeper load grows with the number of replicated tables and the volume of replication metadata, so confirm the RAM and disk for your workload before ordering hardware. Keep Keeper off the ClickHouse data hosts where possible, because a busy data node can starve the coordinator. Your inputs are the number of replicated tables, the number of shards and the availability target you need.

Does replication replace backups for ClickHouse data?

No. Replication keeps copies of data in sync across replicas, and a recovered replica automatically syncs missing data from a healthy replica. The backup documentation notes that replication alone does not protect against human error or corruption, because a destructive statement such as a bad DROP or DELETE is applied to every copy. ClickHouse BACKUP and RESTORE support full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. Plan backup retention, storage location and encryption separately, and treat each backup as a recovery target you have proven. The documentation warns that a backup never test-restored will probably not restore properly when needed, so schedule regular restore tests on spare clusters and record how long each restore takes.

What must be tested before a ClickHouse go-live?

Test the workload you will run in production, in a pre-production environment with representative data and queries. The ClickHouse production guidance recommends this setup and reading the changelog before any upgrade, because minor backward-incompatible changes can occur. Cover these areas:

Query latency on your actual query set at expected concurrency
Ingest throughput under peak load
Schema changes checked against sort key choices
Replica failover, by stopping a node and confirming the recovered replica syncs
A full restore from backup into a spare cluster, with row counts and key queries checked
Access control, TLS on native and HTTP ports, retention jobs and alerting

Record the results and the rollback steps in writing before the go-live decision.

Is ClickHouse Cloud a viable alternative to self-hosting ClickHouse?

It can be, depending on where your data must live and who must operate it. The ClickHouse server is open source under the Apache License 2.0, and ClickHouse Inc. separately sells ClickHouse Cloud as a managed service. Self-hosting fits when data residency, network isolation or air-gapped operation require the cluster to run in your cloud accounts, data centers or networks, and when your team wants direct control over versions and retention. A managed service moves Keeper, patching and capacity operations to the provider, but you still need to review its security configuration, data location and exit path. Compare both options with a multi-year cost model that includes people, storage tiers and support, and test each option against your compliance requirements. DeployOpen works on self-hosted platforms inside your own infrastructure, so this page covers that path.

How DeployOpen scopes, delivers and hands over ClickHouse work

DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, and ClickHouse work follows the same written path. Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before any build starts.

How we scope

We confirm the analytical workloads, data sources, retention needs and query patterns the ClickHouse cluster must serve.
The written scope lists schema and sort key design, shard and replica layout, Keeper nodes, ingestion paths and backup targets.
We name the versions to deploy from the currently supported release lines, and confirm your choice between stable and LTS.
Quotes follow from the written scope, so each cost component and client-side dependency is visible before you commit.

How we build

We build in a pre-production environment with representative data and queries before anything touches production.
Replicated tables are set up with ClickHouse Keeper on dedicated hosts, with replication tested by failing and recovering a replica.
Backup and restore jobs are configured and then exercised with restore tests on a spare cluster, not just scheduled.
Access control is set up through SQL-driven users, roles and row policies, with the default user restricted before go-live.

How we hand over

You receive the documented architecture, configuration, runbooks for failover, backup and restore, and upgrade procedures.
Restore test results, query and ingestion benchmarks, and access control records are delivered as evidence for your own reviews.
Knowledge transfer sessions are held with your platform and data engineers so they can operate the cluster after handover.
Open items, known limits and the changelog review needed before future upgrades are listed in the handover pack.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
Retainers can cover monitoring follow-up, upgrades between supported releases and restore test cycles on a schedule you agree.
Upgrades are tested in pre-production first, since minor backward-incompatible changes can occur between releases.
Ask any provider to confirm which ClickHouse versions they support and how security updates are applied in your environment.