by Alex Stephen & Talat Uyarer, Lakehouse

Apache Iceberg project has just launched version 1.11.0! A lot has happened since the last version.

Iceberg 1.11.0 adds support for Apache Spark 4.1 and Apache Flink 2.1, the latest releases of the two engines and makes both the default build targets

The rest are more structural. The REST catalog learns to plan scans server-side, shifting metadata work off the query engine. A new partition statistics scan API gives optimizers a clean, supported way to read a table's shape. Built-in table encryption arrives with envelope encryption and Google KMS support. And Google Storage Analytics library integration makes your Iceberg workloads faster than before.

Let's take a look at some of the biggest changes.

Spark & Flink Updates

As Spark and Flink are moving forward, the 1.11.0 release is pushing forward for new version support in both.

• Spark 4.1 & DSv2 Migration: Spark 4.1 unlocks is MERGE INTO with automatic schema evolution: Spark's newer MERGE syntax accepts a WITH SCHEMA EVOLUTION clause, so a MERGE whose source carries columns the target table lacks can add those columns to the table within the same statement, with no separate ALTER TABLE round trip. Beyond the version bump, the 1.11 Spark connector also modernizes against Spark's newer DataSource V2 APIs and adds an asynchronous micro-batch planner that speeds up Structured Streaming.
• Flink Ecosystem Updates: Initial work for Flink 2.1 support has landed in the core repository, continuing Iceberg's promise of providing first-class, low-latency streaming sink capabilities. The centerpiece of the Flink work is the DynamicIcebergSink, an experimental sink that breaks the old one-sink-per-table model: a single sink routes each record to a table chosen at runtime, creating tables on demand and evolving their schemas and partition specs on the fly as the input changes including dropping columns once you opt in with dropUnusedColumns. In addition to DynamicIcebergSInk work Flink started supporting nanosecond, variant and unknown types from V3 Spec.

Server-side scan planning

In previous versions of Iceberg, the client handled the heavy lifting of scan orchestration. The driver of engine would traverse the table's metadata tree, retrieving manifest lists and files from object storage to filter data against specific partition requirements. Iceberg 1.11.0 shifts this computational burden into the catalog through server-side scan planning.

Instead of manually traversing manifests, the engine submits a single POST …/plan request detailing the scan allowing the REST catalog to return optimized FileScanTasks.

The API is designed to handle data at any scale: smaller scans return immediate results, extensive operations return a plan-id for polling, and massive datasets are retrieved via parallel plan-tasks through POST …/tasks.

Built-in table encryption

As data lakes increasingly serve as the central hub for sensitive PII and financial data, relying solely on bucket-level storage encryption is no longer enough. Iceberg 1.11.0 introduces built-in table encryption, bringing fine-grained, KMS-backed security directly to the table level.

This provides data platform teams with robust capabilities for security and compliance:

• Zero-Trust Storage Security: Even if a malicious actor gains direct access to your underlying object storage bucket, the data remains completely unreadable.
• Total Index Protection: It isn't just the raw data that is protected; Iceberg encrypts the manifest lists as well, preventing attackers from inferring sensitive information from table statistics.
• Tamper-Proof Data: Built-in authentication tags guard against unauthorized modifications, ensuring data integrity.
• Effortless Key Rotation: Keys are rotated automatically as they age, satisfying strict compliance mandates without requiring you to rewrite massive datasets.

Iceberg achieves this using envelope encryption with a three-tier key hierarchy. A table master key lives securely in your KMS and never touches Iceberg storage. This master key wraps key-encryption keys (KEKs), which are stored safely inside the table metadata. Finally, each KEK wraps a unique, per-file data-encryption key (DEK).

Every data file and manifest list is then encrypted with AES-GCM under its own unique DEK. This decoupled architecture ensures maximum security while maintaining the high performance expected of Iceberg workloads.

File Format API

Historically, Iceberg's format-handling code was tightly coupled, growing organically around Parquet, Avro, and ORC. Adding a new format or enforcing consistent feature support (like V3 default values or new column types) across all formats meant duplicating complex engine-specific switch/case code paths.

Iceberg 1.11.0 introduces the finalized File Format API, bringing a consistent API to reading and writing all of these file formats.

Instead of hardcoded engines handling binary extraction, the architecture introduces:

• FormatModel: A standardized implementation defining how a file format handles reader/writer construction and its specific capabilities.
• FormatModelRegistry: A central directory where query engines fetch appropriate read and write builders.

This API (which is already seeing adoption around other Apache Iceberg implementations) provides a significant code cleanup for the future of the project. It also opens the door for more file formats as time goes on.

Moreover, this new interface facilitates the implementation of Column Families, enabling vertical partitioning of storage. This advancement lets teams perform targeted updates or rewrites on isolated columns—such as recalculating vector embeddings—while leaving the remaining table data undisturbed.

SQL UDF Specification

1.11.0 includes the SQL UDF specification, which adds a brand new metadata format for both Scalar and Table Functions:

• Immutable Versioning and Rollback: UDF metadata is written as self-contained, versioned JSON files stored right in the object store. If a data engineer deploys a buggy UDF update, administrators can execute an atomic rollback to a previous version log state
• Standardized Schema Typings: Parameters and return types map cleanly to Iceberg Type JSON representations, directly accommodating complex nested maps, structs, and the upcoming Iceberg V3 variant type.
• Engine Specific Execution: Each SQL UDF has a function implementation for each engine, allowing users to leverage engine-specific functionality in their UDFs.

Google Analytics Library Integration

For Google Cloud customers, version 1.11.0 delivers substantial throughput gains by embedding the GCS Analytics Core library into GCSFileIO (Issue #14326, PR #14333).

This integration introduces Footer Prefetching, which optimizes Parquet length checks by caching object suffixes to remove network overhead. Combined with threaded VectoredIO for concurrent multi-range operations and specialized small object caching for sub-1MB files, these enhancements eliminate persistent I/O bottlenecks. Initial benchmarks indicate that these architectural improvements can reduce Parquet metadata parsing latency and boost total record processing speeds, empowering high-scale Spark, Flink, and Trino workloads to run with improved efficiency on Google Cloud Storage.

Getting Started with 1.11.0

We are excited to be part of the Apache Iceberg community and innovating together. As a compliant Iceberg REST Catalog, Lakehouse for Apache Iceberg (formerly BigLake) already has support for version 1.11.0.

To upgrade your environment, update your build dependencies to version 1.11.0. Remember to review your deployment runtimes to ensure compatibility with the new JDK 17 baseline, and test your workloads if you are transitioning from Spark 3.4.

For a full breakdown of every bug fix, contributor attribution, and dependency bump, check out the official Apache Iceberg Releases Page

Hi everyone! We've just released Chrome Stable 149 (149.0.7827.45) for iOS; it'll become available on App Store in the next few hours.

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

The Stable channel has been updated to 148.0.7778.216/217 for Windows and 148.0.7778.215/216 Mac  and 148.0.7778.215 for Linux, which will roll out over the coming days/weeks. A full list of changes in this build is available in the Log

Interested in switching release channels? Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.

Srinivas Sista

Google Chrome

New updates to help you spot and connect with high-quality, original content in Google Search.

Starting on June 2nd, 2026, the Google Ads API will transition reach metrics to a "Total Co-view" definition. This update aligns Google Ads reporting with offline media and third-party measurement standards, ensuring consistency across all reporting surfaces, including the Google Ads UI and Editor.

The updated definition of the video view metrics will include all individuals who viewed the ad on connected TV devices, including cases where multiple people are watching YouTube together on the same TV screen.

This change impacts the following reach metrics at the campaign level:

• metrics.unique_users
• metrics.average_impression_frequency_per_user
• metrics.unique_users_two_plus
• metrics.unique_users_three_plus
• metrics.unique_users_four_plus
• metrics.unique_users_five_plus
• metrics.unique_users_ten_plus

Required actions

No API version migration or code changes are required to see this new behavior, as it is a data definition change that will be applied automatically.

However, developers and advertisers should be prepared for a potential change in reported reach and frequency values for dates beginning with the launch date. We recommend updating internal documentation or dashboards to reflect this shift in measurement methodology.

If you have any questions or concerns regarding this update, please reach out via the

“Google Advertising and Measurement Community” Discord server.

Find out what you might have missed and go deeper on all the big announcements from Google I/O 2026 using NotebookLM.

Latency, often called "ping," measures the round-trip time in milliseconds for data to travel between a device and a server. GFiber delivers a typical latency of 14.8 milliseconds (ms), providing a high-performance foundation for competitive gaming, real-time video collaboration, and AI-driven applications.[1]

The technical advantage of pure fiber (FTTH)

This low latency is due to our 100% fiber-to-the-home (FTTH) architecture, where light travels through fiber optic cables directly from our network to the Fiber Jack in your home. Unlike "hybrid fiber" or "fiber-powered" networks that often use copper segments for some portion of their infrastructure, our pure fiber connection was specifically built from the ground up for the dedicated purpose of providing extremely fast internet, not cable television.

Performance benchmarks for real-time use

For remote workers and gamers, lower latency means faster response times. GFiber’s 14.8ms latency is well within the high-performance range for critical digital tasks and 41% better than the US average:[1]

• Competitive gaming: At 14.8ms, commands register near-instantly, keeping players in the performance window required for competitive play. GFiber has been recognized as PCMag’s Best Gaming ISP for three consecutive years.[2]

• Remote work: Symmetrical speeds and low latency ensure video and voice quality remain ideal during video conferencing.

• AI and smart home integration: Rapid request-response cycles are essential for the responsiveness of AI tools and connected home devices. 14.8ms latency ensures these applications stay responsive, even as they grow in complexity and become more and more common.

Standardized measurement and future-ready capacity

In addition to a battery of comprehensive internal monitoring and testing, GFiber monitors latency using the Ookla® multi-server methodology, which measures the median latency across multiple off-network servers to simulate real-world internet use. 

To support capacity demands for now and years to come, GFiber upgraded to 25G PON (passive optical network) technology in 2025. This infrastructure investment increases total network capacity and is designed to support the next generation of immersive video and cloud computing.

Learn more about GFiber speeds. 

GFiber products and symmetrical speeds

All GFiber products provide symmetrical upload and download speeds on the same low-latency network foundation. Symmetrical speeds are essential for latency-sensitive tasks because high upload capacity prevents bottlenecks when you're sending data.

Learn more about GFiber products. 

---

Frequently Asked Questions

What is a good latency for home internet?

For most internet use, latency under 20ms is excellent, under 50ms is good, and under 100ms is acceptable. GFiber's typical latency is 14.8ms.[1]

Does GFiber have low latency for gaming?

Yes. GFiber changed the game for gaming, delivering a typical latency of 14.8ms, measured against multiple off-network servers. This is well within the range required for competitive online gaming and a primary reason GFiber is a multi-year winner of the PCMag Best Gaming ISP award.

What is the difference between latency and download speed?

Download speed measures the volume of data transferred per second, while latency measures the speed of a single round trip. Both affect your experience, but different activities depend on latency and download speed differently. Streaming video depends heavily on download speed. Gaming, video calls, and real-time AI tools depend heavily on latency. GFiber’s average download speed is 448.0Mbps versus the US average of 295.7Mbps.[3]

What is 25G PON and why does it matter for latency?

25G PON (passive optical network) is fiber infrastructure capable of delivering 25 gigabits of capacity over a single fiber strand. GFiber has been upgrading to this technology for years. The investment to increase network capacity and drive latency down further, has built a future-proof foundation that powers even stronger AI applications, immersive video, and cloud computing.

Disclaimers

[1] Typical Latency: Latency comparison based on analysis by GFiber from Ookla® Speedtest Intelligence® data of GFiber multi-server median latency and combined median multi-server latency of all U.S. fixed broadband providers and speed tiers for Q2 2025. Individual speeds vary.

[2] PCMag Award: A trademark of Ziff Davis, LLC. Used under license. Reprinted with permission. © 2025 Ziff Davis, LLC. All Rights Reserved.

[3] Faster than U.S. average based on analysis by GFiber of Ookla® Speedtest Intelligence® data comparing GFiber fixed broadband median download or upload speeds to combined median download or upload speeds of all U.S. fixed broadband providers and speed tiers for Q2 2025. Individual speeds vary.

Hi everyone! We've just released Chrome Beta 149 (149.0.7827.46) for iOS; it'll become available on App Store in the next few days.

You can see a partial list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

We’re introducing more granular admin controls for Workspace Studio steps and starters. With these new controls, admins can define which steps and starters people in their organization can use to create flows, including by Workspace service or individually. They provide admins more granular control of Studio functionality, and are particularly useful for gradual rollout of Studio in their organizations.

Looking for some good vibes on your next drive? We teamed up with musician Ziggy Marley to bring his signature calming energy to Waze. To celebrate his new album, “Brigh…