"Real-time" is one of the most overloaded terms in the data industry. To a trading desk, it means microsecond order matching, to a team building a user-facing app, a sub-second page load, to a finance analyst "fresh by this morning.” Different workloads, all valid.

In analytics, "real-time" usually means the user experience itself feels live. A customer refreshes a dashboard, opens a leaderboard, or investigates an issue and expects the data to reflect what just happened. Technically, this means not just delivering low-latency analytical queries but achieving this while data is being continuously inserted at high volume. 

> **Real-time analytics is not just delivering fast queries, but delivering fast queries over continuously changing data.**

In this blog, we are going to walk you through why this form of real-time analytics matters more than ever now, and how you can parse the problem by looking at both data availability and query latency. You’ll also come away with a practical set of questions to ask when evaluating whether a database can actually support real-time analytics workloads.

## Why real-time analytics matters now

Analytics has undergone dramatic changes over the years, but a paradigm shift is now driven by three factors that are breaking down the previous batch-based models.

First, analytics is moving into the product. The dashboards that used to be exclusively internal are increasingly being exposed directly to customers: [usage explorers](https://clickhouse.com/blog/how-gitlab-uses-clickhouse-to-scale-analytical-workloads) in SaaS products, performance views for advertisers, trading and risk views for end users. Every application has become data-driven, and as a result, analytics latency has become non-negotiable. Real-time analytics has become a part of the user experience. 

Second, an agent generating a customer summary, [scoring an investigation](https://www.harvey.ai/blog/building-an-agentic-security-operations-center), or routing a [support ticket](https://clickhouse.com/blog/mintlify) is only as good as the data it can see, and only as fast as it can query that data. Latency can become the real bottleneck. But freshness is only half the problem. Agents don't query the way humans do: agents can fire off 100x or more the number of queries in rapid succession, and multiply that by hundreds of agents running concurrently, each burning tokens while they wait. Most analytical engines were never built for workloads this bursty and unpredictable. Getting the data layer right isn't a footnote to agent development; it's a prerequisite. 

Third, [more automated decisions](https://clickhouse.com/blog/mintlify) are based on live data. Pricing, personalization, [fraud prevention](https://tech.instacart.com/real-time-fraud-detection-with-yoda-and-clickhouse-bd08e9dbe3f4?gi=aab23e4a7857), observability alerts, and ad targeting. These are no longer reports that a human reads later, but decisions made inside a request, where end-to-end latency directly affects the quality and usefulness of the decision itself.

The demand is clear. As we parse the challenge here, "latency" is often mistaken as query latency only, when in reality it is actually a much broader system property, including how fast your data arrives, and when it becomes ready for querying.  

## Real-time analytics is a system property, not an engine feature

When customers evaluate a real-time analytics platform, they often focus only on query latency. "Can it return an answer within 50ms?" is a reasonable question, and one most analytical engines can answer convincingly if you throw enough compute at a static dataset.

The question that decides what users actually experience is harder. It is whether the system can return a 50ms answer **on data that arrived a second ago**, while ingestion is still running, and while other users are also querying.

Data availability requires thinking about end-to-end time-to-insight, which has three components.

- **Time to ingest.** How long does it take for newly generated data to land in the platform and become durably stored?
- **Time to transform and prepare.** How long does it take to clean, enrich, join, pre-aggregate, or update the serving structures (materialized views, rollups, indexes) that queries actually hit?
- **Time to query.** How long does it take to plan and execute the read once the data is available?

![data_delays.png](/uploads/data_delays_7b8b4a6044.png)

A system can be fast on one of these dimensions but still feel slow to the user if another one dominates. 

**All of these properties need to hold at scale and with resource efficiency under high ingest throughput and high query concurrency.** 

Importantly, a platform that achieves real-time latencies only by throwing unbounded compute at the workload is not a real-time platform you can afford. The hard part is meeting all of these requirements, with the same engine, against the same data, without trading one off against the other.

## Why data platforms struggle with this shape of workload

Most of the platforms in use today were designed for an earlier generation of analytics: batch ingestion, scheduled transformations, and internal users running ad-hoc queries on data that was hours old. They are excellent at what they were built for, but struggle with real-time analytics for reasons that are fundamentally architectural.

These architectural limitations can be broadly grouped into several categories:

1. **An ingest path that is optimized for batches, not continuous streams.** Many warehouse architectures use optimistic concurrency control. Writers proceed independently and resolve conflicts at commit time through retries. This works when writes are infrequent and well-sized batches. However, as concurrent writers grow, the system is subject to more retries to resolve conflicts, causing tail latencies to increase. Continuous high-concurrency ingestion is exactly the workload that exposes this.
2. **Fresh writes are not immediately visible.** In many modern lakehouse and warehouse architectures, data is not queryable immediately after it is written. It has to pass through a catalog refresh, a manifest update, a materialized view refresh, or a metadata reconciliation step before queries can see it. This delay is fine for an end-of-day report but fatal for a feature whose value depends on showing what just happened.
3. **Optimizations are not applied to live data.**  Many warehouse architectures rely on materialized views to perform scheduled transformations and precompute results for low-latency serving. These optimizations are often refreshed every hour, every fifteen minutes, or every minute if you are paying for it. As a result, the freshest your serving layer can possibly be is bounded by that interval. This limitation is architectural, with no amount of additional compute able to remove it. While a 15-minute lag is invisible in a billing dashboard, it is the difference between catching and missing an event in a fraud signal or live leaderboard.
4. **Headline performance depends on caches that do not survive ingestion.** Benchmarks on a static dataset show performance for cached, pre-warmed queries. Once continuous writes are added to the workload, every new part potentially invalidates some of these caches on which performance is dependent. The result is that the performance you saw in the demo is not the performance you will see in production.
5. **Real-time capabilities are isolated feature sets of the platform.** When a platform was not designed for real-time from the start, the common pattern is to bolt on a separate tier: a different table type, a different warehouse type, a different set of supported operations. Snowflake's Interactive Tables and Interactive Warehouses are a recent example. Low-latency queries are available, but only against a specific table and warehouse type that cannot query standard tables, with a list of feature limitations that the [documentation describes as architectural](https://docs.snowflake.com/en/user-guide/interactive#limitations-of-interactive-warehouses-and-interactive-tables). A user who wants real-time behavior across their entire dataset, not just a carved-out capability, is forced to make compromises and architect their solution according to the constraints.
6. **Specialized query types that each need their own system.** Modern analytical workloads are not just structured rows. Teams want to filter logs by keyword, compare embeddings for similarity, and query semi-structured JSON with evolving schemas. The traditional answer is to add a search engine for text queries, a vector database for embeddings, and a separate warehouse for everything else. Each additional system is another ingestion pipeline, another consistency boundary, another freshness floor, and more architectural complexity. Your end-to-end latency is determined by the slowest component.

None of this is a criticism of those platforms for what they were built to do. Batch-era warehouses are still excellent at scheduled, internal-facing analytics. The point is that real-time analytics is different enough in shape that retrofitting it onto those architectures runs into limits that are not simply a matter of tuning.

## What a real-time analytics platform actually has to do

A platform built from the ground up for real-time analytics has to make a few specific design decisions. When you evaluate platforms for this workload, these are the requirements to check.

1. **Does ingestion scale without degrading queries?** Continuous writes should not pull query latency along with them. In practice, that means an ingestion path that can run on isolated resources from the read path, and a concurrency model that holds tail latencies bounded as writers grow. ClickHouse, for example, uses consensus-based coordination through Keeper rather than optimistic concurrency. It pays a small coordination cost on every write, but keeps tail latencies predictable at the high insert concurrency seen in real-time workloads.
2. **Is data queryable within a second or two of being written?** At real-world scale, the realistic target is a delay measured in milliseconds to a couple of seconds, with no catalog or manifest refresh sitting in the middle. 
3. **Do transformations update incrementally, and not on a schedule?** Materialized views, rollups, and pre-aggregations (done using [AggregatingMergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/aggregatingmergetree) in ClickHouse) should update with each insert, not on an interval. This ensures that they're immediately applied and enforce a delay on data availability. This ensures, for example, that:
    - A live billing or usage view stays accurate as charges accrue, instead of jumping every fifteen minutes when the rollup refreshes. This matters when customers are looking at the same number you are.
    - A fraud or anomaly aggregation reflects the most recent events, instead of always being one window behind. This matters when the value of catching the event decays in seconds.

![scheduled_vs_incremental_views.png](/uploads/scheduled_vs_incremental_views_09e6115f62.png)

This maintenance model matters to cost and scalability. Materialized views that rely on full rescans for every update turn freshness into a scaling problem, with update cost growing alongside table size. Incremental materialized views amortize this cost across inserts, processing each row once as it arrives instead of repeatedly recomputing the full dataset.

4. **Can you bias the system towards read-time or write-time work?** Different workloads want different trade-offs. For some, you want indexes and aggregations built at write time so the freshest queries are immediately accelerated. For others, you want to keep the ingest throughput maximal and let the background work catch up. A real-time platform should expose that choice without forcing it. And index maintenance should never block ingestion. New data should be queryable as soon as it is committed, with or without its indexes fully built.
5. **Does a single engine serve all workloads?** Text search, vector similarity, JSON, structured analytics. These should live in the same storage and query engine, not in four loosely coupled systems with their own freshness floors. Every system you remove from the stack is one fewer place where data can fall behind.

![loosely_tightly_coupled.png](/uploads/loosely_tightly_coupled_07060e9416.png)

6. **Is the performance shown on hot data, not just on cached benchmarks?** The realistic question to ask of any platform is how fast its queries are on data that arrived a second ago, not how fast its repeated queries are on yesterday's table. The first number is what production looks like.

7. **Does resource efficiency hold up at scale?** Real-time systems need to remain efficient as ingest volume, query concurrency, and retention grow. The important question is whether performance scales linearly with workload, or whether latency and compute costs begin to degrade disproportionately as traffic increases.

The common thread across these requirements is that real-time analytics is not a feature you switch on. It is a set of design decisions about ingest, storage, transformation, and query that have to be made consistently across the whole system. Either the platform was designed for this workload, or it is working hard to approximate it.

## Bullet - what real-time looks like in practice

Bullet, a crypto derivatives exchange, runs a trading frontend that depends on real-time data. Their previous batch-era stack ran 5 to 30 second queries and 20-minute hourly ETL jobs, leaving users looking at data up to 1.5 hours stale. On ClickHouse Cloud, queries return in milliseconds, data latency dropped 99.4% to under 5 seconds, and the team handles 1,000× more data at comparable cost. As Co-Founder and CTO Tristan Frizza puts it: 

> "We used to have a data lake, a serving layer, and all these other things that would break all the time. ClickHouse became the one-size-fits-all."

For real-world examples of real-time analytics at scale, [explore how our customers](https://clickhouse.com/user-stories?useCase=1) are delivering fresh data and low-latency insights with ClickHouse.



Interested in seeing how ClickHouse works on your data? Get started with ClickHouse Cloud in minutes and receive $300 in free credits.

Get started today

    Most databases can query fast. Far fewer can query data that arrived seconds ago. Learn what real-time analytics really requires.

large_selecting-a-real-time-analytical-database.png

medium_selecting-a-real-time-analytical-database.png

small_selecting-a-real-time-analytical-database.png

thumbnail_selecting-a-real-time-analytical-database.png

selecting-a-real-time-analytical-database.png

What to look for when selecting a real-time analytical database

How we integrated the Rust Delta Kernel to replace our native Delta Lake implementation, reducing maintenance overhead while unlocking writes, schema evolution, time travel, and partition pruning.

large_image1.png

medium_image1.png

small_image1.png

thumbnail_image1.png

image1.png

Integrating the Rust Delta Kernel into ClickHouse

We're excited to announce a new integration between ClickHouse and Google's [Lakehouse Runtime Catalog](https://docs.cloud.google.com/biglake/docs/blms-rest-catalog), enabling direct querying of [Google Cloud Lakehouse Iceberg tables](https://docs.cloud.google.com/biglake/docs/biglake-iceberg-tables-in-bigquery) in ClickHouse via [Apache Iceberg REST Catalog](https://iceberg.apache.org/).

This integration debuts as a beta feature in ClickHouse 26.2 and will be available shortly after in ClickHouse Cloud.

## **Why Iceberg REST Catalog?** {#why_iceberg_rest_catalog}

A common challenge for data teams is making all their data accessible regardless of where it lives. Discovery, governance, and access control need to work across data lakes, warehouses, and operational stores.

Lakehouse Runtime Catalog solves this by providing a centralized catalog for Apache Iceberg tables in Google Cloud. That enables interoperability with any Iceberg-compatible engine: BigQuery, Apache Spark, Trino, and now ClickHouse.

By connecting to the REST Catalog, ClickHouse can discover and query Google Cloud Lakehouse Iceberg tables stored in Cloud Storage with no data movement, no proprietary connectors, and no metadata syncing required. Data engineers can write Google Cloud Lakehouse Iceberg tables with Spark or BigQuery, and analysts can immediately query that same data with ClickHouse for fast, complex analytics. Data can also be loaded into ClickHouse's native format in a single query using this integration!

## **How does the integration work?** {#how_does_the_integration_work}

To use this integration, you need two things:

* A ClickHouse instance (ClickHouse and [ClickHouse local](https://clickhouse.com/docs/operations/utilities/clickhouse-local) supported)  
* A [Google Cloud project](https://cloud.google.com/) with Lakehouse Runtime Catalog enabled

Lakehouse Runtime Catalog tracks the Iceberg metadata for Iceberg tables and exposes it via the Iceberg REST Catalog API at `https://biglake.googleapis.com/iceberg/v1/restcatalog`. ClickHouse connects to this endpoint to discover and query the underlying tables directly.

For authentication, ClickHouse integrates with Google's [Application Default Credentials (ADC)](https://docs.cloud.google.com/docs/authentication/provide-credentials-adc) mechanism.

## **Getting started** {#getting_started}

Deploy ClickHouse on [Google Cloud](https://clickhouse.com/partners/gcp) or use [ClickHouse local](https://clickhouse.com/docs/operations/utilities/clickhouse-local), ensuring you're on version 26.2 or later. Once your instance is ready, follow the steps below to connect to the Lakehouse Runtime Catalog. Read more in the [ClickHouse documentation for Lakehouse Runtime Catalog](https://clickhouse.com/docs/use-cases/data-lake/biglake-catalog).

## **Authentication with Google Application default credentials** {#authentication_with_google_application_default_credentials}

ClickHouse supports Google ADC natively, giving you two options to authenticate with the Lakehouse Runtime Catalog.

### **Option 1: Point to your ADC credentials file**

If you already have Application Default Credentials configured on your machine (e.g. via `gcloud auth application-default login`), you can simply point ClickHouse to the JSON credentials file. This is the easiest approach for local development and testing:

<pre><code type='click-ui' language='sql'>
SET allow_database_iceberg = 1;

CREATE DATABASE Lakehouse_catalog
ENGINE = DataLakeCatalog('https://biglake.googleapis.com/iceberg/v1/restcatalog')
SETTINGS
  catalog_type = 'biglake',
  google_adc_credentials_file = '/path/to/application_default_credentials.json',
  warehouse = 'gs://&lt;bucket_name&gt;/&lt;optional-prefix&gt;';
</code></pre>

ClickHouse reads the `client_id`, `client_secret`, `refresh_token`, and `quota_project_id` directly from the JSON file, so you don't need to specify them individually.

### **Option 2: Provide credentials inline**

For production deployments or environments where a credentials file isn't available, you can provide the OAuth credentials directly in the query settings:

<pre><code type='click-ui' language='sql'>
SET allow_database_iceberg = 1;

CREATE DATABASE Lakehouse_catalog
ENGINE = DataLakeCatalog('https://biglake.googleapis.com/iceberg/v1/restcatalog')
SETTINGS
  catalog_type = 'biglake',
  google_adc_client_id = '&lt;client-id&gt;',
  google_adc_client_secret = '&lt;client-secret&gt;',
  google_adc_refresh_token = '&lt;refresh-token&gt;',
  google_adc_quota_project_id = '&lt;gcp-project-id&gt;',
  warehouse = 'gs://&lt;bucket_name&gt;/&lt;optional-prefix&gt;';
</code></pre>

Both approaches use the same underlying OAuth flow to authenticate with the Iceberg REST Catalog endpoint and authorize access to the data in Cloud Storage.

## **Querying Google Lakehouse Iceberg tables from ClickHouse** {#querying_google_lakehouse_iceberg_tables_from_clickhouse}

Once you've created a connection using either of the authentication methods above, querying your Google Lakehouse Iceberg tables is straightforward.

### **Listing available tables**

List all tables available in the catalog:

<pre><code type='click-ui' language='sql'>
SHOW TABLES FROM Lakehouse_catalog;
</code></pre>

```shell
┌─name─────────────────────────┐
│ public_data.nyc_taxicab      │
│ public_data.nyc_taxicab_2021 │
└──────────────────────────────┘
```

### **Querying tables**

Query any Google Cloud Lakehouse Iceberg table directly:

<pre><code type='click-ui' language='sql'>
SELECT count(*)
FROM Lakehouse_catalog.`public_data.nyc_taxicab`
WHERE vendor_id = 1;
</code></pre>

You can also inspect the full schema:

<pre><code type='click-ui' language='sql'>
SHOW CREATE TABLE Lakehouse_catalog.`public_data.nyc_taxicab`;
</code></pre>

Backticks are required around table names because ClickHouse doesn't support more than one namespace level.

### **Loading data into ClickHouse for faster queries**

For use cases that require repeated, low-latency queries, you can load data from Google Cloud Lakehouse Iceberg tables into a ClickHouse table:

<pre><code type='click-ui' language='sql'>
CREATE TABLE local_taxi_data
(
    `vendor_id` Int64,
    `pickup_datetime` DateTime64(6),
    `dropoff_datetime` DateTime64(6),
    `passenger_count` Int64,
    `trip_distance` Float64,
    `total_amount` Float64,
    `pickup_location_id` Int64,
    `dropoff_location_id` Int64
)
ENGINE = MergeTree
ORDER BY (pickup_datetime, vendor_id);

INSERT INTO local_taxi_data
SELECT
    vendor_id, pickup_datetime, dropoff_datetime,
    passenger_count, trip_distance, total_amount,
    pickup_location_id, dropoff_location_id
FROM lakehouse_catalog.`public_data.nyc_taxicab`;
</code></pre>

You can now query the local_taxi_data directly in ClickHouse native format for low query latency.

## **What's next** {#whats_next}

This release is just the first step toward deeper integration with Google Cloud's data ecosystem.

We're already working on several enhancements for upcoming releases, including:

* **Write support:** Adding support for writing data back to Google Cloud Lakehouse Iceberg tables from ClickHouse.  
* **Enhanced cloud integration:** Introducing a new user interface in ClickHouse Cloud to easily create connections to the Lakehouse Runtime Catalog and query your data directly from the UI.

![](/uploads/lakehouse_apr2026_image1_c9bdbd90df.png)

With ClickHouse and the Lakehouse Runtime Catalog, you can run fast analytics on all of your Google Cloud Lakehouse Iceberg tables in Google Cloud, without moving data, without duplicating it, and without giving up the tools your teams already use.

## **Get started today** {#get_started_today}

Deploy ClickHouse on [Google Cloud](https://clickhouse.com/pricing?plan=scale&provider=gcp&region=gcp-us-central1&hours=8&storageCompressed=false) or use [ClickHouse local](https://clickhouse.com/docs/operations/utilities/clickhouse-local) once your instance is ready, follow the steps below to connect to the Lakehouse Runtime Catalog. Read more in the [ClickHouse documentation for Lakehouse Runtime Catalog](https://clickhouse.com/docs/use-cases/data-lake/biglake-catalog).


We're excited to announce a new integration between ClickHouse and Google's Lakehouse Runtime CatalogCatalog

large_Google Next Blog Banners 1626.jpg

medium_Google Next Blog Banners 1626.jpg

small_Google Next Blog Banners 1626.jpg

thumbnail_Google Next Blog Banners 1626.jpg

Google Next Blog Banners 1626.jpg

ClickHouse integrates with Lakehouse Runtime Catalog

ClickHouse now supports direct querying of Iceberg and Delta Lake formats across major cloud catalogs without requiring data   migration.

large_image4.jpg

medium_image4.jpg

small_image4.jpg

thumbnail_image4.jpg

image4.jpg

ClickHouse is data lake ready

medium_fts_mar2026_image5.png

small_fts_mar2026_image5.png

thumbnail_fts_mar2026_image5.png

fts_mar2026_image5.png

medium_fts_mar2026_image8.png

small_fts_mar2026_image8.png

thumbnail_fts_mar2026_image8.png

fts_mar2026_image8.png

medium_fts_mar2026_image4.png

small_fts_mar2026_image4.png

thumbnail_fts_mar2026_image4.png

fts_mar2026_image4.png

To validate this more broadly, we benchmarked Full-text Search on 50 TB of log data with 59 vCPU and 256GB of RAM in ClickHouse Cloud. In addition to query latency, we measured storage overhead and insert performance. The index introduces additional write cost, with insert throughput reduced by ~50 percent compared to no index. However, the query performance gains are substantial: up to 10 times faster for cold queries, and even greater improvements when data is cached [on local nodes](https://clickhouse.com/blog/building-a-distributed-cache-for-s3). Compared to Bloom filter-based approaches, Full-text Search is typically slightly slower on inserts but delivers multiple times faster performance at query time.

The animation below illustrates the impact on end-to-end query latency across representative workloads.


o11y-fts.mp4


There is also a storage tradeoff. Full-text Search indexes are larger than Bloom filters, and both are larger than having no index at all. The difference is visible when comparing index sizes directly for our Github dataset:

<pre><code type='click-ui' language='sql'>
SELECT
    name,
    type,
    formatReadableSize(data_compressed_bytes) AS compressed_bytes,
    formatReadableSize(data_uncompressed_bytes) AS uncompressed_bytes
FROM system.data_skipping_indices
WHERE (`table` = 'github_events') AND (database = 'github') AND ((name = 'bloom_body') OR (name = 'fts_body'));
</code></pre>

```shell
   ┌─name───────┬─type─────────┬─compressed_bytes─┬─uncompressed_bytes─┐
1. │ fts_body   │ text         │ 215.84 GiB       │ 223.13 GiB         │
2. │ bloom_body │ bloom_filter │ 7.04 GiB         │ 7.24 GiB           │
   └────────────┴──────────────┴──────────────────┴────────────────────┘

2 rows in set. Elapsed: 0.003 sec.
```

That said, in ClickHouse Cloud the cost of storage is often a small fraction of overall infrastructure spend. At approximately $25 per TB per month, even a sizable index is rarely a dominant cost driver for large analytical workloads, with overall compression remaining strong.

For example, if we look at the compression rate for the GitHub table, it is about 9x before considering the text index. This reduces to around 6x when we factor in the text index.

<pre><code type='click-ui' language='sql'>
SELECT
    formatReadableSize(sum(data_compressed_bytes)) AS compressed_size,
    formatReadableSize(sum(data_uncompressed_bytes)) AS un_compressed_size
FROM system.columns
WHERE (`table` = 'github_events') AND (database = 'github');
</code></pre>

```shell
┌─compressed_size─┬─un_compressed_size─┐
│ 477.09 GiB      │ 4.23 TiB           │
└─────────────────┴────────────────────┘

1 row in set. Elapsed: 0.004 sec.
```

There are still open questions for some scenarios, particularly around how the index interacts with node level and distributed caching layers in observability workloads. For this reason, we have not yet made it the default in ClickStack, but we expect to address these considerations and expand default usage in the near future.

## GitSearch - a Full-text Search demo {#gitsearch_a_full_text_search_demo}

The examples above illustrate the mechanics and performance characteristics, but the best way to understand Full-text Search is to try it yourself. To make this easy, we have built an interactive public demo, [GitTrends](https://gittrends.clickhouse.com/), on top of the same GitHub Events dataset.

![](/uploads/fts_mar2026_image7_520bc9d605.png)

In the demo, you can search for any technology term and instantly see how mentions trend over time across all public GitHub repositories.


GitTrends v2.mp4

Users can then drill into specific repositories where that technology appears, analyze how it shows up in issues and pull requests, and explore how interest in a given project evolves. You can even compare multiple technologies side by side, offering a lightweight alternative to tools like Google Trends for understanding activity and momentum within the developer ecosystem.

![](/uploads/fts_mar2026_image1_3870d680a5.png)



![](/uploads/fts_mar2026_image6_9bdf472d6f.png)

All of this is powered by Full-text Search. For those who want to explore the performance differences directly, the UI also allows you to toggle between Full-text Search, Bloom filter based search, and a linear scan, so you can see the impact of each approach in real time.

As in all of our public demos, we'll keep the dataset updated (hourly) so our users can benefit from GitHub analytics for free.

## Conclusion {#conclusion}

We are delighted to announce that Full-text Search in ClickHouse is now generally available and ready for production use. After multiple iterations and significant performance work, including optimizations for object storage in ClickHouse Cloud, we are excited for users to begin benefiting from fast, native text search at scale.

To celebrate the [GA release, we are hosting a webinar](https://clickhouse.com/company/events/202602-EMEA-AMER-Webinar-FullTextSearch) on March 11th with the engineering team, where we will take a deeper dive into the internals, design decisions, and benchmark results behind Full-text Search.

We look forward to seeing how the community applies this powerful new capability across analytics, observability, and beyond, and to hearing the success stories that follow.


large_Text Indices GA ClickHouse Issue 1440.jpg

medium_Text Indices GA ClickHouse Issue 1440.jpg

small_Text Indices GA ClickHouse Issue 1440.jpg

thumbnail_Text Indices GA ClickHouse Issue 1440.jpg

Text Indices GA ClickHouse Issue 1440.jpg

Announcing General Availability of ClickHouse Full-text Search

**San Francisco, CA — November 18, 2025 — ClickHouse Inc.**, the company behind one of the world’s fastest and most popular real-time analytics databases, today announced the availability of a powerful new integration with [Microsoft OneLake](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview), the unified data lake of Microsoft Fabric.

This integration enables organizations to harness the scale, governance, and simplicity of OneLake with the speed and flexibility of ClickHouse for real-time, large-scale analytical workloads. Learn more in our [technical post](http://www.clickhouse.com/blog/clickhouse-integrates-with-microsoft-onelake).

## Expanding the ClickHouse-Microsoft collaboration

Following the general availability of [ClickHouse Cloud on Microsoft Azure](https://clickhouse.com/blog/clickhouse-cloud-is-now-generally-available-on-microsoft-azure), recent performance enhancements of ClickHouse on Azure Blob Storage, and [a steady series of new capabilities](https://clickhouse.com/blog/a-year-of-clickhouse-cloud-on-azure), this integration with Microsoft OneLake marks the latest milestone in ClickHouse’s growing collaboration with Microsoft.

This initiative reinforces ClickHouse’s commitment to deep interoperability across Microsoft’s data ecosystem. From Azure to Fabric, the goal is to enable real-time analytics within a unified platform for Microsoft customers.

## Improved interoperability between ClickHouse and Microsoft OneLake

Organizations are increasingly unifying their data with a lakehouse architecture, a flexible foundation that supports best-of-breed tools across workloads, from large-scale analytics with ClickHouse to emerging GenAI and AI agent use cases and more. By storing data in open table formats such as Apache Iceberg or Delta Lake, teams ensure accessibility and interoperability across engines, including ClickHouse, so they can always use the right tool for the job.

The ClickHouse integration with OneLake Table APIs exposes Iceberg tables to ClickHouse, allowing users to directly access and analyze their data, facilitating federated and unified analytics across both ClickHouse and Fabric.

Facilitating real-time analytics with ClickHouse

A common challenge for databases is simplifying how data is ingested into the system itself. This new integration gives Fabric customers powerful new options to query critical data in low latency and high concurrency from OneLake with ClickHouse, enabling new workloads such as real-time analytics, operational dashboards, and agent-facing analytics.

“Microsoft OneLake is a very popular data lake solution among our users, and we’ve long wanted to provide a direct integration to enhance their experience, especially by simplifying data movement and analysis. With the introduction of Table APIs in OneLake, we were finally able to do just that. ClickHouse can now natively query data stored in OneLake, giving users seamless access to all their data in OneLake with zero friction,” said Alexey Milovidov, Co-Founder and CTO of ClickHouse.

“For data to be useful, it must be interoperable with a range of tools our customers use every day,” said Dipti Borkar, VP & GM for Microsoft OneLake and Fabric Ecosystem. “Customers can now use ClickHouse on data unified by Microsoft OneLake to deliver on some of the most data-intensive use cases, like real-time observability, cybersecurity & fraud detection and AI.”

## *About ClickHouse*
   
ClickHouse is a fast, open-source columnar database management system built for real-time data processing and analytics at scale. Engineered for high performance, ClickHouse Cloud delivers exceptional query speed and concurrency, making it ideal for applications that demand instant insight from massive volumes of data. As AI agents become increasingly embedded in software and are generating far more frequent and complex queries, ClickHouse brings a high-throughput, low-latency engine, purpose-built to meet this challenge. Trusted by leading companies like Sony, Tesla, Anthropic, Memorial Sloan Kettering, Lyft, and Instacart, ClickHouse helps teams unlock insights and drive smarter decisions with a scalable, efficient, and modern data platform. For more information, visit [clickhouse.com](http://clickhouse.com).  
  

ClickHouse today announced the availability of a powerful new integration with Microsoft OneLake, the unified data lake service within Microsoft Fabric.

Melvyn Peignon

Blog posts by Melvyn Peignon

What to look for when selecting a real-time analytical database

Integrating the Rust Delta Kernel into ClickHouse

ClickHouse integrates with Lakehouse Runtime Catalog

ClickHouse is data lake ready

Announcing General Availability of ClickHouse Full-text Search

ClickHouse strengthens collaboration with Microsoft through Microsoft OneLake Integration for Seamless Data Interoperability