The most common architecture question I get in 2026 is no longer "should we use Iceberg." That one is settled. The question now is "how fresh can our Iceberg tables be," followed immediately by "and what do we do when that is not fresh enough."
Those two questions deserve a serious answer, because the space has gotten crowded. Open source engines, Kafka Connect sinks, brokers that write Iceberg natively, managed vendor pipelines, and streaming databases all now claim the same job: moving events from a stream into an Iceberg table. They differ wildly in latency, cost, operational burden, and what they quietly break. Picking among them without understanding the underlying physics is how teams end up with a pipeline that technically works and a table that queries terribly.
So this article is my July 2026 map of the territory. We will start with the physics, because every option is a different negotiation with the same constraints. Then we will walk the options one by one, open source and vendor, with honest latency expectations and honest trade-offs. And we will finish with the part most articles skip: the architectural patterns for workloads where even a well-tuned Iceberg pipeline is not fast enough, and how to serve sub-second freshness without giving up the lakehouse.
