ClickHouse gains full text search

This matters because OpenSearch is no longer protected by a must have feature gap in log analytics. ClickHouse now has native inverted text indexes, which makes token search on log lines and error strings much more practical inside the same system teams already use for fast aggregations, retention, and cost control. In Firebolt’s case, text search was a follow on step after narrowing by time and filters, not the center of the workflow.

• The migration logic is concrete. Teams usually start with a time window, service, customer, or error code, then inspect a smaller slice of logs. That favors ClickHouse, because its strength is scanning huge structured datasets cheaply, and text lookup only needs to work on the narrowed result set.
  1 sacra 2 sacra
• ClickHouse has moved from older Bloom filter based text techniques to native text indexes built as inverted indexes. As of March 10, 2026, full text search is generally available, with ClickHouse positioning it for observability and large scale analytics over billions of rows.
  3 clickhouse 4 clickhouse
• OpenSearch still has the more search native heritage. Its core model is Lucene style full text indexing and query DSL for match, phrase, and fuzzy search. So the easier displacement path is log analysis, where search is one step in an analytics workflow, not document search products built around relevance tuning.
  1 sacra 4 clickhouse 5 opensearch 6 opensearch

The next step is convergence. ClickHouse is turning observability into a one database workflow, where raw events, aggregates, and text search live together. That pushes OpenSearch further toward workloads where ranking, fuzzy matching, and search application features matter most, while ClickHouse keeps taking cost sensitive log and telemetry workloads.