# 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](../flink/concepts/materialized-tables.md#flink-sql-materialized-tables). 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](quick-start.md#streamhouse-quick-start). ### One table, three modes You can serve the same maintained state in three ways: - [Serve current state](#streamhouse-query-lightning-tables) 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](../connectors/overview.md#kafka-connect-cloud). - [Feed the lakehouse you already have](#streamhouse-query-tableflow) 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](../ai/real-time-context-engine/get-started.md#rtce-enable-topic), [Tableflow in Confluent Cloud](../topics/tableflow/overview.md#cloud-tableflow), and [Tableflow upsert mode](../topics/tableflow/concepts/write-modes.md#cloud-tableflow-write-modes-upsert). ### 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. - [Materialized Tables in Confluent Cloud for Apache Flink](../flink/concepts/materialized-tables.md#flink-sql-materialized-tables) - [Stream Processing with Confluent Cloud for Apache Flink](../flink/overview.md#ccloud-flink) ## 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](#streamhouse-query-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](#streamhouse-query-mcp) | MCP | Generally available | AI/ML engineers | | Run ad-hoc exploration and complex analytical queries
(throughput-optimized) | [Snapshot Queries](#streamhouse-query-snapshot-queries) | Flink SQL | Generally available | Data engineers, analysts | | Feed a data warehouse or lakehouse (throughput-optimized) | [Tableflow](#streamhouse-query-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](../lightning-tables/overview.md#lightning-tables-overview). ### 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](../flink/concepts/snapshot-queries.md#flink-sql-snapshot-queries). To run one, see [Run a Snapshot Query with Confluent Cloud for Apache Flink](../flink/how-to-guides/run-snapshot-query.md#flink-sql-run-snapshot-query). ### 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](../topics/tableflow/overview.md#cloud-tableflow-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](../topics/tableflow/overview.md#cloud-tableflow). ## 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](../ai/real-time-context-engine/overview.md#real-time-context-engine). ### 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](../lightning-tables/query/overview.md#lightning-tables-query-overview). 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](quick-start.md#streamhouse-quick-start-step-5). - **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](#streamhouse-query-mcp). - **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](../ai/real-time-context-engine/lightning-queries.md#rtce-lightning-queries). #### NOTE This website includes content developed at the [Apache Software Foundation](https://www.apache.org/) under the terms of the [Apache License v2](https://www.apache.org/licenses/LICENSE-2.0.html).