When one ClickHouse server is enough and when a replicated cluster is worth it
One ClickHouse server is enough when the analytics workload can tolerate a restart window and a restore from backup, and a replicated cluster is worth its cost when the business needs the data to stay queryable through a host failure. The deciding question is not how large the data is but how long your users can wait while a lost host is rebuilt. A single server means one host to lose, so every hardware fault, failed disk or bad upgrade stops queries until the box returns or a backup is restored. The replication guide's minimum for one shard with two replicas is five servers: two ClickHouse servers that each hold a copy of the data, and three ClickHouse Keeper nodes that coordinate replication through quorum. Keeper nodes are small but not free. The guide recommends dedicated hosts in production with about 4 GB of RAM each, so a "second server" plan quietly becomes five machines to patch, monitor and back up. A single node with tested backups can suit many internal analytics workloads, such as weekly reporting, ad hoc exploration by a small team or dashboards that can be rerun after an outage. In that case, the work to invest in is restore testing, since the backup documentation warns that a backup never test-restored will probably not restore properly when needed.
Move to a replicated layout when the dashboards or customer-facing queries have a stated availability target, when a missing day of data would cause business harm, or when a single host already runs close to its limits and cannot be taken down for maintenance. Add shards only when one replica set can no longer hold the data or serve the query load, which is a separate decision from availability. Before committing, confirm with your own team how long a rebuild would take at your data volume, who owns Keeper and replica monitoring, and whether your upgrade process can roll through replicas one at a time. Replication also does not protect against human error or corruption, so backups remain necessary in both layouts.
Single-node and replicated layouts compared factor by factor
This table sets one ClickHouse server against a replicated layout with two replicas and a Keeper quorum across eight factors. Read each row as the question to answer for your own environment, and treat the cells as the documented starting point rather than a sizing decision.
| Factor | Single-node ClickHouse | Replicated cluster (one shard, two replicas) |
|---|---|---|
| Host count | One ClickHouse server, plus whatever backup target you choose | Five servers in the documented layout: two ClickHouse servers holding data and three ClickHouse Keeper nodes |
| Coordination service | None required for replication | ClickHouse Keeper, which replaces ZooKeeper; the replication guide recommends at least three Keeper nodes on dedicated hosts in production |
| Failure behavior | A host failure stops the service until the host or a restore returns it | With two replicas, one host can fail and the surviving copy keeps data available; confirm the behavior of your queries and client failover in a test |
| Data protection | Protects only against hardware loss if backups exist elsewhere | Replicates data across two hosts, but the documentation notes replication alone does not protect against human error or corruption |
| Upgrade approach | Upgrade one server, with a pre-production run on representative data and queries | Upgrade replicas in sequence and test mixed-version behavior; read the changelog first, since minor backward-incompatible changes can occur |
| Backup dependence | Full reliance on BACKUP and RESTORE to recover from deletion or corruption | Still relies on BACKUP and RESTORE for logical errors; replication only resyncs a recovered replica from a healthy one |
| Operating skills | ClickHouse administration, backup scheduling and restore testing | Adds Keeper operation, replica health monitoring, resync oversight and quorum troubleshooting |
| What drives cost | Server size, storage, backup target, and the restore testing effort on a spare environment | Five hosts including dedicated Keeper nodes (about 4 GB of RAM each per the replication guide), added storage for each replica, and the staff time to run both tiers; ask any quote for each host and its support scope |
How ReplicatedMergeTree and Keeper keep two copies in step
ReplicatedMergeTree works like MergeTree but also replicates the data. With two replicas, the same table exists on two ClickHouse servers, and a failed host catches up when it returns. ClickHouse Keeper, which replaces ZooKeeper as the coordinator, tracks replication state and quorum for those tables. The two replicas and the Keeper nodes are separate roles, so a two-replica layout still needs three Keeper nodes, which is why the five-server count applies. Before you commit, confirm with your own topology that the Keeper nodes will not share hosts or failure domains with the data servers, because a shared host removes the quorum benefit you are paying for.
A recovered replica syncs missing data from a healthy replica automatically, according to the ClickHouse replication guide, so an outage of one data server does not require manual copying in the normal case. For production, the guide recommends at least three Keeper nodes on dedicated hosts, with about 4 GB of RAM each. Treat those figures as the documented starting point and check them against your ingest rate and monitoring data. Plan for Keeper placement, RAM, and network latency between nodes as part of the design, not as an afterthought.
Replication is not backup. Replicas copy mistakes as faithfully as they copy good data, so a dropped table or a bad ALTER reaches every replica within moments. The ClickHouse backup documentation makes the same point, noting that replication alone does not protect against human error or corruption. Plan a separate backup path using BACKUP and RESTORE to local disk, S3-compatible storage or Azure Blob Storage, and schedule restore tests on a spare cluster. Ask your team who owns those restore tests and how often they run, because an untested backup will probably not restore when you need it.
When adding shards makes sense, and when replicas are the better step
Replicas and shards solve different problems, and teams often reach for the wrong one. Replicas keep a copy of the same data on another host so service survives a failure, while shards split the data across hosts so that no single machine has to hold or scan all of it. The cards below set out the signals that point toward each step and what to measure in your own environment first.
Availability is the first driver
If a single host failing would stop reporting or ingestion for too long, the first need is a second copy, not more capacity. A ReplicatedMergeTree pair keeps the same data on two hosts, and a recovered replica syncs missing data from its healthy peer. Replicas do not add write or storage capacity, so measure your tolerated downtime and recovery time before deciding.
Dataset outgrows one host
Shards become relevant when the data itself no longer fits comfortably on one server, including the room needed for merges and backups. Each shard holds a different slice of the rows, so a query touches several hosts in parallel. Measure table size on disk, growth per month and free space headroom on your current host, and check whether a single partitioning key distributes rows evenly.
Query latency under heavy scans
When analytical queries scan large date ranges and run too slowly on one server even after schema and index tuning, splitting the table lets each shard scan a fraction of the rows. This helps most for wide aggregations. Before adding shards, capture p95 query time on representative queries, and confirm the slow queries are CPU or I/O bound on one host rather than blocked by merges or poor ordering keys.
Concurrency and write throughput
Many simultaneous users or a steady high insert rate can saturate one server's CPU, memory or disk queues even when the data fits. Shards spread inserts and queries across hosts, while replicas only help reads if your client routing sends queries to them. Measure peak concurrent queries, insert rate and merge backlog, and test whether the bottleneck moves when you add a second host.
Sharding key and per-table sizing
Sharding is a per-table decision, so a few very large tables may justify it while small dimension tables stay on one host. A poor sharding key causes skewed shards, uneven load and joins that move data across the network. Check row counts and key cardinality per table, and write down which joins must stay local before choosing a key.
Operating cost of each step
Each shard adds hosts, and each replicated shard adds replicas plus the Keeper quorum that coordinates them. Ask your team who patches, backs up and restore-tests every host, and budget for that work recurring alongside the hardware. Backups still need separate handling because replication does not protect against human error or corruption. Confirm the operating load with your own staff or with a partner quote before committing to a layout.
Which layout fits internal analytics, customer-facing dashboards and regulated workloads
Internal reporting usually tolerates planned downtime. Analysts refresh dashboards, batch jobs load data overnight, and a short maintenance window rarely stops a business process. In this situation a single ClickHouse server is often enough, especially when the data fits on one host with room for merges and backups. The main risk is not a failed node but a lost or damaged dataset, so the team should plan backups and restore tests before it plans replicas.
- Single server fits: One node with local storage suits teams whose reports can wait for a restart after an upgrade or a host repair.
- Backups carry the protection: ClickHouse BACKUP and RESTORE can write to local disk, S3-compatible storage or Azure Blob Storage, and replication alone does not protect against human error or corruption.
- Replicas become worth it when: Dashboards become a daily dependency for many people, or a host outage would block a finance or operations cycle that cannot slip.
- Upgrades move to a window: Stable releases ship roughly monthly and LTS releases twice a year, so a single node means a planned restart for each upgrade.
- Adding a second cluster member later requires a Keeper quorum and a data copy, so the team should size its storage and network with growth in mind.
Before choosing, confirm how long a restart and restore would take in your environment and whether the business accepts that window for each month-end cycle.
Customer-facing analytics carries an uptime expectation that internal reporting does not. When a customer's embedded dashboard fails, the failure is visible outside your organization and often lands in a support queue or a contract review. A replicated layout is the usual starting point here, because ReplicatedMergeTree keeps the data on two hosts and a recovered replica syncs missing data from a healthy one without manual intervention. Replication alone still does not cover bad writes, so the backup and restore plan remains required.
- Two replicas with Keeper: The minimum for one shard with two replicas is five servers: two ClickHouse servers for data and three ClickHouse Keeper nodes for coordination.
- Dedicated Keeper hosts: The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each.
- Shards follow data volume and query load: Add shards when one shard cannot hold the data or serve the concurrency, not only because a host is failing.
- Upgrade rehearsal matters more: Reading the changelog and testing on representative data is necessary, since minor backward-incompatible changes can occur.
- Edge cases change the answer: Very low query volume, a single customer tenant or a tolerance for short degraded periods may keep a single node viable.
Confirm your uptime commitments in writing, the latency each customer expects during a failover, and who on your team will run the Keeper quorum and upgrades.
Regulated environments need documented recovery more than any particular topology. A replicated cluster can be part of the design, but it does not by itself produce the recovery evidence an assessor will ask for. The layout should be chosen together with the backup schedule, the restore test procedure, the upgrade process and the access controls. DeployOpen can help prepare systems, controls and evidence for a compliance assessment, but independent auditors decide whether those controls meet the requirement.
- Replication is not recovery: The backup documentation states that replication does not protect against human error or corruption, so backups must exist alongside the replica design.
- Restore tests are the proof: The documentation warns that a backup never test-restored will probably not restore properly, and recommends regular restore tests on spare clusters.
- Authentication options: ClickHouse supports LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT as external authenticators, which may map to your identity standards.
- Support window drives the upgrade plan: Only versions listed as supported in the security policy receive security updates, so the team needs a dated upgrade path.
- Confirm with your assessor: Ask which recovery objectives, evidence and retention rules apply to your data before choosing between a single node and a cluster.
Write down your recovery procedure and the evidence it produces, then check it against the framework your assessor uses.
What backup, restore testing and upgrades add to a cluster
This sequence turns a replicated ClickHouse cluster from a set of running servers into one you can recover and change safely. Replication alone does not cover human error or corruption, so backups, proven restores and a staged upgrade path each close a different gap.
Define the backup scope and retention
The data owner and the platform team agree which databases, tables or partitions must be recoverable and how far back they need to go. Replication keeps two copies in sync, so a bad DROP or a corrupting write reaches both replicas, which is why backup scope is a separate decision. Write the scope into the runbook and name the owner of each dataset. The step is done when every production database has a documented scope and an owner who signed it off.
Choose backup destinations and methods
The platform team picks where backups land: local disk, S3-compatible storage or Azure Blob Storage, as supported by ClickHouse BACKUP and RESTORE. They also decide between full and incremental backups for each scope. Confirm the target storage's durability, access controls and separation from the cluster's failure domain with your storage team, since a backup stored on the same host as the data offers limited protection. The step is done when a test backup of one table completes to the chosen destination and its location is recorded.
Schedule automated backups with monitored results
The platform team wires BACKUP jobs into the scheduler you already run, with alerts on failure and on backups that run longer than expected. Each run should record its name, scope and destination so the on-call engineer can find the latest good copy quickly. Ask the vendor or your DeployOpen engineer to confirm how incremental chains are rebuilt before you rely on them. The step is done when several consecutive scheduled backups succeed and the failure alert has been triggered once on purpose.
Run restore tests on a spare cluster
The operations team restores recent backups into a separate spare cluster that matches production's version and layout as closely as budget allows. ClickHouse documentation warns that a backup never test-restored will probably not restore properly when needed, so this is the step that proves the backup works. Compare row counts and checksums on key tables against production, and time the restore so you know the recovery path. The step is done when a restore completes and the data matches the source for each tested scope.
Read the changelog before each upgrade
Before any version change, the platform team reads the release notes between the current and target versions. ClickHouse notes that minor backward-incompatible changes can occur, so this review finds settings, query behavior or table changes that affect your workload. Check the ClickHouse production FAQ and the security policy for the currently supported lines, and confirm whether your current version is still receiving security updates. The step is done when a written change list names every incompatible item that touches your schemas or queries.
Test the upgrade on a pre-production environment
The team builds a pre-production environment with representative data and real query patterns, then runs the target version against it. ClickHouse recommends stable releases for most production use and a pre-production environment with representative data and queries, so this environment should be sized and loaded to reflect production shape. Measure query results, latency and ingestion throughput against the current version. The step is done when the target version passes the agreed query set and the results are signed off by the application owner.
Stage the upgrade one replica at a time
In production, the operations team upgrades one replica, lets it resync, verifies queries, and then moves to the next. A recovered replica automatically syncs missing data from a healthy replica, which makes rolling changes workable, but the second replica should stay healthy throughout. Keep Keeper nodes and their quorum in view during the change, and hold the rollback path open until both replicas are verified. The step is done when both replicas run the target version, replication lag is normal and the post-upgrade checks pass.
Plan the support window for each version line
The team sets a recurring review of the version it runs against the supported list and the LTS support window. ClickHouse LTS releases ship twice a year and are supported for a year after release, and the security policy lists which lines receive security updates, so a cluster on an unsupported line needs a planned move. Calendar the next review and the next upgrade cycle, and confirm the dates with ClickHouse's current release notes. The step is done when the cluster's version, its support end date and the next review date are recorded in the operations runbook.
What drives the cost of each ClickHouse layout
The single-node layout needs one ClickHouse server, but the replicated layout needs five servers at minimum for one shard with two replicas: two ClickHouse servers that hold copies of the data and three ClickHouse Keeper nodes that coordinate replication, as the ClickHouse replication documentation describes. Host count is the largest recurring line item, and it multiplies with CPU, memory and disk per host. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each, so those Keeper hosts are not free capacity you can reuse from the data servers. Each Keeper host also needs its own patching, monitoring and restart discipline. Ask the vendor or integrator to price the five hosts separately from the data hosts, and to state whether Keeper runs on dedicated machines.
Storage and backup costs grow with the data, and replication doubles the stored copies on the two replicas. Backups are a separate cost: ClickHouse BACKUP and RESTORE can write to local disk, S3-compatible storage or Azure Blob Storage, and the backup documentation notes that replication alone does not protect against human error or corruption. Confirm the backup target, its retention period, the backup frequency and whether incremental backups are included. Network capacity between replicas and to Keeper is a further recurring cost, and monitoring (metrics, log retention and alerting for replica lag and Keeper health) adds tooling plus staff attention.
Staff time is where most of the ongoing spend sits. Upgrades need a pre-production environment with representative data and queries, and the production FAQ advises reading the changelog first because minor backward-incompatible changes can occur. Restore tests need spare capacity, since the backup documentation recommends regular restore tests on spare clusters. Incident response for a replicated cluster covers replica resync and Keeper quorum loss. For the quote, request host specifications for each role, the backup target and retention, the upgrade test scope, the restore test frequency, the Keeper placement and who on your side must be on call. Setup is largely one-time work, while patching, upgrades, restore tests and monitoring recur for the life of the cluster.
Questions teams ask before moving from one ClickHouse server to a cluster
Is a single ClickHouse server enough for production?
It can be, provided you accept that one host is a single point of failure and that the data exists only on that host until you add a copy. A single server suits analytics where a short outage is tolerable and the data can be rebuilt from sources or restored from backup within the window your business allows. The questions to settle are how long a restore takes on your hardware, how much data you could lose since the last backup, and whether dashboards or customer-facing queries can wait for a rebuild. Confirm these against a restore test in your own environment, because the ClickHouse backup documentation warns that a backup never test-restored will probably not restore properly when needed.
How many servers does a replicated ClickHouse cluster need?
The replication guide describes five servers for one shard with two replicas: two ClickHouse servers hold copies of the data and three ClickHouse Keeper nodes coordinate replication. The guide recommends at least three Keeper nodes for high availability and quorum, and recommends running them on dedicated hosts in production with about 4 GB of RAM each. Keeper hosts are a recurring cost even though they store little data, so count them in the hardware and licensing plan from the start. Adding shards to spread data across more hosts is a separate decision driven by data volume and query load, not by availability.
What work can our team do itself, and what might need outside help?
Your team can run a single server with standard operating skills if it has Linux administration, monitoring and a tested restore procedure. A replicated layout adds Keeper administration, network design between replicas, access control configuration, and a runbook for failed replicas, which the replication guide says resync automatically once they return. Outside help is most useful for the parts that are easy to get wrong without experience: the migration plan, the backup and restore tests, security hardening of authentication such as LDAP, Kerberos or JWT, and documentation for auditors. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms in your infrastructure, and most engagements are fixed-scope with the scope and deliverables agreed in writing before work starts.
How long does a migration to a cluster take, and what sets the timing?
No duration is documented for this move, so the timing should come from a written plan for your environment rather than a general estimate. The main drivers are the volume of data that must be copied and validated, the number of tables and their engines, how much change control your organization requires, and whether the new hosts, network and Keeper nodes already exist. Access integration and backup verification often take longer than the data copy itself. Ask any implementation partner to break the timeline into planning, build, data movement, cutover and restore testing, and to state which steps depend on your staff's availability.
Does replication replace backups in ClickHouse?
No. Replication keeps a second copy of the data on another host, so it protects against a server failing, but it does not protect against human error or corruption, because a bad delete or a faulty load is copied to the replica as well. The ClickHouse backup documentation supports full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage through BACKUP and RESTORE. Plan both: replicas for availability, and independent backups with scheduled restore tests on a spare cluster for recovery. Confirm the backup destination, retention and restore time objectives with your risk owner before go-live.
How do upgrades differ between a single server and a replicated cluster?
The core advice is the same for both layouts: use stable releases for most production systems, test in a pre-production environment with representative data and queries, and read the changelog before upgrading because minor backward-incompatible changes can occur. A cluster adds sequencing work, since you upgrade replicas one at a time so queries keep running on the others, and you must verify replication health after each step. ClickHouse publishes stable releases roughly monthly and LTS releases twice a year, with LTS supported for a year, so choose a release line and a cadence your team can keep up with. The security policy lists which versions receive security updates, so check it before each planned upgrade window.
What should we confirm with ClickHouse before choosing the layout?
Confirm the supported version lines and their security update windows on the ClickHouse security policy and the GitHub releases page, since these change over time. Ask your team to verify the replication and Keeper configuration against the current replication guide for the release you plan to run, and to test a failed replica and a restore on realistic data. If authentication must integrate with your identity provider, confirm which external authenticators fit your directory setup in the access control and external authenticator documentation. Get these answers in writing before the layout decision is final, because they determine both the node count and the upgrade calendar.
What your team must be able to run before it commits to a cluster
A replicated cluster is a standing operations commitment, so before committing your team should confirm it can run the layer beneath ClickHouse itself. The five-server layout for one shard with two replicas (two clickhouse-server hosts holding data and three ClickHouse Keeper nodes coordinating replication) only works if someone can manage Linux hosts consistently, keep time synchronized, and configure the network and DNS names that replicas and Keeper nodes use to reach each other. Keeper runs best on dedicated hosts in production, so you also need people who can read Keeper health, restart a node, and recover a quorum after a failed host. Ask the vendor or your own platform team which of these skills already exist in-house before you size the project.
The second group of skills concerns recovery and visibility. Replication protects against a failed host but not against a bad DROP or corrupted data, so the ClickHouse backup documentation pairs replication with BACKUP and RESTORE and warns that an untested backup will probably not restore when needed. Your team must schedule restore tests on a spare cluster and own the storage target, whether local disk, S3-compatible storage or Azure Blob Storage. Monitoring must cover replication lag on each replica and Keeper quorum health, because a replica that silently falls behind looks healthy until a failover. Confirm which metrics your existing monitoring stack can collect from ClickHouse and Keeper before you depend on them.
Access control is the third area. ClickHouse supports external authenticators including LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT, and its access control model governs users and roles. Choose the authenticator that matches your identity provider and confirm, in a test environment, how each one behaves across both replicas and the Keeper-dependent DDL path. A small team can usually run the single node, standard backups and a basic monitoring setup alone. It should consider contracting out the first Keeper build, the first failover drill and the first restore test, with the scope and deliverables agreed in writing before work starts.
How DeployOpen scopes and delivers a ClickHouse deployment
The engagement moves from workload and availability requirements to a written topology, a build inside your own infrastructure, tested backups and documented runbooks, with ongoing support available afterward.
Confirm workload and availability requirements
DeployOpen reviews your query patterns, data volumes, ingest rates, concurrency, retention periods and the outage and data loss you can tolerate, with your data and platform owners. The output is a short written requirements record that states whether a single server or a replicated layout is in scope, and which assumptions still need confirmation. The step is done when the client signs off on that record as the basis for the quote.
Agree the topology in writing
Based on the requirements, DeployOpen proposes a layout, such as one server, or one shard with two ReplicatedMergeTree replicas coordinated by a ClickHouse Keeper quorum of three nodes on dedicated hosts. The document covers host counts, sizing assumptions, network paths, storage, and when adding shards would be reconsidered. Your infrastructure team confirms the hosts and capacity they can actually provide. The step closes when the topology is approved and attached to the fixed-scope agreement.
Confirm authentication and access design
DeployOpen maps your identity requirements to ClickHouse access control and external authenticators, such as LDAP, Kerberos, X.509 certificates, or JWT, where your environment supports them. Your identity team confirms which methods are approved and who administers users and roles. The output is an access model and a list of settings to verify against the version you run. The step is done when a test account authenticates through each approved path.
Build in your own infrastructure
DeployOpen installs and configures the servers, Keeper nodes, networking and monitoring inside your cloud accounts, data centers or air-gapped network, using the version your team selects after reading the changelog. Staging is built first with representative data and queries so that behavior can be checked before production. The step produces a configuration baseline stored in your repositories and a staging environment that passes the agreed load and failover checks.
Set up backups and test restores
DeployOpen configures BACKUP and RESTORE jobs to your chosen target, such as local disk, S3-compatible storage or Azure Blob Storage, with full and incremental schedules you approve. Replication is treated as a availability measure only, since it does not protect against human error or corruption. Restore tests run on a spare cluster, and the team records the time and result of each test. The step is done when a backup has been restored and queried successfully, not merely written.
Test failover and upgrade procedures
DeployOpen simulates a replica failure and a Keeper node loss in staging, then confirms that the failed host resyncs when it returns and that the surviving quorum keeps serving reads and writes as designed. The same staging environment is used to rehearse a version upgrade, including a review of changelog items that may be backward-incompatible. The output is a dated test log with pass or fail results. The step closes when both rehearsals match the written expectations.
Document runbooks and hand over
DeployOpen writes runbooks for routine operations, failover, restore, upgrade, adding a replica, and escalation, along with the evidence your compliance team needs for change and backup records. Your operators run one or more supervised procedures so the handover is tested, not assumed. The deliverable is a documentation set in your own systems and a signed handover checklist. The step is done when your staff can execute the core runbooks without DeployOpen present.
Agree ongoing support and upgrade retainers
Support, scheduled upgrades and continuous testing are offered as retainers, scoped separately after the build is complete. The retainer defines which ClickHouse release lines are covered, how often restore tests repeat, and who responds to incidents. Your team decides whether to keep the work in-house or contract it out. The output is a signed retainer scope, or a documented decision to operate without one.
How DeployOpen plans, implements and supports self-hosted ClickHouse
DeployOpen plans and implements self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks, so the layout decision is made against your infrastructure and your recovery requirements. We scope the single-node or replicated option in writing, build it, test it and document it for your operators.
How we scope
- Written scope states whether the engagement covers one server or a replicated layout with two replicas and three Keeper nodes.
- Scope records the data volume, query concurrency, availability target and restore expectations that decide between the two layouts.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We provision the chosen servers, dedicated Keeper hosts and network paths inside your environment, following your change controls.
- Replicated tables are configured with ReplicatedMergeTree and tested by stopping a replica and confirming it resyncs.
- Backup jobs with BACKUP and RESTORE are configured, and we run a restore test on a spare cluster before sign-off.
How we hand over
- Handover documentation covers topology, Keeper configuration, authentication settings and the upgrade procedure your team will follow.
- Runbooks describe how to read the changelog, test upgrades in a pre-production environment with representative data, and roll back.
- Your operators are walked through failure drills so they can act without DeployOpen on the first incident.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for clusters that need them after handover.
- A retainer can cover scheduled upgrades to supported ClickHouse lines, backup verification and periodic restore tests.
- Ask any quote to separate one-time build work from recurring retainer work, and to name who is responsible for each backup.
