When self-hosted ClickHouse or ClickHouse Cloud fits your team
Choose ClickHouse Cloud when your team wants replication, scaling and high availability handled by the vendor and does not need to own the server configuration. Choose self-hosted ClickHouse (the Apache-2.0 server) when you need control over configuration, authentication, data location and upgrade timing, and you have staff who can run replicas, coordination and backups. The core trade is managed operations against control. Cloud runs on SharedMergeTree, which replaces ReplicatedMergeTree and keeps data in shared object storage, so replication and scaling are not your job. Self-hosting means you choose the engines, coordinate replicas through ClickHouse Keeper, and build your own backup and restore routine.
Authentication and settings are the first thing to check against your policy. ClickHouse Cloud does not support LDAP, Kerberos, X.509 certificate or HTTP external authentication, and most system settings are not configurable there. If your identity model depends on any of these, or on the PostgreSQL wire protocol, JDBC or ODBC, self-hosting or a different hosting path is needed. Confirm the full list in the ClickHouse cloud compatibility documentation before you commit. Self-hosting also means you own the backup discipline: replication does not protect against human error or corruption, and the backup documentation advises regular restore tests on spare clusters.
If the requirement is data residency rather than operations, treat Bring Your Own Cloud as a third path. It runs ClickHouse Cloud inside your own VPC and is sold by custom quote, so it is a commercial conversation, not a self-service plan. Ask ClickHouse Inc. what it manages, which controls stay with you, and what the quote covers. Whichever path you choose, put the decision in writing with the workload, the identity requirements and the staff available to run it.
How the two models differ on control, features and cost
This table compares ClickHouse Cloud and self-hosted open source ClickHouse on license, pricing meters, engine family, authentication, feature limits, release support, and backup ownership. Read each row as the question to settle with your team before choosing, since the right answer depends on your data residency rules, staffing and workload.
| Factor | ClickHouse Cloud (ClickHouse Inc.) | Self-hosted open source ClickHouse |
|---|---|---|
| License and seller | ClickHouse Inc. sells Cloud as a managed service. The server itself is open source under Apache-2.0, so you buy operation, not the software. | Server is Apache-2.0 licensed and free to download. You run it on your own servers or cloud accounts and pay your own infrastructure and staff. |
| Pricing meters | Compute and storage are metered separately by tier. Published N. Virginia rates include storage at 25.30 US dollars per TB per month and compute by unit per hour, and idle services can scale to zero. | No ClickHouse license fee. Costs are your hardware or cloud resources, Keeper nodes, backup storage, monitoring, and the engineering time to run them. |
| Engine family | SharedMergeTree is used by default. MergeTree and Replicated engines are substituted with Shared engines, with data in shared object storage. | MergeTree tables, with ReplicatedMergeTree tables coordinated by ClickHouse Keeper when you need replicas. You configure and size replication yourself. |
| Authentication methods | LDAP, Kerberos, HTTP external and X.509 certificate authentication are listed as unsupported. Confirm which identity options your Cloud tier offers. | LDAP, Kerberos, SSL X.509, HTTP authenticator and JWT are documented as external authenticators. You configure and maintain them. |
| Table engines and integrations | PostgreSQL wire protocol, MaterializedPostgreSQL, MySQL database engine, HDFS, Hive, JDBC, ODBC, SQLite and Log-family engines are listed as unsupported. | Engine and integration availability depends on the server build and configuration you deploy. Test each connector you need in a pre-production environment. |
| System settings and experimental features | Experimental features are disabled and most system settings are not configurable. ClickHouse manages replication, scaling and high availability. | You control server configuration, including settings and Keeper and storage tier layout, and you carry the tuning and testing work that comes with them. |
| Release lines and support | ClickHouse operates the upgrade path. Confirm with the vendor how upgrades are scheduled, and whether scheduled upgrades are included in your tier. | Stable releases ship roughly monthly and LTS releases twice a year, with LTS supported for a year. Security support covers listed versions only, so you plan and run upgrades. |
| Backup and recovery responsibility | Confirm in writing which backup, restore and retention actions ClickHouse performs and which you must request or test. | You own BACKUP and RESTORE jobs, backup storage and restore tests. Replication alone does not protect against human error or corruption. |
Where your data lives and what compliance requires
Your choice of deployment model decides where ClickHouse data sits, who operates the platform and which authentication methods you can use. The cards below cover those decisions in the order a compliance review usually reaches them, with the checks to run before you sign.
Data location under Cloud
ClickHouse Cloud runs on the SharedMergeTree engine family, which keeps data and metadata in shared object storage and coordinates replicas through ClickHouse Keeper, so compute and storage scale separately. Your tables live in the storage that ClickHouse Inc. operates for your service. Ask the vendor which regions and providers are available for your tier, where backups are kept, and who inside ClickHouse Inc. can reach the storage layer.
Bring Your Own Cloud inside your VPC
Bring Your Own Cloud runs ClickHouse Cloud inside your own virtual private cloud, which is the option to examine when a residency rule requires that data never leave your account boundary. It is offered by custom quote, so the scope of who operates the environment, how keys are held and what your cloud account must allow should appear in the written proposal. Confirm those details with the vendor before you assume the residency position.
Self-hosting in your own environment
Open source ClickHouse under Apache-2.0 runs on your servers, data centers or air-gapped networks, which keeps storage location and key management entirely under your control. The trade-off is that your team owns replication, backups, patching and access design. Document where each replica sits, how the Keeper quorum is isolated and which team answers for each control.
Authentication Cloud does not support
ClickHouse Cloud does not support LDAP, Kerberos, HTTP external or X.509 certificate authentication, so a directory-based or certificate-based login model that works on self-hosted servers may not carry over. Map every user population and service account before choosing Cloud, and confirm which identity methods the Cloud service offers in your tier. Self-hosted servers support these methods through external authenticators, which is a reason some teams keep control in-house.
Access control and role design
Access rights in ClickHouse are granted through SQL users, roles and privileges, and the same model applies whether you run Cloud or self-hosted servers. Review which roles can read raw tables, who can alter settings and whether service accounts are separated from people. Experimental features are disabled in Cloud and most system settings are not configurable, so write down which controls you expect to set yourself.
Enterprise tier controls and compliance scope
The Enterprise tier on the pricing page adds SAML SSO, private regions, CMEK, scheduled upgrades, a named lead support engineer and HIPAA and PCI compliance. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue audit reports, attestations or certifications. Confirm with ClickHouse Inc. which compliance programs cover your tier and region, and agree the audit scope with your own auditor before relying on any of them.
How SharedMergeTree changes what you operate
The core difference is where replication lives. ClickHouse Cloud runs on SharedMergeTree, which the ClickHouse docs describe as a cloud-native replacement for ReplicatedMergeTree. Data and metadata sit in shared object storage and are coordinated through ClickHouse Keeper, so replicas do not communicate with each other. Cloud substitutes Shared engines for MergeTree and Replicated engines automatically, and compute and storage scale independently. You do not choose the replication topology, and you do not run the Keeper quorum yourself.
Self-hosted ClickHouse works differently. Replicated tables use ReplicatedMergeTree and depend on ClickHouse Keeper, which replaces ZooKeeper. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Your team owns those hosts, their patching, their monitoring and the decision about how many replicas and shards to run. A recovered replica syncs missing data from a healthy replica without manual intervention, but the same guide and the backup documentation both make clear that replication does not protect against human error or corruption. Backups with BACKUP and RESTORE stay your responsibility, and the backup documentation advises regular restore tests on spare clusters.
Before assuming a workload ports cleanly, check engine usage and configuration. Any table that names MergeTree or Replicated engines explicitly, along with self-managed Keeper settings, storage tier configuration and experimental features, needs a review because Cloud disables experimental features and does not expose most system settings. Confirm the current list of supported engines and integrations in the ClickHouse cloud compatibility documentation, and ask ClickHouse Inc. to confirm how your specific table definitions and replication assumptions map to Cloud before migrating.
What your team runs in each model
This table lists the operating tasks that come with ClickHouse, shows who handles each one in ClickHouse Cloud and who handles it when you self-host. Read each row as a question to answer for your own team: if a task lands on your staff, confirm that you have an owner, a runbook and a restore test before go-live.
| Operating task | ClickHouse Cloud | Self-hosted ClickHouse |
|---|---|---|
| Replication and failover | ClickHouse Inc. runs replication and high availability by default on the SharedMergeTree engine family, with compute and storage scaling independently. | Your team runs ReplicatedMergeTree tables with a ClickHouse Keeper quorum, which the replication guide recommends at three or more nodes on dedicated hosts in production. Recovered replicas resync automatically from a healthy replica. |
| Scaling | Scaling is handled through the service tier and compute settings, and idle services can scale to zero on the pricing page. Confirm which scaling options your tier includes. | Your team sizes hosts, adds shards and replicas, and plans data movement. Sizing depends on your workload, so test with representative data and queries. |
| Version upgrades | ClickHouse Inc. performs upgrades. Enterprise tier lists scheduled upgrades, so confirm timing and notice terms in writing. | Your team chooses a stable or LTS line, tests in a pre-production environment, reads the changelog for backward-incompatible changes and applies the upgrade. Stable releases ship roughly monthly, and LTS releases twice a year with one year of support. |
| Supported version tracking | ClickHouse Inc. keeps the service on supported versions. Confirm the current version policy with the vendor. | Your team must track the security policy list. Versions 26.9, 26.8, 26.7 and 26.3 are listed as supported with security updates, and all other versions are unsupported. |
| Backups and restore | Backup configuration and retention are service features. Confirm backup scope, retention and restore procedures with ClickHouse Inc. | Your team runs BACKUP and RESTORE to local disk, S3-compatible storage or Azure Blob Storage. Replication does not protect against human error or corruption, and the documentation recommends regular restore tests on spare clusters. |
| System settings and experimental features | Experimental features are disabled and most system settings are not configurable. Confirm which settings your workload needs before choosing Cloud. | Your team sets server configuration, enables or disables experimental features after testing, and documents each change for upgrades and audits. |
| Authentication integration | LDAP, Kerberos, HTTP external and X.509 certificate authentication are listed as unsupported. Confirm the supported identity options for your directory. | Your team configures LDAP, Kerberos, SSL X.509, HTTP or JWT external authenticators and maintains them through upgrades. |
| Monitoring and alerting | Confirm with ClickHouse Inc. which service metrics, logs and alerts are exposed to your team. | Your team selects and runs monitoring for replicas, Keeper nodes, disk, merges and backups, and owns alert response. |
What each model costs and what drives the bill up
ClickHouse Cloud is billed by ClickHouse Inc. as a managed service, and the bill is built from two meters that scale independently. Storage and compute are priced separately, so a service with large retained history but light query traffic costs differently from one with small data and heavy concurrent queries. The published pricing page states that idle services scale to zero, which lowers compute charges during quiet periods but does not change what you store. In the N. Virginia (us-east-1) region, the pricing page lists storage at 25.30 US dollars per TB per month and compute at 0.2181 (Basic), 0.2985 (Scale) or 0.3903 (Enterprise) US dollars per unit per hour, according to the ClickHouse pricing page. Tier limits also shape cost: Basic caps storage at 1 TB with one availability zone, Scale adds unlimited storage, compute-compute separation, two or more availability zones and private networking, and Enterprise adds SAML SSO, private regions, customer-managed keys, scheduled upgrades and HIPAA and PCI compliance.
- Metered compute: Compute units are billed per hour, so the number of units you run and how long they stay active drive most of the compute line.
- Metered storage: Storage is billed per TB per month and recurs for as long as data is retained, including backups you keep in the service.
- Tier step-ups: Moving from Basic to Scale or Enterprise changes the unit rate and unlocks features that many regulated buyers treat as requirements.
- Trial and credits: The pricing page lists a 30-day trial with 300 dollars of credits, which covers evaluation but not a production run rate.
- Bring Your Own Cloud: A custom quote covers deployment inside your own VPC for residency needs, so cost follows that negotiated scope rather than the published meters.
Before signing, confirm the region, tier, unit count assumptions and retention period with ClickHouse Inc. and ask for a worked estimate based on your own data volume and query pattern.
The ClickHouse server is open source under the Apache License 2.0, so there is no license fee for the software itself. The money goes to the infrastructure that runs it, the people who operate it, and any outside support you buy. A production layout that uses ReplicatedMergeTree tables needs servers for replicas and at least three ClickHouse Keeper nodes, which the replication guide recommends on dedicated hosts with about 4 GB of RAM each. Backup storage is a separate line, because the BACKUP and RESTORE commands write to local disk, S3-compatible storage or Azure Blob Storage, and replication alone does not protect against human error or corruption. Most of the recurring cost is staff time for upgrades, monitoring, capacity planning and restore testing, which is hard to price without knowing your team's current skills and on-call model.
- Software: The Apache-2.0 server carries no license charge, so the cost lines are hardware or cloud instances, storage and network.
- Keeper nodes: Three or more coordination nodes add machines that must stay healthy, patched and monitored.
- Backup storage: Storage for full and incremental backups grows with retained history and needs its own retention policy.
- Staff time: Upgrades follow a monthly stable cadence or a twice-yearly LTS cadence, and each upgrade needs a pre-production test and changelog review.
- Support: Vendor or partner support is optional, but it is a recurring commitment you must price if you want a defined response path.
Ask your internal platform team to estimate hours per month for upgrades, backups and incident response, and compare that figure with the Cloud line items before deciding.
One-time costs cover the work that happens before the platform carries production load. For self-hosted ClickHouse, this includes sizing the cluster, designing the replica and shard layout, hardening the server, configuring authentication, setting up backup jobs and proving that a restore works. For ClickHouse Cloud, the one-time work is smaller on the platform side but still includes data migration, schema translation and network design, especially where Cloud's unsupported features affect existing pipelines. The backup documentation warns that a backup never test-restored will probably not restore when needed, so restore testing belongs in the first project phase, not after go-live. Neither model removes the initial effort of moving data and rewriting queries, and both depend on how much of your current stack relies on features outside the managed service.
- Architecture design: Choosing shard count, replica count and Keeper placement determines both the hardware line and the operating effort that follows.
- Hardening and access: Self-hosted teams configure authentication, network controls and system settings themselves, while Cloud fixes many of these choices in the managed service.
- Migration and compatibility: Cloud does not support several authentication methods, table engines and protocols, so pipelines using them need rework before migration.
- Restore proof: A first restore test on a spare cluster is a one-time task that validates the backup design for every later month.
- Documentation and runbooks: Upgrade, failover and restore procedures are written once and then maintained as the platform changes.
Ask any provider to separate migration and design fees from recurring charges so you can see which costs repeat.
Recurring costs decide the long-term comparison. In ClickHouse Cloud, compute units billed by the hour and storage billed per TB per month recur for as long as the service runs and data is retained, and both rise with query concurrency, availability zone count and retention length. In self-hosted ClickHouse, recurring costs are the infrastructure bill, staff time for operations and any support contract, and they rise with cluster size, the number of environments you keep for testing and the frequency of upgrades. The ClickHouse production FAQ recommends a pre-production environment with representative data and queries, which doubles part of the infrastructure line if you want that environment always on. Neither model has a fixed monthly figure that applies to every team, so the comparison depends on your data volume, growth rate and the people you already employ.
- Compute and hardware: Cloud compute units or self-hosted server instances set the largest recurring line for query-heavy workloads.
- Storage growth: Retained data grows the storage bill in both models, and backups add to it when kept on separate storage.
- Environments: A staging cluster with representative data is a recurring cost in either model if you run it continuously.
- Upgrade cadence: Monthly stable releases and twice-yearly LTS releases each carry a test and change-review cycle that repeats.
- Support and retainers: Vendor tiers and partner retainers recur and should be compared against the response times you need.
When comparing quotes, ask for the recurring total at your expected data growth over the contract term, not only the first-month figure.
A written quote makes the two models comparable only if every line is defined. For ClickHouse Cloud, ask ClickHouse Inc. or a reseller to state the region, tier, unit count, storage volume, retention period, availability zone count and whether idle scale-to-zero is assumed in the estimate. For self-hosted ClickHouse, ask an implementation partner to state the server sizing, Keeper node count, backup target and retention, the upgrade and restore testing scope, monitoring and on-call assumptions, and the support response commitments in writing. DeployOpen works from a written scope and quotes follow from that scope, so the fixed-scope agreement should list deliverables, timelines and exclusions before work starts. Compare both quotes over the same period and the same data growth so differences reflect architecture, not assumptions.
- Assumptions: Require the data volume, query concurrency and growth rate used in every estimate.
- Exclusions: Confirm which items are out of scope, such as migration of specific pipelines or features Cloud does not support.
- Recurring versus one-time: Ask each provider to label every line so you can separate fixed setup charges from monthly charges.
- Support terms: Get the response levels, named contacts and escalation path in writing, not only in marketing pages.
- Exit costs: Ask what it costs to export data and move workloads if you leave, since that cost belongs in the total.
Check that both quotes use the same region, retention period and growth assumption before comparing totals.
How to move between self-hosted and ClickHouse Cloud
This sequence gives you a tested path for moving ClickHouse workloads in either direction, with the engine, authentication and backup gaps found before any production traffic moves.
Inventory engines, settings and authentication
Your platform or database team lists every database, table engine, user, authentication method, external integration and non-default system setting on the current cluster. Compare that list line by line against ClickHouse's cloud compatibility documentation. Flag MergeTree and ReplicatedMergeTree tables that will be substituted with Shared engines, LDAP, Kerberos, X.509 or other authenticators that Cloud does not support, unsupported table engines such as the MySQL database engine or Log-family tables, and any settings you tune that Cloud does not expose. The output is a signed-off gap register that names an owner and a fix for each item.
Resolve engine and authentication changes
Your database engineers and identity team decide how each flagged item will work on the destination. Engine changes usually mean moving tables to the engine family the destination runs and checking that query behavior still matches. Authentication changes may mean replacing directory-based or certificate-based logins with the methods the destination supports, and updating every application connection string and service account. Confirm each choice with ClickHouse, in writing, before building anything, because the supported set and the transfer path depend on the destination and your deployment model. Done means every register item has a supported replacement or a documented accepted risk.
Test queries and access on a pre-production environment
Build a pre-production environment on the destination platform and load representative data, not a small sample, so that query plans and table sizes are realistic. Your application and analytics teams run the critical queries, dashboards and ingestion jobs against it, and the security team tests every user role and each authentication path. Record query results, latency and error rates against the current production system. For self-hosted sources, also check the version you are moving to against the ClickHouse release lines and the production FAQ's advice to read the changelog before upgrading. Done means every critical query returns matching results and every access path has been tested.
Plan the data transfer and backups
Your platform team writes the transfer runbook, covering how data moves, in what order tables load, how writes are paused or replayed during the cutover window, and who approves each stage. Take a full backup of the source before the first transfer. ClickHouse BACKUP and RESTORE support full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage, so confirm which of those targets your transfer path can use. Ask ClickHouse to confirm the supported transfer path for your source and destination before you commit to a method. Done means the runbook is approved and the backup has been written to a location separate from the source.
Test the restore on a spare cluster
Restore the backup to a spare cluster that matches the destination and check row counts, partition coverage, schema, users and grants, and a sample of business queries against the source. ClickHouse's backup documentation warns that a backup never test-restored will probably not restore properly when needed, and recommends regular restore tests on spare clusters. Time the restore so the cutover plan reflects real figures rather than estimates. Done means the restored data matches the source on agreed checks, and the restore time is recorded in the runbook.
Cut over and verify live traffic
Your platform team pauses writes according to the runbook, runs the final incremental transfer, repoints application connections and service accounts to the destination, and resumes ingestion. Watch query errors, authentication failures, ingestion lag and dashboard results during the first working period, with a documented rollback path to the source until you have accepted the new environment. Done means applications and ingestion run on the destination, the agreed checks pass on live data, and the rollback window has closed by a recorded decision.
Confirm backups and upgrade process afterward
After cutover, the operations owner confirms the new environment's backup schedule, retention, storage location and restore test cadence, because replication alone does not protect against human error or corruption. For self-hosted environments, also set the upgrade process: which release line you run, how you test upgrades in pre-production, and who reads the changelog. For Cloud, confirm how upgrades are scheduled and which upgrade controls your plan includes. Done means a written operations record names owners and dates for backups, restore tests and upgrades, and the first scheduled restore test is booked.
Questions buyers ask before choosing a hosting model
Is self-hosting ClickHouse cheaper than ClickHouse Cloud?
It depends on what you count. Open-source ClickHouse carries no license fee, so the cost of self-hosting is the infrastructure you pay for plus the people who run it. ClickHouse Cloud bills compute and storage separately, and the ClickHouse pricing page lists storage at 25.30 US dollars per TB per month in N. Virginia (us-east-1), with compute at 0.2181, 0.2985 or 0.3903 US dollars per unit per hour depending on tier. Self-hosting costs recur in servers or cloud instances, storage, backup targets, Keeper nodes and engineering time for upgrades and restore tests. Ask your team to model both sides against the same data volume, query concurrency and availability target, and include the hours your engineers spend on patching and on-call.
How much operating work does self-hosted ClickHouse need?
The work falls into four areas: replication and coordination, upgrades, backup and restore, and capacity. Production replication uses ReplicatedMergeTree tables coordinated by ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts with about 4 GB of RAM each. A recovered replica syncs missing data from a healthy one without manual steps, but replication does not protect against human error or corruption. ClickHouse publishes stable releases roughly monthly and LTS releases twice a year, with LTS supported for a year, so you need a planned upgrade cadence. Confirm internally whether your team has the skills to run these areas without an outside partner.
Can our team run self-hosted ClickHouse alone?
A team can run it alone if it already operates Linux clusters, monitors stateful services, and has an owner for database upgrades and disaster recovery. Check three things before committing. First, can someone other than the database admin perform a restore? The backup documentation warns that a backup never test-restored will probably not restore properly when needed. Second, is there a pre-production environment with representative data and queries for testing each upgrade, and is someone reading the changelog for minor backward-incompatible changes? Third, who is on call? If any answer is no, buy help for the setup and a restore test before you go live, and keep the operating model in writing.
What do ClickHouse Cloud's Basic, Scale and Enterprise tiers add?
Each tier adds operational and governance features rather than changing the database engine. Basic is limited to 1 TB of storage, 8 to 12 GiB of memory and one availability zone. Scale adds unlimited storage, compute-compute separation, two or more availability zones, private networking and 24x7 one-hour Severity 1 response. Enterprise adds SAML SSO, private regions, customer-managed encryption keys (CMEK), scheduled upgrades, a named lead support engineer, and HIPAA and PCI compliance. When you request a quote, ask which tier covers your required availability zones, key management and compliance scope, and whether the support response times are written into the contract.
Does Bring Your Own Cloud meet our data residency rules?
Bring Your Own Cloud runs ClickHouse Cloud inside your own VPC, which is the option ClickHouse describes for strict data residency and compliance requirements. It is offered by custom quote, so pricing and the exact deployment terms come from ClickHouse Inc. Whether it satisfies your rules depends on where your data may sit, who may administer the environment, and which controls your auditor expects to see. Ask the vendor in writing which regions, which operators and which encryption key controls apply. Self-hosting in your own accounts or data centers is the other route, and it keeps all administration inside your existing controls. An independent assessor decides whether the design meets the rule, so involve your compliance lead early.
Which authentication methods do we lose by moving to Cloud?
ClickHouse Cloud does not support LDAP, Kerberos, HTTP external or X.509 certificate authentication. It also does not support the PostgreSQL wire protocol, MaterializedPostgreSQL, the MySQL database engine, HDFS, Hive, JDBC, ODBC, SQLite or Log-family table engines. Self-hosted ClickHouse supports LDAP directories, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication as external authenticators. Before choosing Cloud, list every client, service account and BI tool that depends on these methods, and confirm with ClickHouse which replacement is available for each. Check the cloud compatibility documentation for the current list, since support changes over time.
How long does a migration take, and what does it depend on?
No duration can be given without your workload, so treat any single figure with caution. The main drivers are data volume, the number of tables and materialized views, how many clients rely on unsupported features or authentication methods, and whether you must keep ingestion running during cutover. Migrating to Cloud also means checking that engines and system settings you use are supported, since experimental features are disabled and most system settings are not configurable. Moving between self-hosted layouts depends on backup and restore speed, which you should measure on a spare cluster. Ask any partner for a written plan that lists these dependencies and the test steps for each.
When is outside help worth buying for ClickHouse?
Outside help is worth buying when a skill gap or a compliance deadline would otherwise leave a single point of failure. Typical cases are a first production cluster, an initial restore test, a migration from another database, or a residency design that must be documented for an assessment. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish prices, so ask for a quote based on a written scope that names the environment, data volume, clients and the restore test you expect.
When outside help changes the decision
Outside help matters most when no one on your team can operate ClickHouse in production. Self-hosting puts replication, ClickHouse Keeper quorum sizing, upgrades and restores on your staff. ClickHouse Cloud absorbs much of that work by default, since it runs on SharedMergeTree and handles replication, scaling and high availability for you. If your team already knows how to run a Keeper ensemble, track the stable and LTS support windows and test restores, self-hosting is a realistic internal skill to keep. If it does not, a partner can take on those duties under a written scope, but the ongoing ownership still sits with you and should be assigned explicitly. Residency rules are the most common reason a team moves away from the managed service. When data must stay inside your own accounts or networks, the choice narrows to self-hosting or ClickHouse's Bring Your Own Cloud option, which is offered by custom quote. Confirm with ClickHouse which deployment models they will support for your regulator and your cloud, and ask what evidence they provide for the controls you must show. DeployOpen implements, hardens and documents self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks, so a residency requirement is a reason to scope that work early, not a reason to assume it is cheap.
Backup restore testing and upgrade planning are where self-hosted teams most often fall short. ClickHouse's backup documentation states that replication does not protect against human error or corruption, and that a backup never test-restored will probably not restore properly when needed. Ask who will run restores on a spare cluster, how often, and who signs off on the result. For upgrades, the production guidance recommends a pre-production environment with representative data and queries, plus reading the changelog, because minor backward-incompatible changes can occur. Check the current supported-version list in the security policy before choosing a line. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, and offers retainers for ongoing support, upgrades and continuous testing. We do not publish a price list, so ask for a quote built from a written scope that names the environments, the backup and restore tests, the upgrade cadence and the handover to your own staff. Compare that quote with the Cloud pricing you would pay, including the recurring operations work it replaces.
How DeployOpen works on this
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For ClickHouse, that means starting from your residency, replication and recovery requirements, then deciding with you whether a self-managed cluster inside your environment fits better than a managed service.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope names the ClickHouse version line, the tables and engines in use, and the query and ingestion sources.
- We record which external authentication methods, system settings and data residency rules your environment needs to meet.
How we build
- We deploy ClickHouse with ReplicatedMergeTree tables and a ClickHouse Keeper quorum sized to your replication design.
- We configure authentication, access control and network boundaries in your own infrastructure rather than through a vendor console.
- We test failover, replica recovery and restores in a pre-production environment with representative data and queries before go-live.
How we hand over
- You receive documentation covering topology, upgrade steps, configuration decisions and the backup and restore procedure.
- We run a timed restore test on a spare cluster and record the results, since untested backups often fail when needed.
- Runbooks state who owns each task after handover, including Keeper maintenance, backup schedules and version upgrades.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Upgrade work follows the changelog review and pre-production validation steps that ClickHouse recommends for each release.
- Ask us to confirm support windows, patch cadence and escalation terms in writing before you choose a retainer.
