StreamNative shipped Lakestream last week. Confluent has Tableflow in GA. Aiven launched Iceberg Topics. The pitch is identical across all three: your Kafka topic is your Iceberg table. No connectors, no ETL, no redundant copies. Just produce via the Kafka protocol, query from Spark or Trino or Snowflake. Done.
Five days ago I walked through nine different ways to move data from Kafka to Iceberg. Now I'm starting to wonder if I should have titled that post "enjoy this while it lasts."
The Promise: One Object, Two Interfaces
The core idea behind topic-table duality is deceptively simple. A stream and a table share the same physical storage. Produce a message and it materializes as a row queryable by whatever analytics engine your team already uses — no sink connector sitting in between, no consumer group to babysit, no intermediate staging layer.
StreamNative's Lakestream takes the most radical approach. Their storage engine, Ursa, ditches local broker disks entirely. Every write lands in a write-ahead log for sub-millisecond latency, then background compaction converts those entries into Parquet files on object storage, organized as Iceberg or Delta Lake tables. The brokers are stateless and leaderless — any node handles any partition. No leader elections, no rebalancing storms when a node goes down. They claim 95% cost reduction at 5 GB/s throughput, which sounds outrageous until you realize most of traditional Kafka's bill comes from cross-AZ replication that Ursa simply doesn't do.
Confluent's Tableflow works differently. It sits on top of Kora, their existing storage layer, and materializes topic segments as Parquet files with Iceberg metadata generated from Schema Registry. It's closer to an "automatic connector" than a storage rethink — the stream and the table aren't literally the same bytes on disk, but the system handles the translation transparently so you don't have to manage it.
Aiven's Iceberg Topics land somewhere in between: incoming records get batched into Parquet, committed as Iceberg snapshots with exactly-once semantics. Pragmatic, less revolutionary, gets the job done.
How They Actually Differ
This matters more than the marketing copy suggests.
| StreamNative Lakestream | Confluent Tableflow | Aiven Iceberg Topics | |
|---|---|---|---|
| Storage model | Object storage native (no local disks) | Kora + async materialization | Broker storage + Iceberg snapshots |
| Broker architecture | Stateless, leaderless | Traditional (managed) | Traditional (managed) |
| Write latency | Sub-ms via WAL | Standard | Standard |
| Iceberg write path | Inline compaction | Background materialization | Batch snapshots |
| Catalog support | Unity, Horizon, Polaris, S3 Tables | Iceberg REST (Glue planned) | Native catalog |
| Open source | Planned (Ursa) | No | Partial |
StreamNative is rebuilding the streaming stack from the storage layer up. Confluent is adding a feature to a platform that already owns the market. Aiven is bridging the gap without asking you to rearchitect anything. Each bet makes sense given where each vendor sits — and each has tradeoffs the launch blog posts conveniently omit.
The Fine Print
Here's where my inner on-call engineer starts twitching.
Compaction staleness. When StreamNative advertises "sub-millisecond write latency," that's the WAL path. The Iceberg table doesn't refresh at sub-millisecond granularity — there's a compaction step that batches WAL entries into columnar format. How long is that window? The product page doesn't say. If your analysts are querying the Iceberg interface while fresh data sits in the WAL, you have a staleness gap that nobody defined an SLA for. For dashboards refreshing every 15 minutes, this is irrelevant. For a fraud detection system that needs the last 30 seconds of transactions, you just built something that looks real-time but isn't.
Schema mapping isn't free. Avro union types, field defaults, and type promotion don't map cleanly to Iceberg's column definitions. Confluent leans on Schema Registry to bridge this, but anyone who's fought a schema compatibility rejection on a Friday deploy knows this translation layer is where production incidents hide. StreamNative's approach sidesteps some of this by writing directly to Parquet, but you still need to reconcile the producer's schema expectations with what downstream query engines can actually read.
Leaderless ordering guarantees. Ursa offloads sequence coordination to Oxia, a dedicated metadata service. That's elegant on a whiteboard, but it introduces a coordination dependency that traditional broker-leader designs internalize. If Oxia becomes a bottleneck or has a partial failure, your ordering guarantees get fuzzy. Anyone who's operated Dynamo-style leaderless systems at scale knows that "leaderless" doesn't mean "simpler" — it means the complexity moved somewhere less visible.
"Open source soon" is not open source now. StreamNative plans to release Ursa to the community "in the coming months." Tableflow is proprietary. The data sits in open formats, which is genuinely valuable — you can walk away from any of these vendors and still read your Parquet files. But the orchestration layer, the thing that makes topic=table actually work, is the part you can't easily replace. Open formats reduce lock-in; they don't eliminate it.
Who Should Evaluate This Now
If you're running a healthy Kafka Connect pipeline today, don't rip it out. The operational maturity of these unified systems — monitoring, failure modes, debugging tools — is months behind where the connector ecosystem stands. Connect is boring. Boring is good at 3 AM.
That said, three situations where the math changes:
Greenfield projects with no existing streaming infrastructure. Starting with Lakestream or Tableflow means one fewer system to operate from day one. The reduced operational surface area compounds over time.
Cost-dominated decisions. If your streaming bill is mostly cross-AZ replication and broker EBS volumes, Ursa's architecture (stateless nodes, object storage only, no inter-zone data movement) genuinely shifts the economics. Run a proof of concept at your throughput before trusting the 95% headline. Vendor benchmarks test vendor-friendly workloads.
Connector fatigue. If someone on your team spends double-digit hours per week nursing Connect workers, debugging offset commits, and manually compacting small files, the operational simplification of a unified system might justify the platform risk — even if the technology is younger.
For everyone else: the connector approach works, it's well-understood, and it'll keep working for years. But watch the Lakestream open-source release closely. If Ursa ships as a genuine community project and not a managed-service upsell, the streaming-lakehouse architecture conversation changes permanently.