Three problems, one solution
Streambased unifies Kafka and Iceberg into a single, queryable view, live and historical data together, without moving or copying anything. That one capability can answer a wide range of different data challenges.
August 31, 2026
We talk to a lot of teams working with Kafka and Iceberg, and the conversation soon turns to a cost or a challenge: an AI agent reasoning without being able to see what’s happening in the present moment, a pipeline stack with too many places to fail, a CDC bill that’s grown faster than the data behind it.
Different questions, different teams asking them perhaps, but Streambased offers the same mechanism to address them all: Kafka and Iceberg unified into one single, queryable view, without moving or copying the data.
Which of these questions can we answer for you?
‘Why does my support team keep asking customers to troubleshoot their own tickets?’
Sending someone a checklist of commands and log requests, then waiting on their reply, is still how a lot of support and SRE teams investigate issues. It’s slow, it puts the diagnostic work back on the customer, and every round trip adds time to resolution.
AI tools haven’t fully closed that gap. Most can answer from documentation, or execute a fix once someone’s told them what’s wrong, but there’s a layer missing in between: an understanding of what’s actually happening right now, in production, behind a specific ticket.
Streambased sits in that gap. It gives AI agents a unified, queryable view across live and historical operational data, spanning Kafka and Iceberg, so an agent can compare current behaviour against historical baselines, test hypotheses and reach a root cause on its own.
That means less back-and-forth, faster resolution, and fewer tickets that need a human to escalate before the problem’s been diagnosed.
Streambased AI for customer success
‘Why does getting data from A to B take six systems?’
The usual route from an operational database into an analytics stack runs through several hops: a CDC tool capturing changes, a Kafka topic carrying them, a nightly transform job, a warehouse holding the result.
Every hop is something to build, run, and potentially break, and it could be hours before anyone notices the numbers downstream are wrong.
Streambased collapses that chain to a single hop. Connect the databases, SaaS applications and event sources your data already lives in, then query them directly from the engines you already run, Snowflake, Databricks, Spark, Trino and others, through open standards rather than a proprietary format. Nothing gets migrated and nothing gets copied.
The value here is engineering time and infrastructure cost: fewer systems to maintain, fewer copies to keep in sync, fewer 3am pages when a pipeline breaks and nobody notices.
Streambased for Zero-ETL data transfer
‘Why is my CDC bill six figures when the data itself barely registers?’
A busy CDC feed runs at around 3MB a second, well within home broadband capabilities. But the bill can easily run in six figures. The reason the bill doesn’t match that is mechanical: CDC costs scale with table count and commit frequency, not data volume. Every commit into a materialised table means deduplication, file rewrites, new snapshots and compaction, whatever the size of the actual change.
Streambased works differently. Instead of ingesting your change feed into another system, it acts as a gateway over Kafka, exposing your existing topics directly as Iceberg tables. Deduplication happens once per range and gets cached, rather than repeated on every commit.
The value here is direct and measurable: cost tracks the volume of change itself rather than table count or query load, which on a like-for-like workload comes out roughly eight times cheaper than a tightly materialised setup on Snowflake or Databricks, at the same freshness.