BigQuery vs Kubernetes
Side-by-side trajectory, velocity, and editorial themes.
BigQuery doubles down on Iceberg, graph, and global data sharing as the lakehouse fight intensifies.
BigQuery's May 2026 ship list is dominated by three tracks: open-format lakehouse integration (Iceberg v3 with deletion vectors, REST catalog support in Conversational Analytics), graph capabilities maturing inside BigQuery Studio, and global data exchange via multi-region sharing listings reaching GA. Alongside the feature work, Google is tightening Data Transfer Service security (MFA on Google Ads transfers) and warning about Ads retention changes that will cap historical backfills from June 1. The release notes show a mature warehouse continuing to absorb adjacent workloads rather than reinventing itself.
BigQuery is positioning itself as the federated query and sharing fabric for a multi-format world, with Iceberg getting closer to first-class status and Conversational Analytics extending across external catalogs. The graph and notebook work signals a push to keep more analytical work inside Studio instead of bouncing to specialized tools. Expect continued layering of governance, AI-assisted query, and open-table support on top of the existing engine rather than core engine reinvention.
Next obvious step is GA for Iceberg v3 features and full conversational graph querying without Preview gating. Watch for additional first-party data sources getting MFA mandates, mirroring the Google Ads tightening.
Kubernetes 1.36 leans into AI/ML scheduling and control-plane scaling.
The 1.36 cycle is graduation-heavy, with PSI metrics, declarative validation, and volume group snapshots all promoted to GA. Alongside that, the project is making architectural moves around workload scheduling (a new PodGroup API), API-server safety (Mixed Version Proxy on by default), and very-large-cluster scaling (server-side sharded list and watch in alpha). Etcd 3.7 has hit beta in parallel.
Kubernetes is repositioning the control plane for two pressures at once: AI/ML batch workloads, where gang scheduling and DRA are becoming first-class concerns, and very-large clusters, where the control plane itself needs to shard. The pattern across this cycle is consolidation — old experimental scaffolding is reaching GA or being removed (ExternalIPs), while new APIs land with explicit separation of static template from runtime state. Less feature sprawl, more API hygiene.
Expect 1.37 to push server-side sharded watch toward beta and to keep extending DRA's reach into native resources like memory and networking. Workload-aware scheduling will likely accumulate scheduler-plugin-level coordination patterns next, with downstream batch frameworks starting to converge on the PodGroup shape.
See more alternatives to BigQuery →
See more alternatives to Kubernetes →