Five projects that quietly became one stack
The open lakehouse now runs on five interlocking Apache projects: Parquet for storage encoding, Arrow for in-memory and wire format, Iceberg for table semantics, Polaris for catalog and access control, and the newly incubating Ossie for business semantics. Parquet and Arrow are over a decade old at this point, which matters because it means the newer layers, Iceberg and Polaris, are being built on genuinely battle-tested foundations rather than novel formats still finding their failure modes.
As Dremio's head of developer relations put it in a September 3 assessment of the ecosystem, the state of the open lakehouse this month is a stack that stopped arguing about whether it won and started dealing with the consequences of winning. That is a useful way to read the last six months of activity: less debate about whether Iceberg beats proprietary formats, more focused engineering on the unglamorous plumbing, versioning policies, catalog governance, credential handling, that determines whether the format actually holds up under real enterprise load.
Polaris becomes neutral ground, on paper and in governance
Apache Polaris, the open catalog that governs access to Iceberg tables, graduated to Top-Level Project status within the Apache Software Foundation on February 18, 2026. That graduation is not a cosmetic milestone. It means Polaris's governance now runs through the Apache Software Foundation's neutral process rather than any single vendor's roadmap, which is exactly the structural protection that vendor-owned query engines and catalogs cannot offer, regardless of how open the underlying table format is.
Polaris 1.7.0 shipped with Kafka event publishing and Google Cloud Storage attribution, and 1.8.0 was targeted for early September with tags, directories, OpenLineage integration, and data sharing features, all under a release manager rotating through the community rather than a single company's release calendar. For any CTO weighing whether to trust an open catalog against a vendor-controlled alternative, this governance structure, not just the code, is the asset worth pricing into the decision.
A semantic layer built specifically for AI agents
The newest addition to the stack, Apache Ossie, entered the Apache Incubator in June 2026 with a narrower and more urgent goal than the other four projects: giving business metrics and dimensions a shared, machine-readable definition that LLM agents can rely on consistently. The problem it targets is concrete. Ask two different AI agents to calculate customer churn against the same warehouse today, and they can produce two different numbers because each is inferring the business logic from context rather than reading it from an agreed definition.
Ossie is still early, source-only distribution discussions were underway as of September, with a compliance suite in progress and no formal release yet. But its existence signals something important for anyone planning an agentic AI rollout on top of a lakehouse: the industry has recognized that ungoverned semantic ambiguity, not model capability, is the practical blocker to trusting AI agents with financial and operational metrics, and it is building open infrastructure specifically to close that gap rather than leaving it to each vendor's proprietary semantic layer. That choice matters for the same reason Polaris's governance structure matters: a semantic layer everyone can inspect and extend is a very different trust proposition than one locked inside a single vendor's product.
The release cadence is the actual signal
Look past the roadmap and at the calendar for early September alone: PyIceberg 0.12 shipped September 1 with binding votes from a named set of maintainers, Arrow Rust 59.3.0 followed the same day after verification across three separate hardware platforms, and the first stable release of the Apache Iceberg Terraform provider went out after a release candidate cleared a licensing review that had blocked two earlier attempts. Parquet Java 1.18.1 was in release-candidate review by the end of August with six named committers signing off.
None of these are individually dramatic. Together, they describe an ecosystem operating with the release discipline of enterprise software, named maintainers, binding votes, cross-platform verification, licensing review, rather than the more informal cadence typical of a fast-moving open source project still finding its process. One community discussion captured the shift directly: sustained, high-quality review now matters more than pull request count when considering someone for committership, a governance standard that mirrors how mature commercial software teams evaluate senior engineers rather than how young open source projects have historically operated. For a platform team deciding whether to trust this stack in production, that process maturity is as reassuring a signal as any individual feature release.
The operational scars nobody puts in a keynote
Maturity also means the community is now openly documenting the failure modes that only show up at production scale, and this list is the most practically useful part of the whole update. Small files cause query planning to slow down at the Parquet layer. Manifest files bloat over time at the Iceberg layer and require active maintenance jobs most teams underbudget for. Short-lived REST catalog tokens expire mid-job on long-running queries, killing pipelines with no obvious error message pointing back to the real cause.
Two more are worth flagging directly to any data engineering lead: accumulated equality deletes degrade read performance in ways that are easy to miss until query latency has already crept up over months, and Polaris's default purge configuration blocks view drops in a way that surprises teams who expected view management to work the same as table management. None of these are reasons to avoid the open lakehouse stack. They are the exact line items that belong in your platform team's operational runbook before you put Iceberg and Polaris in front of a production SLA, and the fact that the community is documenting them this openly is itself evidence of a project confident enough in its adoption to admit where it still hurts.
