ClickHouse or Elasticsearch: when each one fits your log and observability workload
If your logs or observability data already sit in Elasticsearch, or ClickHouse is on a shortlist that includes it, the decision turns on what you ask the data to do. Choose ClickHouse when the workload is SQL aggregation over large columnar datasets and an Apache-2.0 license matters to your procurement or legal team. ClickHouse server is Apache-2.0 licensed, and column storage favors filtering and aggregating across many rows. Choose Elasticsearch when full-text search, the Kibana ecosystem and existing Elastic tooling dominate how your engineers work. Elastic's default distribution is under the Elastic License 2.0, and SSPL and AGPLv3 are the other offered options, with ELv2 and SSPL not OSI-approved.
Four factors settle most cases. First, query shape: if analysts write SQL joins, group-bys and percentiles over long time ranges, ClickHouse fits; if engineers search free text across messages and rely on Lucene-style queries, Elasticsearch fits. Second, retention volume: check how many days you keep and how fast ingest grows, then test both engines on a representative slice. Third, licensing posture: confirm with your legal team which Elastic license option, if any, your policy allows, and which Elastic features sit in paid tiers. Fourth, team skills: run a short proof of concept with the people who will operate the cluster, because ClickHouse's SQL and Elastic's query and node-role model demand different habits.
Treat the choice as reversible but not free. ClickHouse's own migration guidance recommends running Elastic and ClickStack in parallel for observability data rather than moving historical data, and aligning ClickHouse TTL settings with your existing Elastic retention policies. Before you commit, confirm the current Elastic support dates on the Elastic product end of life dates page and review the ClickHouse migration overview for the parallel run.
Which platform fits which log and observability scenario
This table maps common logging and observability scenarios to the platform that usually fits them better, with the condition under which each advantage matters. Read each row against your own query patterns, retention targets and license requirements before deciding, since most teams have more than one of these scenarios.
| Scenario | Better fit | Why and when it matters |
|---|---|---|
| Full-text search over application logs | Elasticsearch | Its inverted index and Lucene query syntax are built for free-text search and relevance. This matters most when engineers search raw message text ad hoc across many fields. |
| SQL dashboards over high-volume event data | ClickHouse | Column storage speeds filtering and aggregation over many rows, which suits grouped counts and percentiles over large event tables. The advantage holds when queries aggregate rather than retrieve individual documents. |
| Kibana-centric teams with existing dashboards and alerts | Elasticsearch | Kibana, Elastic Agent and existing alert rules keep working without rewriting. Moving to ClickStack means translating Kibana Lucene queries to HyperDX syntax, so confirm the effort against your saved objects first. |
| Teams needing an OSI-approved license | ClickHouse | ClickHouse server is Apache-2.0. Elasticsearch's default distribution is under the Elastic License 2.0, and the AGPLv3 option is the OSI-approved path, so confirm which Elastic license and edition your procurement policy accepts. |
| Retention-driven log storage with time-based deletion | Either, depending on cost model | Elastic's TTL and tiered data nodes can match retention policies, and ClickHouse TTL settings can be aligned with the same retention windows. Test storage size and compression with your own log samples. |
| Historical data that must move between platforms | Run both in parallel | ClickHouse recommends running Elastic and ClickStack side by side for observability data rather than migrating history. Direct copying from Elasticsearch is only viable for datasets under 10 million rows, so plan retention so old data ages out. |
| Security and access controls required in the free tier | Confirm per edition | Elastic made TLS, native realms and RBAC free in the Basic tier, while SSO and field-level security are in paid tiers. ClickHouse supports LDAP, Kerberos, X.509, HTTP and JWT external authenticators, so confirm field-level controls for your data. |
How ClickHouse and Elasticsearch store and query data differently
ClickHouse stores data in columns and replicates tables through ClickHouse Keeper, while Elasticsearch stores indexed documents and divides work across node roles and data tiers. The cards below cover the parts of each design that change how you run, patch and recover the cluster.
Column storage for SQL aggregations
ClickHouse is a column-oriented SQL database for online analytical processing. Column storage speeds filtering and aggregation over many rows but makes retrieving a single row slower, so a log store that mostly answers questions like error counts by service per hour fits its layout well. Check whether your investigators depend on full-text search across free-form message fields, because that workload is where Elasticsearch's inverted index is designed to help. Test both with your own queries before choosing.
ReplicatedMergeTree and Keeper quorum
ClickHouse replicates data with ReplicatedMergeTree tables, coordinated by 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. Plan for these extra hosts when you size a cluster, and confirm the Keeper layout your team will run. A recovered replica syncs missing data from a healthy replica automatically, but replication does not protect against human error or corruption, so backups remain a separate job.
Master-eligible nodes in Elasticsearch
Elasticsearch splits work across node roles, including master-eligible, data, ingest, machine learning, transform, remote cluster client and coordinating-only. A highly available cluster needs at least three master-eligible nodes, so a small log cluster carries a minimum footprint before it stores any data. Confirm which roles each host carries, because a shared host that mixes master and heavy data work can make cluster state unstable during a busy ingest period.
Hot, warm, cold and frozen tiers
Elasticsearch data nodes can be assigned to hot, warm, cold and frozen tiers, so older indices move to cheaper hardware as they age. ClickHouse handles retention differently, using TTL settings on tables that you align with existing Elastic retention policies. When you plan the move, map each Elastic tier to a storage plan on the ClickHouse side and confirm how long your compliance and investigation needs keep data readily queryable.
Rolling upgrades and version support
ClickHouse publishes stable releases roughly monthly and LTS releases twice a year, with LTS supported for a year after release. The production FAQ advises reading the changelog before upgrading because minor backward-incompatible changes can occur. Elastic maintains each major release on its own schedule, and its EOL page lists end of maintenance dates for 8.x and 9.x lines. Build an upgrade calendar for both platforms and rehearse node-by-node upgrades in a pre-production environment.
Day-two restore and recovery work
ClickHouse BACKUP and RESTORE support full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. The backup documentation warns that a backup never test-restored will probably not restore when needed, so schedule restore tests on spare clusters. Ask your Elastic administrators how snapshots and restores run in your current cluster, then compare recovery time and staff effort with your own data volumes.
Side-by-side capabilities for logs and observability
This table compares licensing, query language, search strength, identity integration, backup and release support for ClickHouse and Elasticsearch in log and observability roles. Read each row against your own retention, query and access requirements, since the two products make different trade-offs on each. The main takeaway is that the choice turns on whether you need SQL analytics over large volumes or full-text search with Elastic's tiered feature set.
| Capability | ClickHouse | Elasticsearch |
|---|---|---|
| License | Apache-2.0 for the server, with ClickHouse Inc. separately selling ClickHouse Cloud | Elastic License 2.0 by default, with SSPL 1.0 and AGPLv3 also offered; ELv2 and SSPL are not OSI-approved |
| Query language | SQL, the column-oriented engine's native interface | Query DSL and Lucene-based query syntax; Kibana queries must be translated when migrating |
| Full-text search strength | Supports text filtering and aggregation, but confirm the search features your log queries depend on | Built as a search engine, so relevance-ranked full-text search is its core strength |
| SQL support | Native SQL for filtering, aggregation and joins across large tables | SQL is available, but the search-first query model is the primary interface |
| Identity integration | LDAP, Kerberos, SSL X.509, an HTTP authenticator and JWT as external authenticators | SAML, OpenID Connect, Kerberos and JWT single sign-on, with LDAP and Active Directory in paid tiers |
| Field-level security | Confirm role and row or column controls against the access control documentation for your version | Field- and document-level security sits in paid tiers, not the free Basic tier |
| Backup approach | BACKUP and RESTORE for full and incremental backups to local disk, S3-compatible or Azure Blob storage; replication alone does not cover human error | Confirm snapshot and restore setup against your Elastic subscription and deployment model |
| Release support windows | Stable releases roughly monthly; LTS releases twice a year, supported for one year; security updates for 26.9, 26.8, 26.7 and 26.3 | Elastic 9.x core stack maintenance ends October 15, 2027; 8.x maintenance ends January 15, 2027 |
What the Apache-2.0 and Elastic licenses allow and charge for
ClickHouse server is open source under the Apache License 2.0, so your team can run, modify and redistribute the server code inside its own infrastructure without paying a license fee for the software itself. The money moves to the people and hardware that operate it, plus any outside support or consulting you buy separately. The license covers the server code. It does not set the terms of any managed service or support contract you choose to add later.
- Software license: The Apache-2.0 identifier on the ClickHouse repository on GitHub applies to the server code, so confirm the license file in the exact release you deploy.
- Who gets paid: Hardware, staff time and any third-party support or consulting are priced separately from the license, and each one recurs unless you buy it once for a project.
- Upgrade work: Stable releases ship roughly monthly and LTS releases twice a year, with LTS supported for a year, so plan recurring upgrade windows and changelog reviews.
- Security coverage: Only the versions listed in the security policy receive security updates, so staying on an unlisted line becomes a risk your team must accept or fix.
Ask counsel to confirm how Apache-2.0 notice and attribution duties apply if you package, modify or ship a build to others.
ClickHouse Cloud is a managed service sold by ClickHouse Inc., and it is a separate purchase from the open source server. Choosing it changes who runs the operations and where the data sits, and it adds a contract with its own terms. It does not change the license on the self-hosted server you already run, so the two can be evaluated side by side on cost and control.
- Separate product: Cloud is sold by ClickHouse Inc. under its own terms, so do not assume that the Apache-2.0 license on the server covers the managed service.
- Metered billing: Compute and storage are charged according to the tier you pick, so ask for the rate structure in writing before you compare totals with your own hosting costs.
- Feature differences: The managed service may not support every engine, authentication method or system setting that your self-hosted deployment uses, so test your workload against the current documentation.
- Data residency: If residency rules matter, confirm in writing which regions, deployment models and bring-your-own-cloud options are available to you.
Request written terms covering data processing, support scope, service levels and exit or data return before you sign.
Elasticsearch and Kibana source code is available under three licenses. The default distribution has used the Elastic License 2.0 (ELv2) since 2021. Elastic states that ELv2 and SSPL 1.0 are not OSI-approved open source licenses. In September 2024, before the 8.16 release, Elastic added AGPLv3 as an OSI-approved option, so the same source can now be taken under any of the three terms.
- Default terms: ELv2 applies unless you select another license option when you obtain the distribution, so check which license your artifact carries.
- OSI status: Elastic describes AGPLv3 as the OSI-approved option it added, while ELv2 and SSPL are not OSI-approved, which matters for policies that require OSI-approved software.
- Copyleft review: AGPLv3 carries network copyleft obligations, so legal teams should review how it applies if you modify the code and offer it to users over a network.
- Licensing and tiers: The license you take and the subscription tier you buy are separate decisions, and the tier governs which features and support you receive.
Have counsel confirm which license governs the exact build you deploy and how it applies to any internal changes or hosted service you offer to others.
Elastic sells self-managed subscriptions in tiers, and the features your controls depend on determine which tier you need. Elastic's subscriptions page lists Free and open (Basic), Platinum and Enterprise tiers. It states that Platinum is no longer available to new customers, who are pointed to Elastic Cloud. Elastic moved TLS, the file and native user realms and role-based access control into the free Basic tier with Elasticsearch 6.8.0 and 7.1.0 on May 20, 2019.
- Free in Basic: TLS, file and native user realms and role-based access control were made free in the Basic tier by that 2019 change, which is the baseline for many internal deployments.
- Paid security features: Single sign-on, Active Directory and LDAP authentication, and field- and document-level security stayed in paid tiers under that announcement, so confirm current placement on the subscriptions page.
- Anomaly alerting: Alerting rules based on anomaly detection are listed only for Platinum and Enterprise, which affects detection designs that rely on them.
- Existing Platinum: If you already hold a Platinum subscription, confirm your renewal path with Elastic, because new purchases are directed to Elastic Cloud.
- Enterprise scope: The Enterprise tier is where the broader security list, including FIPS 140-3 mode, sits in the subscriptions materials, so confirm entitlements for your deployment in writing.
Map each control you must meet to a named feature and tier, and get that entitlement confirmed in writing before you design around it.
What drives the running cost of each platform
Running either platform costs more than its license line. Infrastructure, storage and retention, staff skills, support subscriptions, upgrades and restore testing each carry different payees and different recurring obligations. The cards below separate them so you can request comparable quotes for ClickHouse and Elasticsearch.
Infrastructure and node layout
ClickHouse is documented as optimized for vertical scaling, with a recommendation to start with a single shard. A replicated layout adds ClickHouse Keeper nodes, which the replication guide recommends on dedicated hosts in production, at least three of them with about 4 GB of RAM each. Elasticsearch needs at least three master-eligible nodes for a highly available cluster, and its data nodes are sized by tier. Ask each quote to price the same redundancy level, including the coordination or master nodes, not just the data nodes.
Storage and retention policy
For logs and observability data, retention drives storage cost more than any other setting. ClickHouse recommends aligning its TTL settings with existing Elastic retention policies, and Elastic's TTL should match the retention period you want. Elasticsearch's hot, warm, cold and frozen data tiers let you move older indices to cheaper storage, which you must design and fund. Ask vendors and integrators to quote storage at your actual ingest rate and retention window, with compression assumptions stated.
Staff skills and operating effort
Most of the recurring cost is people time. Elasticsearch operators need cluster, index lifecycle and node role expertise, while ClickHouse teams need SQL, MergeTree table design and replication know-how. Staff can be in-house salary, a DeployOpen implementation or retainer, or a managed service. Ask each proposal to name who performs tuning, on-call and capacity reviews, and how many hours per month that work is expected to take.
Support subscriptions and licensing tiers
Elastic's self-managed subscriptions include Free and open (Basic), Platinum and Enterprise tiers, and Platinum is no longer offered to new customers. Security features such as SAML and OpenID Connect single sign-on, attribute-based access control and field-level security sit in paid tiers, as does anomaly-detection alerting. ClickHouse server is Apache-2.0 and self-hosted use carries no license fee, but commercial support and ClickHouse Cloud are separate purchases. Ask for the exact subscription tier, the features it unlocks and whether renewal terms change.
Upgrades and release tracking
ClickHouse ships stable releases roughly monthly and LTS releases twice a year, with LTS supported for a year. Elastic maintains major lines on a fixed schedule, with end of maintenance for core 8.x set for January 15, 2027. Each upgrade needs a pre-production test with representative data and a changelog review, because minor backward-incompatible changes can occur. Ask whether the quote covers a recurring upgrade cycle, and how many upgrades fall within the contract term.
Backup and restore testing
ClickHouse BACKUP and RESTORE cover full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage. Replication alone does not protect against human error or corruption, and the documentation warns that a backup never test-restored will probably not restore when needed. Recurring restore tests on a spare cluster add storage and compute cost. Elasticsearch snapshot and restore costs depend on your repository and retention design. Ask every quote to price backup storage, scheduled restore tests and who owns the results.
When log analytics outgrow Elasticsearch
Move analytics off Elasticsearch when the questions you ask of logs have shifted from finding events to aggregating them. The clearest signal is heavy aggregation over many rows: dashboards that group error counts by service, region and build over months of data, or analysts who run ad hoc GROUP BY queries across billions of rows. ClickHouse is a column-oriented SQL database, and column storage speeds filtering and aggregation across many rows, while retrieving single rows is slower. If your daily work is mostly full-text lookup of one request ID, Elasticsearch's inverted index is the better tool. Track which query shapes dominate your slow dashboards before you decide anything. A second signal is an analyst team that already thinks in SQL and finds the Lucene query model a barrier. ClickHouse's own migration guidance maps Kibana Lucene queries to HyperDX syntax, so confirm with the vendor how much query rewriting your team would absorb.
Retention cost is the third signal and the one most often underestimated. Elastic's own migration guide tells teams to align the ClickHouse TTL with their existing Elastic retention policy, which means retention is a setting you must choose deliberately in either system. Confirm your required retention period and the data volume it implies before comparing storage bills. Also note that ClickHouse describes its optimization as vertical scaling with few shards, and recommends starting with a single shard. That design favors teams who can grow one large server before they need distribution, and it is a poor fit if your ingest already requires horizontal sharding across many nodes.
Stay on Elasticsearch when your use case is search-first, such as application search, security investigations that depend on fuzzy matching, or a team already standardized on Kibana and Elastic Agent. Staying is also correct if you need Elastic's security stack without buying a paid tier. The Basic tier made TLS, the file and native user realms and role-based access control free as of Elasticsearch 6.8.0 and 7.1.0. Single sign-on, Active Directory and LDAP authentication, and field- or document-level security remain in paid tiers, so confirm which of these your controls require before you commit to a migration.
How to move observability data without a risky bulk copy
This sequence moves observability workloads to ClickStack in parallel with Elastic, so historical data stays where it is and retention ends on its own schedule. Each step produces a check you can confirm before the next one starts.
Inventory Elastic data, agents and retention policies
Start by listing every index pattern, data stream, Kibana dashboard, saved search, alert rule and Elastic Agent or Beats deployment that feeds observability data. For each one, record the retention period set in Elastic, because ClickHouse guidance asks you to match TTL settings to existing Elastic retention policies. Assign an owner to each item. This step is done when the inventory is signed off by the teams that depend on those dashboards and alerts, and every retention period is written down.
Map Elastic concepts and data types to ClickStack
Use ClickHouse's ClickStack migration guide, which is written for teams coming from Kibana, Elastic Agent and Elasticsearch, to map equivalent concepts and data types. Your platform engineers and the observability owner should work through the mapping table together and flag any field whose type does not translate cleanly. Record each mismatch with a decision: change the source mapping, change the target schema, or accept a difference. This step is done when every field in the inventory has a documented target type or a recorded exception.
Deploy ClickStack alongside the existing Elastic stack
Stand up ClickStack in your own infrastructure next to Elastic, and point new ingestion at it while Elastic keeps receiving its current feeds. ClickHouse recommends running the two in parallel for observability data rather than migrating historical data. Engineers should confirm that the ClickHouse version chosen matches your production guidance, using a stable release for most production use and a pre-production environment with representative data. This step is done when both stacks receive live data and the target cluster passes the health checks your platform team defines.
Translate Kibana Lucene queries to HyperDX syntax
Take each saved Kibana query and alert condition, and rewrite it in HyperDX syntax using the translation guidance in the ClickStack migration documentation. Run the original and translated queries against the same time window on both stacks and compare result counts. Differences usually come from field names, time handling or wildcard behavior, so record every difference and its cause. This step is done when the translated queries return matching results for the agreed sample windows, or each remaining difference has a documented reason and an approved fix.
Migrate agents and rebuild dashboards
Move Elastic Agent and Beats configurations to ClickStack collection in stages, one source group at a time, and rebuild dashboards and alert rules in the new tool using the translated queries. Dashboards and alerts are rebuilt rather than exported, so the owner of each dashboard should review it against the original. Keep the Elastic version running until each dashboard owner signs off. This step is done when every migrated source is sending data to ClickStack and each rebuilt dashboard has a recorded owner approval.
Set TTL to match Elastic retention
Configure ClickHouse TTL settings on each table so that data expires at the retention period recorded in step one. Because ClickStack receives only new data, the retention clock starts at cutover, and Elastic indices continue to expire under their own policies. Confirm the TTL values against the inventory and check that no table keeps data longer than the agreed period. This step is done when a TTL check on each table matches the retention list, and the platform team has written the expiry dates for the Elastic indices.
Decide on historical data under 10 million rows
For any dataset Elastic must hand over, check its size first. ClickHouse's migration guide says moving data out of Elasticsearch is limited by its export capabilities, with only JSON over HTTP supported, and that direct copying is only viable for datasets under 10 million rows. Anything above that threshold should stay in Elastic until its retention ends, or be archived under a documented plan. Confirm the row count with your Elastic administrator before any export starts. This step is done when every historical dataset is either copied under the threshold with a verified row count or marked to stay in Elastic.
Retire Elastic after the retention window closes
Once the longest Elastic retention period has passed and no open alert or dashboard depends on Elastic, stop ingestion to the old cluster and shut it down on a planned date. Keep a restore-tested backup of any Elastic data your auditors or incident teams still need, and confirm that the backup was tested by restoring it to a spare environment. Note that Elastic 8.x end of maintenance is January 15, 2027 per Elastic's end-of-life page, so check the version you run before setting the retirement schedule. This step is done when Elastic is read-only or offline, the restore test is recorded, and the decommission record is signed by the platform owner.
What implementing each platform involves and where projects run long
The effort to move from Elasticsearch to ClickHouse sits mostly in the pipelines and agents that feed data in, and in the queries and dashboards that read it out. Plan that rework first. ClickHouse's migration guide for ClickStack is written for teams moving from Kibana, Elastic Agent and Elasticsearch, and it maps equivalent concepts and data types, so your team can check each field mapping against it before any ingestion changes. Agent reconfiguration, Logstash or Beats pipelines, and any custom ingest processors will need to be re-pointed and retested, because ClickHouse does not read Elastic's ingest pipelines as they are. The client's team must supply the inventory of agents, pipelines and index templates, and a named owner for each data source who can confirm field meanings and retention needs.
Query translation is the second area that runs long. Kibana Lucene queries have to be rewritten into HyperDX syntax, and the migration guide explains how to do this. Expect the most time in saved searches, alert conditions and dashboard panels that were built by hand over years, because nobody on the current team may remember why each one exists. Dashboards and alert rules are usually rebuilt by hand, not exported, so schedule them as a line item with an owner and a sign-off step rather than as a side task. Historical data is a separate decision. ClickHouse recommends running Elastic and ClickStack in parallel and aligning TTL with existing Elastic retention, and it notes that copying data out of Elasticsearch is limited to JSON over HTTP and is only viable below 10 million rows. Confirm the volume and retention requirements before anyone commits to a copy approach.
Operational work follows. For a replicated cluster, ClickHouse Keeper must be planned before the first table is created. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each, so ask your platform team whether that capacity is available. Backup needs a restore test, not only a schedule. The backup documentation notes that replication does not protect against human error or corruption, and warns that a backup never test-restored will probably not restore when needed, so plan recurring restore drills on a spare cluster and record how long they take. Identity is the last item to settle. ClickHouse supports LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT as external authenticators, while Elastic's single sign-on and field-level security sit in paid tiers, so confirm which of your current controls must carry over before the design is fixed. DeployOpen plans and implements these pieces under a written scope, but the decisions about retention, ownership and sign-off stay with your team.
Questions buyers ask before choosing ClickHouse or Elasticsearch
Is ClickHouse a drop-in replacement for Elasticsearch?
No. ClickHouse is a column-oriented SQL database, while Elasticsearch is a search engine built around inverted indexes and its own query language. Teams cannot swap one for the other by changing a connection string. Observability data, such as logs and traces, can be moved to ClickHouse through ClickStack, but the query language, agents, dashboards and data types all change. The ClickStack migration guide maps equivalent concepts and explains how to translate Kibana Lucene queries to HyperDX syntax, which is the practical starting point for estimating the rework. Plan for a rewrite of saved searches, alerts and dashboards, not a configuration change.
Does Elastic's AGPLv3 option change the license decision?
It can, but it is rarely the deciding factor on its own. ClickHouse server is Apache-2.0, which is permissive and OSI-approved. Elasticsearch source is available under the Elastic License 2.0 by default, under SSPL 1.0 and under AGPLv3. Elastic added AGPLv3 in September 2024 before the 8.16 release to offer an OSI-approved option, but ELv2 and SSPL are not OSI-approved. Legal teams should confirm which license applies to the exact distribution and version they deploy, and how AGPLv3 network-use obligations apply to their internal services. Licensing mainly matters when the company plans to offer the software to outside customers or to modify and redistribute it.
What drives the cost and effort of an Elasticsearch to ClickHouse migration?
The effort follows the surface area you own. The main drivers are the number of saved searches, alerts, dashboards and detection rules that encode Elastic query logic, the number of Elastic Agent and Beats deployments to repoint, the retention policy you need to match, and the volume of historical data you want to keep. ClickHouse's guidance is to run Elastic and ClickStack in parallel for observability data rather than migrating history, and to set Elastic's TTL to match the retention period you need. Costs are one-time for translation and cutover work and recurring for the infrastructure running two stacks during the overlap. Ask any provider for a quote that lists each artifact category, the overlap period and who validates the results.
Can our team run the migration itself?
Often yes, if the team already operates both stacks and has an engineer who knows the query languages well. The work is mostly translation, validation and agent reconfiguration, which is within reach of a platform team that understands logging pipelines. The harder parts are sizing a ClickHouse cluster, designing replication and backups, and writing the cutover plan. ClickHouse's migration guide notes that moving historical data out of Elasticsearch is limited to JSON over HTTP and that direct copying is only viable for datasets under 10 million rows, so bulk history moves need a deliberate design. Teams without spare capacity often bring in outside help for a fixed-scope piece, such as translating a defined set of dashboards and alerts.
How should we test ClickHouse with our own queries before deciding?
Test with your real query workload, not with a generic benchmark. Export a representative set of queries from your Kibana dashboards, saved searches and detection rules, translate them, and run both systems against the same data window. Compare result correctness first, then latency at your peak concurrency and the storage footprint for the retention you need. ClickHouse's production guidance recommends a pre-production environment with representative data and queries. Include failure tests: stop a replica, restore a backup to a spare cluster and confirm that alerts still fire. Record the translation effort per query family, since that number will drive the migration plan more than any vendor claim.
Which operating skills does a ClickHouse deployment need?
A self-hosted ClickHouse deployment needs skills in SQL, MergeTree table design, replication, ClickHouse Keeper and backup operations. ClickHouse replicates data with ReplicatedMergeTree tables coordinated by ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production. Backups use BACKUP and RESTORE, which replication alone does not replace, and the documentation warns that a backup never test-restored will probably not restore when needed. Upgrades need a pre-production check, because minor backward-incompatible changes can occur. Elasticsearch teams will need to learn these habits, while keeping the Elastic node roles, master-eligible quorum and ILM-style lifecycle skills they already use.
What does a fixed-scope DeployOpen engagement need from us?
A fixed-scope engagement needs a written statement of the outcome before work starts. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted platforms in your own infrastructure, and most engagements are scoped with agreed deliverables and timelines. To scope a ClickHouse or Elastic migration, we would need an inventory of data sources and agents, the saved searches, dashboards and alerts in scope, the retention and compliance requirements, the target hosting environment and named owners on your side. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen does not issue audit reports or certifications, so any compliance evidence still comes from independent auditors.
How long does a migration take?
The honest answer depends on the number of artifacts to translate, the retention period you must match and how much historical data you need. No duration is set by a supplied fact, so no figure is given here. Ask any provider for a timeline tied to a written scope, and check whether it covers the parallel-run period, validation of query results, agent cutover and the time needed to match Elastic TTL settings. Also ask how the timeline changes if you choose to migrate historical data or keep Elastic for a defined retirement window. Elastic's support windows for the Elasticsearch release lines, such as the end of maintenance for 8.x on January 15, 2027, can also shape the timing and should be confirmed against the Elastic end-of-life page.
How DeployOpen helps you choose and implement either platform
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a ClickHouse vs Elasticsearch decision, that can mean a written comparison of your log volumes, retention rules and query patterns, followed by a fixed-scope build of whichever platform fits, or a side-by-side run of both during a migration. DeployOpen does not favor either platform. Its recommendation should follow from your workload, your team's skills and your licensing requirements, and it should be willing to conclude that the platform you already run is the right answer.
Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. A useful scope for this decision names the components in play: for ClickHouse, the ClickHouse Keeper nodes if you run a replicated cluster, the TTL settings that match your Elastic retention policy, the backup schedule and the restore tests. For Elasticsearch, it names node roles, the number of master-eligible nodes, the security features in your subscription tier and the Elastic version you will stay on. Ask DeployOpen to state which of these are in and out of scope. DeployOpen does not issue audit reports, attestations or certifications. If you need evidence for an assessment, the scope can cover preparing the systems, controls and records, while the independent auditor or certification body issues the outcome.
A quote follows from the written scope, and DeployOpen does not publish a price list. When you request one, ask for the line items: discovery and comparison, environment build, data migration or parallel run, integrations with your agents and dashboards, hardening, backup and restore testing, documentation and handover. Separate one-time work from any recurring retainer for upgrades, support and continuous testing. Ask the vendor-side questions yourself too, such as which Elastic tier you need for single sign-on and field-level security, since licensing conditions are yours to confirm with Elastic and not something a quote can settle for you.
