Skip to content

CONCEPT Cited by 1 source

Bridge query

A bridge query is a single SQL statement that transparently reads from both an Iceberg table (historical/cold tier) and the underlying Redpanda topic (live/hot tier) via one virtual table. The query engine handles the stitching: historical data comes from Iceberg Parquet files, the most recent messages come straight from the topic, and the result set has nothing missing or duplicated.

Key properties

  1. Single logical table. The consumer writes SQL against one table name; the engine routes reads to the appropriate tier.
  2. Deduplication-free stitching. Because the Redpanda broker performs the Iceberg conversion, it has authoritative knowledge of what's in which tier. The bridge is a simple concatenation, not a dedup join.
  3. Freshness decoupling. The topic covers the recency gap, so the flush interval can be optimized for file layout rather than freshness (Source: sources/2026-06-23-redpanda-bridge-queries-in-redpanda-sql).

Architectural unlock

Bridge queries invert the traditional streaming-to-lakehouse constraint where the flush interval must equal the freshness requirement. With the topic available as a query source, the flush cadence can be driven by storage-layout concerns (large, well-compressed Parquet files) rather than dashboard latency needs.

Seen in

Last updated · 559 distilled / 1,651 read