OpenSearch or ClickHouse for logs: when each one fits
A team storing security and application logs on its own infrastructure often arrives at this choice from two directions. One group wants fast free-text lookups across every field, the way an analyst pivots from an IP address to a user to a process. Another wants to aggregate billions of rows quickly and keep storage lean. Both OpenSearch and ClickHouse are licensed under Apache-2.0, so license cost and usage terms do not separate them. The decision turns on query model, the security tooling you need on day one, the operating effort you can staff, and how your analysts will actually investigate events.
OpenSearch fits best when investigations start with unknown terms and detection content matters. Its inverted index suits free-text search across heterogeneous log sources, and the Security plugin provides role-based access, document and field-level security, field masking and audit logs without a paid tier. OpenSearch Security Analytics also matches logs against Sigma rules, so it can serve as a SIEM backend. Confirm which Security Analytics rules and log types your sources need, because the rule set is not a substitute for the detection engineering your team must still own.
ClickHouse fits best when the questions are aggregate and known in advance: error rates by service, request volumes over long windows, or large retention on modest hardware. Its columnar storage and ReplicatedMergeTree replication are designed for analytical scans, but ClickHouse does not ship security content, so you will build parsers, detections and dashboards yourself. Ask who will maintain that work, how often you will upgrade (ClickHouse publishes stable and LTS release channels), and whether a tested restore is part of your backup plan. Deciding questions: how often do analysts search for unknown strings, who owns detection content, and which team will run backups and upgrades.
Which scenarios favor OpenSearch and which favor ClickHouse
This table maps common logging scenarios to the platform that fits each one better and gives the reason in terms of supplied facts. Read each row as a starting point: the deciding factor is usually whether your team needs full-text search and detection content, or fast aggregate analytics over very large volumes of structured events.
| Scenario | Better fit | Why |
|---|---|---|
| SOC investigation with free-text search | OpenSearch | Its search engine is built for full-text queries across raw log messages, and its Security plugin adds role-based and field-level access controls for analysts. |
| Sigma-based detection | OpenSearch | Security Analytics matches ingested logs against prepackaged or custom Sigma rules and correlates findings across log types, so no separate SIEM product is needed. |
| High-volume application telemetry with aggregate dashboards | ClickHouse | ClickHouse is a columnar analytical database, which suits scans and aggregations over large structured event tables. Confirm ingest rates and query latency on your own data. |
| Team with no search operations experience | Neither without preparation | Both need cluster sizing, upgrades and backup design. ClickHouse documents backup and restore tooling that must be tested, and OpenSearch has a packaged Security plugin. Ask a vendor or partner to scope the operating work for your team. |
| Existing ClickHouse estate | ClickHouse | Your team already runs the engine, replication through ClickHouse Keeper and backup tooling, so adding log tables extends known operations. Confirm schema and retention fit first. |
| Existing OpenSearch or Elasticsearch estate | OpenSearch | Its roots in Elasticsearch 7.10 and wire compatibility support rolling upgrades and reuse of existing indices and dashboards. Confirm API compatibility for your clients. |
| Compliance-driven access control to log data | OpenSearch | The Security plugin provides SAML, OpenID Connect, LDAP and document-level security out of the box. Verify ClickHouse external authenticators and access rules against your control set. |
How OpenSearch and ClickHouse store and replicate log data
OpenSearch and ClickHouse both hold large volumes of log data, but they index, replicate and recover it in different ways. The choices below shape cluster sizing, node roles, Keeper hosts and the routine work your team takes on after go-live.
Inverted index search model
OpenSearch builds an inverted index over log fields, so free-text searches and field lookups are answered from the index structures rather than by scanning raw events. Index size, shard count and mapping choices drive memory and disk use on data nodes. Check how many shards each daily index creates and whether your field mappings are explicit, because both determine how the cluster grows and how hard it is to rebalance.
Columnar MergeTree storage
ClickHouse stores each column separately and writes data in sorted parts that background merges combine over time, using MergeTree table engines. Queries read only the columns they need, which suits aggregations over long log histories. Your team should confirm the sort key and partitioning scheme with representative queries before loading production volumes, since these are hard to change later.
Replicated tables and ClickHouse Keeper
ReplicatedMergeTree tables coordinate replicas through 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. Keeper is an extra stateful tier you must size, patch and monitor, and a failed Keeper quorum stops replicated writes, so plan these hosts as part of the cluster.
OpenSearch node roles and shard replicas
OpenSearch separates cluster manager, data, ingest and coordinating roles, and it keeps replica shards on other nodes to survive node loss. Scaling usually means adding data nodes and managing shard allocation, with replica count set per index. Confirm your node role layout, how many cluster manager nodes you will run and how index lifecycle policies move older logs to cheaper storage.
Replica recovery and backups
A recovered ClickHouse replica automatically copies missing data from a healthy replica, but replication alone does not protect against human error or corruption. ClickHouse BACKUP and RESTORE cover full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage. Backups that are never restore-tested will probably fail when you need them, so schedule restore drills on a spare cluster.
Day-two operations and upgrades
OpenSearch 3.9.0 followed 3.8.0 on a roughly eight-week minor cadence, and maintenance branches receive security fixes without new features. ClickHouse ships stable releases about monthly and LTS releases twice a year, and its production FAQ advises reading the changelog because minor backward-incompatible changes can occur. Ask each vendor, or your implementation partner, to define the upgrade test cycle your team will own.
Query model, identity, backup and SIEM features compared
This table compares the features that decide whether a log store can also support security monitoring: query model, detection content, identity, access control, audit, replication, backup and release support. Read the OpenSearch column as the documented capability and the ClickHouse column as a list of items to confirm for your version. The main takeaway is that OpenSearch ships more of the security layer, while ClickHouse expects your team to build most of it.
| Capability | OpenSearch | ClickHouse |
|---|---|---|
| Query language and full-text search | Query DSL for full-text search and aggregations, with SQL access available through plugins (confirm the plugin for your version) | SQL for analytical queries over columnar tables. Confirm which text-search index options your version offers. |
| Detection content | Security Analytics matches logs against prepackaged or custom Sigma rules and correlates findings across log types | No detection content ships with the database. Your team writes queries or sources rules from another tool. |
| SAML and OpenID Connect | SAML and OpenID Connect supported by the Security plugin | Not in its external authenticators documentation. Confirm support with ClickHouse before planning around it. |
| LDAP, Active Directory and Kerberos | LDAP, Active Directory and Kerberos backends supported by the Security plugin | LDAP directories and Kerberos supported as external authenticators |
| RBAC, document-level and field-level security | Role-based access control, document-level and field-level security, and field masking included | Role-based access control exists. Confirm row-level and column-level restrictions in its access control documentation. |
| Audit logs | Audit logs included with the Security plugin | Confirm query and login auditing options with ClickHouse for your version |
| Replication | Shard replicas configured per index. Confirm node counts and sizing in the cluster documentation. | ReplicatedMergeTree with ClickHouse Keeper. Production guidance is at least three Keeper nodes, about 4 GB RAM each. |
| Backup and restore | Snapshot-based backup to a repository. Confirm repository setup and restore testing for your cluster. | BACKUP and RESTORE with full and incremental runs to local disk, S3-compatible or Azure Blob storage. Replication alone does not protect against human error. |
| Release lines | 3.9.0 released September 29, 2026. Maintenance release 2.19.6 on July 6, 2026. | Monthly stable releases and LTS twice a year, each supported for one year. Current LTS lines include v26.8.29.10-lts and v26.3.53.4-lts. |
What Apache-2.0 means for each platform in practice
OpenSearch is released under the Apache License, Version 2.0, and the project's FAQ does not describe any paid edition of the engine. The OpenSearch Dashboards front end derives from Kibana 7.10.2, so the license covers both the search engine and the visualization layer. Governance sits with the OpenSearch Software Foundation, a Linux Foundation project, which does not oversee the technical direction of the code. For a regulated team, this means the core features you deploy are available under one permissive license without a separate paid tier unlocking them.
- Engine and dashboards: The engine and OpenSearch Dashboards are both Apache-2.0, so you can run, modify and redistribute them under the same license terms.
- No paid edition in the FAQ: The supplied FAQ describes no commercial edition, so any paid feature question is a question for a specific vendor.
- Foundation governance: Member companies sit on the board, but the foundation does not direct technical oversight, so roadmap decisions come from the project itself.
- Security features in the project: Security plugin capabilities such as SAML, OpenID Connect and audit logs are part of the open project, which is worth confirming against your required controls.
Before you commit, confirm with your chosen support provider exactly which components and versions they cover and how long each release line stays in maintenance.
ClickHouse server is open source under the Apache License 2.0, as shown by its SPDX identifier in the GitHub repository. ClickHouse Inc. is the company behind the project and separately sells ClickHouse Cloud as a managed service. Your license obligations for self-hosting therefore come from the Apache-2.0 terms, while the commercial relationship for a hosted or supported deployment is a separate contract with the vendor. Because the license is the same as OpenSearch, the decision on this axis depends on operating model and support, not on whether the code is free to run.
- Server license: ClickHouse server is Apache-2.0, so self-hosting it does not require a commercial license for the server itself.
- Managed service is separate: ClickHouse Cloud is sold by ClickHouse Inc. and is a different product from the self-hosted server.
- Release cadence: Stable releases ship roughly monthly, and LTS releases ship twice a year, so you must plan upgrades against the support window of the line you run.
- Support windows: The security policy lists specific supported versions, and all other versions are unsupported, so confirm the line you deploy is still covered.
Ask any commercial support provider which ClickHouse versions they cover, how they handle backports, and whether their contract includes the Keeper and backup components you deploy.
When teams ask whether a platform has a paid tier, they usually mean whether a feature they need is locked behind a fee. For both OpenSearch and ClickHouse, the supplied facts show Apache-2.0 licensing for the open project, so the paid question concerns vendors and services. For OpenSearch, the relevant paid party is any vendor offering hosting or support, since the FAQ describes no paid edition. For ClickHouse, the separate paid offering is ClickHouse Cloud, which is a managed service rather than a locked feature set in the self-hosted server. The license itself does not change between these models.
- Who is paid: Support providers, managed hosting vendors and integrators are paid for their work, not the license to run the code.
- One-time versus recurring: Implementation and integration are typically one-time, while support, upgrades and hosting recur.
- What drives cost: Cluster size, number of supported versions, and the depth of SLA or response commitments drive the price of support.
- What to request in a quote: Ask for the supported versions, the upgrade and backport policy, and the written scope of what the vendor will and will not cover.
Confirm with each vendor, in writing, which features they claim to support under their contract before you assume any feature is free or paid.
What drives running cost for each platform
This table breaks running cost into the components a team pays for, marks which recur and which are one-time, and names the drivers that move each one. Use it to build a like-for-like quote request, since neither platform's cost is set by its license alone.
| Cost component | OpenSearch (Apache-2.0) | ClickHouse (Apache-2.0) | What to ask for in a quote |
|---|---|---|---|
| Infrastructure and compute | Recurring. Nodes for data, ingest and cluster management, sized to indexing rate and query concurrency. Full-text indexing typically adds CPU and heap pressure at ingest. | Recurring. Fewer nodes are often needed for the same log volume because data is columnar and compressed, but this depends on query shape and retention. Confirm with a pilot on representative data. | Node count, instance types and storage per tier, with the assumptions behind each sizing figure. |
| Storage and retention | Recurring. Indexed plus stored data usually takes more disk per day of logs. Index lifecycle policies and snapshot repositories drive the long-term bill. | Recurring. Compressed columnar storage often keeps hot data smaller. Object storage tiers reduce cost for older data if the design uses them. Confirm compression ratios on your own logs. | Retention periods by log type, hot and cold tier design, and the compression assumption used. |
| Staff skills and operating effort | Recurring. Index mapping, shard sizing, lifecycle policies and dashboard work are common in-house tasks. Teams with Elasticsearch experience ramp faster. | Recurring. Schema design, table engines, partitioning and query tuning need database skills. Security analysts writing detections may need SQL-based training. | Named roles in the scope, hours per month for run work, and which tasks the vendor covers after handover. |
| Detection content and SIEM features | Recurring or one-time. Security Analytics with Sigma rules is part of OpenSearch. Building and tuning correlation and detections is ongoing analyst work either way. | Recurring or one-time. ClickHouse does not ship a SIEM detection layer, so detection logic, dashboards and case handling must be built or integrated. This is one-time build plus ongoing tuning. | Whether detection content, correlation rules and dashboards are in the fixed scope or left for the client team. |
| Support subscriptions | Optional and recurring. The project has no paid edition. Commercial support comes from third-party vendors or retainers, priced by the provider. | Optional and recurring. ClickHouse Inc. sells ClickHouse Cloud as a managed service. Self-managed support terms are set by the vendor, so confirm them directly. | Support tier, response terms, covered versions and whether patches for unsupported versions are included. |
| Upgrades and version support | Recurring. Upgrades follow a minor release about every eight weeks, and each version stays in maintenance for a set period. Plan regular upgrade windows. | Recurring. Stable releases ship roughly monthly, and LTS releases twice a year. Each release needs changelog review and a pre-production test. | Upgrade cadence covered, staging effort assumed and who runs rolling upgrades and rollback tests. |
| Backup and restore testing | Recurring. Snapshots to a repository need periodic restore tests. Cluster replication does not protect against deletion or corruption, so budget for restore drills. | One-time setup plus recurring tests. BACKUP and RESTORE cover local disk, S3-compatible and Azure Blob targets. The vendor warns that untested backups will probably fail when needed, so restore drills are a standing cost. | Backup targets, retention of backups, restore test frequency, and who performs and records the test. |
| Hardening, identity and compliance evidence | One-time build plus recurring review. Security plugin roles, audit logs and TLS are included, but configuration and evidence collection take effort. | One-time build plus recurring review. LDAP, Kerberos, X.509 and JWT authenticators are available, and access rules and evidence collection require configuration. | Hardening scope, evidence the team must produce for assessors and who maintains it after go-live. |
Moving log storage from one platform to the other
This sequence moves log retention, ingest and detection logic from one store to the other while keeping the existing platform live until the new one has been checked against real queries. The output is a cut-over with a documented rollback path and a retired legacy store.
Inventory sources, queries and retention needs
Your team lists every log source, its daily volume as measured on the current platform, the retention period each source must meet under internal policy, and every saved search, alert and dashboard that reads from the store. Security engineers and the SOC lead sign off on the list. It is done when each source has an owner, a retention requirement and a set of queries that someone can name, including full-text searches, aggregations and joins across sources.
Map fields and rebuild ingest pipelines
Platform engineers define the target schema for each log type, deciding which fields become keyword, numeric, timestamp or text values in OpenSearch, and which become typed columns with a sort key in ClickHouse. They rebuild the collectors and parsers that feed each store and test them against sample logs from every source. The step closes when parsed sample events match field for field in both stores and the team has documented every field that changed type or name.
Rewrite detections and dashboards for the new query model
Detection engineers translate each alert and dashboard into the query language of the target platform. Full-text matching in OpenSearch and SQL aggregations in ClickHouse do not map one to one, so rules that depend on tokenized text search need a different expression in a columnar store. Each rebuilt rule is tagged with the original rule ID so the team can trace coverage. The step is done when every rule in the inventory has a counterpart or a recorded decision to retire it.
Rebuild access roles and authentication
Identity and access administrators recreate the roles that govern who can query which indices or tables and which fields they can see. OpenSearch access is controlled through its Security plugin, including document and field level security, while ClickHouse access is set through its access control and its external authenticators. Confirm the exact controls with each vendor's documentation for your chosen edition. The step is complete when a test account from each role returns the same permitted results in both stores.
Run both stores in parallel
The SOC feeds live logs to the existing platform and the new store at the same time, and both sets of detections run against both feeds. Operators watch ingest lag, storage growth and query latency on each side. Any event that appears in one store but not the other is logged as a defect. The step produces a parallel run record that shows matching alert counts and any gaps, and the team agrees in writing on the window in which the parallel run must be judged successful.
Validate queries and restore a sample backup
Analysts run the agreed query set against both stores over the same time range and compare results, including counts, top values and sample events. Separately, the team runs a restore of backed-up data into a spare environment, because a backup that has never been test-restored will probably not restore properly when needed. The step closes when query results match within the tolerance the team documented and a restore test has completed successfully.
Cut over and document the rollback path
The team switches collectors, alerts and dashboards to the new store and records the time of change. Old ingest stays available for a defined rollback window that the owner sets before cut-over. Operators keep the rollback steps in the runbook with named owners. The step is done when all sources write to the new store, the rollback has been rehearsed, and the change record is filed with the security team.
Retire the legacy store and archive evidence
Once the rollback window closes, the team exports any data that must be kept under the retention policy, verifies the export, and shuts down the old store. Access keys and service accounts tied to it are revoked, and the decommissioning is recorded. The output is a closed change record, an archived copy of retained logs that can be read by the new platform or by an auditor, and an updated inventory of sources, rules and roles.
How release windows and upgrades affect long-term effort
The main long-term question is how often you must upgrade and how much of each release you can absorb. OpenSearch keeps each version in maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance, versions receive bug fixes and security patches but no new features. The current minor line is 3.9.0, released on September 29, 2026, and the 2.19 line still received a 2.19.6 maintenance release on July 6, 2026. A cluster on 2.19 will keep getting security fixes, but any capability added after that line closed (for example, new Security Analytics content) requires a move to 3.x. Plan your upgrade path around the maintenance window rather than the newest release.
ClickHouse follows a different rhythm. Stable releases ship roughly monthly, the three latest stable releases receive diagnostics and bug fix backports, and LTS releases ship twice a year with one year of support. The security policy currently lists 26.9, 26.8, 26.7 and 26.3 as supported, and everything else as unsupported, so a cluster on an older line needs an upgrade to remain patched. The production FAQ recommends stable releases for most production use, warns that minor backward-incompatible changes can occur, and advises reading the changelog before every upgrade. Because ClickHouse reaches new stable builds frequently, the LTS line is usually the more predictable choice for a log store that is hard to take offline.
Whichever engine you choose, the practical check is the same: stand up a pre-production cluster with representative log volumes and the saved queries your analysts and detection rules actually run, then upgrade it first and time the results. Confirm with each vendor which versions still receive security updates on the date you plan to go live, and budget the recurring work of tracking those dates. Record the upgrade cadence in your runbooks, since the effort is recurring and grows with the number of detection rules, dashboards and ingest pipelines you maintain.
Questions buyers ask before choosing or hiring help
Does the license choice change what I pay for OpenSearch or ClickHouse?
Both server projects are licensed under Apache-2.0, so the license itself adds no fee for either. The cost comes from the infrastructure you run, the staff time to operate it, and any managed service you buy. OpenSearch does not describe a paid edition in its FAQ, so a commercial OpenSearch cost is usually the hosting and people you choose to pay for. ClickHouse Inc. sells ClickHouse Cloud as a managed service, which is a separate purchase from the open-source server. Ask each vendor or partner to split the quote into infrastructure, licensing (if any), and recurring support, and confirm whether any feature you need sits outside the open-source distribution.
How much ongoing effort does each platform need to run?
Effort depends on the workload more than on the brand. OpenSearch clusters require attention to index lifecycle, shard sizing, heap tuning and rolling upgrades, and its minor releases arrive about every eight weeks, with each version in maintenance for at least one year. ClickHouse replicated tables depend on ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts with about 4 GB of RAM each in production. ClickHouse also ships stable releases roughly monthly, so you need a routine to read changelogs and test upgrades in a pre-production environment. Ask for the upgrade cadence, the monitoring you will run, and who owns on-call for each option.
What skills does my team need to run OpenSearch or ClickHouse?
OpenSearch suits teams that already know Elasticsearch-style query and mapping concepts, and its Security plugin covers SAML, OpenID Connect, LDAP and role-based access, which your identity engineers will need to configure. ClickHouse suits teams comfortable with SQL, columnar table design, partitioning and replication concepts. Both need Linux administration, TLS and certificate management, and capacity planning. For security analysts who expect search-first workflows and prebuilt dashboards, the learning curve may be shorter on the OpenSearch side. Assess the skills you have against the tasks in your runbook, and decide whether to train staff or bring in an implementation partner for the initial build.
Can my team migrate between OpenSearch and ClickHouse without outside help?
Moving log data between these engines is a re-platforming project, not a version upgrade. Ingestion pipelines, field mappings, dashboards, alert rules and retention policies all need to be rebuilt for the target query model. OpenSearch can read indices from Elasticsearch 6.0 through 7.10 and supports rolling upgrades from those versions, but that does not cover ClickHouse. A self-run migration is realistic for a small log set with few dashboards. For a larger estate, plan a parallel run where both stores receive the same events for a period, and confirm with each vendor how they handle the historical data you need to keep.
What does a fixed-scope quote for log platform work depend on?
A quote follows from the written scope, so DeployOpen does not publish a price list. The main drivers are the number of log sources and daily volume, the retention and archive periods you require, the authentication and access model, the number of dashboards and detections to migrate, the high availability and disaster recovery design, and the testing and documentation deliverables. Compliance-driven logging also changes the scope. Before requesting a quote, gather your data volumes, retention rules, identity provider, network zones and target hosting, and agree in writing which systems and deliverables are included.
Do I need regular restore tests for ClickHouse and OpenSearch backups?
Yes. ClickHouse documents BACKUP and RESTORE for full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage, and states that replication alone does not protect against human error or corruption. Its backup documentation warns that a backup never test-restored will probably not restore properly when needed, and recommends regular restore tests on spare clusters. The same principle applies to OpenSearch snapshots. Confirm your recovery time and recovery point objectives, schedule restore drills on a non-production cluster, and record the results as evidence for your auditors.
How do authentication options differ for ClickHouse and OpenSearch?
OpenSearch Security provides SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JSON Web Token backends, along with role-based access, document and field-level security, field masking, user impersonation and audit logs. ClickHouse supports LDAP authentication and directories, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication as external authenticators, and it uses its own access control for users and roles. Check whether your analysts need field-level restrictions on sensitive log fields, whether audit logging must meet a specific control, and whether your identity provider speaks the protocols each option supports. Confirm these details in the current documentation before you commit.
Risks to check before committing to either store
Both stores can hold security and application logs, but the risks sit in different places: the SIEM features you need, how you protect and restore data, how you run the cluster, and who on your team can operate it. Each card below names the condition under which a risk matters and what to confirm before you choose.
Unclear SIEM feature needs
A log store is not a SIEM. If your team needs prepackaged detections, correlation, case handling or threat hunting workflows, you will either build them or add a product on top. OpenSearch Security Analytics matches logs against Sigma rules and correlates findings across log types, which may cover part of that need. ClickHouse has no equivalent built in, so detection logic would sit in your own queries or a separate tool. Write down the detections and workflows your SOC needs in the first month, then confirm which of them each option covers natively.
Untested backups
Replication keeps a second copy of data but does not protect against deletion, corruption or a bad configuration change. ClickHouse BACKUP and RESTORE can write full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage, and its documentation warns that a backup never test-restored will probably not restore when needed. For OpenSearch, confirm your snapshot repository, retention and restore procedure in the same way. This risk matters most when logs are evidence for an incident or a compliance review. Schedule restore tests on a spare cluster and record the time each one takes.
Keeper sizing for ClickHouse
Replicated ClickHouse tables depend on ClickHouse Keeper for coordination. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Keeper is an extra tier to provision, patch and monitor, and it is easy to underestimate when a team plans only for data nodes. It matters if you plan replicated tables for availability. Ask your platform team who owns Keeper, how quorum loss is detected and how Keeper hosts are backed up. OpenSearch has no separate coordination tier of this kind to size, though its cluster manager nodes need their own planning.
Skills gap in search or SQL
OpenSearch teams need working knowledge of index lifecycle, shard sizing, mappings and cluster health. ClickHouse teams need table engine choices, partitioning, merges and SQL analytics. A team strong in one will be slower with the other, and the gap shows up during incidents, not during the pilot. This matters most when the people who run the store are not the people who write detections. Before committing, have the analysts run their five most common hunts on both candidates and time the hands-on work each one needs from an operator.
Upgrade drift across releases
Both projects ship on different cadences, and drift between your nodes, agents and client libraries is a common source of breakage. OpenSearch maintains each minor line until the next major enters maintenance or one year passes, whichever is longer, and maintenance releases carry fixes but no new features. ClickHouse publishes stable releases roughly monthly, with LTS releases twice a year, and its security policy lists which versions still get security updates. Confirm which line you will run, how long it is supported, and who reads the changelog before each upgrade.
Vendor-neutral support
Both engines are Apache-2.0, so no license fee applies to the server software. Support differs: OpenSearch is governed by a foundation with no role in technical oversight, while ClickHouse Inc. sells a managed cloud service alongside the open source server. Commercial support contracts for either are a separate decision. This matters when your auditors or procurement team ask who patches a vulnerability on a fixed date. Ask any implementation partner which support paths they can cover, what is in a written scope and who you call when a release breaks a pipeline.
How DeployOpen helps choose, implement or migrate log storage
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For log storage, that means working through the choice between OpenSearch and ClickHouse against your actual sources, queries, retention and team skills before any build starts.
How we scope
- Written scope lists the log sources, query patterns, retention periods and alerting use cases the store must serve.
- Scope names which parts of the OpenSearch or ClickHouse decision are being tested, such as query model, storage and identity integration.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- Deployment is built in your environment, using your identity provider, network controls and existing log shippers.
- Replication, backup and restore are configured, and restore tests run on a spare cluster before go-live.
- Security testing of the log pipeline and its access controls is planned and documented alongside the build.
How we hand over
- Documentation covers configuration, upgrade steps, access roles and the backup and restore runbook for your team.
- Compliance evidence is prepared for your auditors, which DeployOpen does not issue or certify itself.
- Handover includes a walkthrough so your operators can run queries, rotate credentials and respond to storage alerts.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning reviews release notes and maintenance windows for the platform versions you run.
- Retainer scope is agreed in writing, so you know which tasks, responses and checks are covered.
