Query Current State with a Streamhouse on Confluent Cloud

A Streamhouse serves current state from one continuously maintained table, instead of having each team load and maintain its own copy in a separate database. You read the table through Lightning Tables, Snapshot Queries, Tableflow, or the Model Context Protocol (MCP).

This page describes the always-current table, how to choose a way to read from it, and the products and access patterns that serve it.

Start here: the always-current table

The way into a Streamhouse is a single table. You define your current state once as an Apache Flink® materialized table. You then serve that same table in three ways, for low-latency reads, for operational systems, and for analytics, instead of standing up a separate system for each destination.

To build this pattern yourself in about 30 minutes, see Quick Start: Build a Streamhouse on Confluent Cloud.

One table, three modes

You can serve the same maintained state in three ways:

Serve current state with Lightning Tables for low-latency reads, to AI agents, and to applications through Early Access direct API access.
Drive operational systems by consuming the table’s backing topic with sink connectors. For more information, see Connect to External Services in Confluent Cloud.
Feed the lakehouse you already have by exposing the same state as Apache Iceberg or Delta Lake with Tableflow.

A materialized table writes to a backing topic, and you enable a Lightning Table and Tableflow on that topic. To serve the table this way, give it a primary key so that it writes its changes in upsert mode. For more information, see Enable the Real-Time Context Engine on a topic, Tableflow in Confluent Cloud, and Tableflow upsert mode.

Where the table is built

The materialized table is the boundary between processing and querying: processing builds the current state, and the query capabilities serve it. You build and maintain the table in Confluent Cloud for Apache Flink. The deep reference for materialized tables is in the Flink documentation.

Choose a query surface

After you have an always-current table, choose how to read from it based on the task you’re doing. Each workload reads the table through the surface that fits it.

Pick a surface by the task

Surfaces fall into two tiers. Serving-optimized surfaces handle many fast, concurrent queries at low latency, such as agent context, user-facing dashboards, and in-app analytics. Throughput-optimized surfaces handle a few large, complex queries that run in seconds to minutes, such as ad-hoc exploration, complex joins, and aggregations.

If you want to	Use	Through	Availability	Typical persona
Look up current state with low latency and high concurrency (serving-optimized)	Lightning Tables	Confluent Cloud Console, MCP, or the API	Rolling out to accounts in phases. Direct API access is an Early Access Program feature.	Application, AI/ML, and platform engineers
Serve context to AI agents (serving-optimized)	MCP and the Real-Time Context Engine	MCP	Generally available	AI/ML engineers
Run ad-hoc exploration and complex analytical queries (throughput-optimized)	Snapshot Queries	Flink SQL	Generally available	Data engineers, analysts
Feed a data warehouse or lakehouse (throughput-optimized)	Tableflow	Iceberg or Delta Lake tables	Generally available	Data engineers

Query products

Query products are the ways the platform serves current state for you to read.

Lightning Tables

A Lightning Table is a read-only table that the Real-Time Context Engine maintains for each topic where you enable it, such as the backing topic of a Flink materialized table. You query it through the Model Context Protocol (MCP), or directly through the API in Early Access, with point lookups, range scans, and full scans at low latency, so you don’t have to load the state into a separate database yourself.

For the full documentation, see Lightning Tables in Confluent Cloud.

Snapshot Queries

Snapshot Queries run a bounded query that spans live Apache Kafka® topics and the historical data Tableflow keeps in Iceberg tables, in a single statement, so one decision can draw on both current conditions and long-range context.

For the full documentation, see Snapshot Queries in Confluent Cloud for Apache Flink. To run one, see Run a Snapshot Query with Confluent Cloud for Apache Flink.

Tableflow

Tableflow materializes the backing topic of your always-current table as Apache Iceberg or Delta Lake tables, so your existing warehouse and lakehouse tools read the same state without a separate pipeline.

Tableflow publishes new data to these tables approximately every 5 minutes. For more information, see Table freshness. In the Streamhouse, Tableflow is the lakehouse-facing way to serve the one maintained table.

For the full documentation, see Tableflow in Confluent Cloud.

Access patterns

Access patterns are the ways a consumer connects to the query products in the previous section.

MCP and the Real-Time Context Engine

The Real-Time Context Engine serves current state to AI agents over the Model Context Protocol (MCP). In the Streamhouse, MCP is an access pattern rather than a separate query product: it’s how an agent reads the state that the Real-Time Context Engine maintains for the always-current table’s backing topic.

For the full documentation, see Real-Time Context Engine in Confluent Cloud.

Ways to query a Lightning Table

You query a Lightning Table with SQL, so you can read the current state in a Streamhouse without writing Kafka consumers. For the interfaces you can use to query a Lightning Table and how they compare, see Lightning Table Queries in Confluent Cloud.

You can query a Lightning Table in the following ways:

From Confluent Cloud Console, by running SQL in the Lightning Table’s preview panel. For a walkthrough, see Step 5: Serve the current state with Lightning Tables.
From AI agents, through the Real-Time Context Engine over the Model Context Protocol (MCP). For more information, see MCP and the Real-Time Context Engine.
From applications, directly through the API, which is an Early Access Program feature. For details and the sign-up form, see Query a Lightning Table with the API.

Note

This website includes content developed at the Apache Software Foundation under the terms of the Apache License v2.