Apache Iceberg™ Europe Community Meetup - London Hub
Apache Iceberg™ Europe Meetup - London Hub!
Join us for the Apache Iceberg™ Europe Meetup in London! Our event is hosted in London co-hosted by Fresha, Databricks and Vakamo.
🎟️ When registering, please select one of the two ticket types:
In-Person Ticket: Join us on-site! Your name will be used to pre-register for venue access.
Remote-Only Ticket: Can’t make it in person? No worries—register to join the live stream, receive event recordings, and stay connected with the community.
Livestream
Agenda
5:00 pm – Registration & Networking
6:00 pm – 1st set of short talks
🎙️ Giannis Polyzos (Fresha) - Apache Fluss and The Streaming Lakehouse: Rethinking Architecture For Data & AI
🎙️ Elizabeth Christensen (Snowflake) - The Open Data Stack: Postgres, pg_lake, Iceberg
🎙️ Jimmy Angelakos (pgEdge) - ColdFront: Transparent PostgreSQL Data Tiering with Apache Iceberg
7:30 pm – 8:00 pm Networking break
🎙️ Jan Kaul (Vakamo): Lakekeeper — Running compaction with concurrent writes
🎙️ Andrei Tserakhau (Databricks) - From Data Portability to Metadata Portability
How to Get to the Venue
Address:
The Bower, 207-211, Old St, Tower, London EC1V 9NR, United Kingdom
Building Access
Fresha Office(8th Floor)
🪪 ID Requirements
bring an Id with you
Presentations & Speakers
🌟Apache Fluss and The Streaming Lakehouse: Rethinking Architecture For Data & AI
For over a decade, building streaming data platforms has meant assembling a patchwork of specialised systems—message layers, stream processors, databases, caches, and analytical engines. Each solves a narrow problem well, but the cumulative cost is high: duplicated data, fragmented consistency, and significant operational overhead.
Apache Fluss challenges this by natively integrating streaming into the Lakehouse, as a first-class architectural capability built directly on top of it. By making the table the core abstraction, one that natively handles row, columnar, and vector data, Fluss eliminates the need to juggle multiple systems for different workloads. Data can be ingested, updated, and served continuously through a single unified interface.
In this session, we'll explore what it means to treat streaming as a native Lakehouse capability, how it solves challenges with Apache Iceberg, how it simplifies a real-time architecture, and where this new paradigm is headed
Giannis: An engineer working at the intersection of stream processing, streaming data infrastructure, and distributed data systems.
Over the years, he has helped design and operate large-scale streaming data platforms used by large-scale organisations in production. He enjoys turning complex distributed systems into dependable platforms that data teams can understand, adopt, and operate successfully.
He is a PMC member of Apache Fluss and has been deeply involved in the Apache Flink and broader streaming ecosystem. He particularly interested in streaming storage, stateful stream processing, stream/batch unification, and the data foundations behind real-time intelligent systems.
His work focuses on unifying batch and streaming architectures, simplifying data primitives, and enabling streaming analytics and stateful workloads at scale. Lately he focuses on the real-time context layer for AI.
🌟The Open Data Stack: Postgres, pg_lake, Iceberg
Read and write to Apache Iceberg with Postgres using an open source extension, pg_lake. Everyone loves the interoperability that Iceberg brings to the “table”. pg_lake makes the world of Iceberg even bigger by connecting it to the most popular transactional db, Postgres.
In this talk, we’ll dig into pg_lake, look at a couple demos, and show some sample pipelines for simplifying data movement processes for getting data to and from Iceberg. We’ll also cover some of the architecture which merges a traditional Postgres server with a DuckDB one to get the best of both OLAP and OLTP.
If you’re hoping the modern data estate will be built on open standards top to bottom, this talk will show you how to build it with Postgres, pg_lake, and Apache Iceberg.
Elizabeth is an open source software advocate at Snowflake focused on Postgres and the open lakehouse. She’s a Postgres contributor, hosts the Postgres Meetup for All series, a local KC user group, and co-hosts PostGIS Day. She is a board member at the United States PostgreSQL Association.
🌟 ColdFront: Transparent PostgreSQL Data Tiering with Apache Iceberg
PostgreSQL data tiering today asks you to compromise. You either build fragile, custom ETL pipelines to move aging rows to a data lake and then you have to query two completely different systems, or hoard everything in Postgres and pay premium block storage prices for cold data, while performance degrades and backups bloat.
ColdFront is the missing piece. It seamlessly bridges PostgreSQL and Apache Iceberg, allowing a single table to span recent rows in native Postgres partitions and older rows on S3, Azure, or GCS. The magic is in the transparency: the cold tier is readable and writable through the exact same standard SQL. Your application queries and mutates the table as an ordinary Postgres relation without code changes.
Under the hood, ColdFront uses pg_duckdb to query Iceberg in-process, intelligently intercepting and rewriting DML to the correct tier. You choose the architecture per table: Tiered mode, where a Go archiver moves rows from hot to cold with a watermark and a schedule, or Decoupled mode, where the table lives entirely in Iceberg from the first row and scales horizontally across Postgres nodes.
The talk covers:
* The architecture: How standard SELECT, INSERT, UPDATE, and DELETE statements are transparently rewritten under the hood to target native Postgres partitions or Iceberg via DuckDB.
* The operating modes: Balancing performance and storage by choosing between Tiered (hot PG + cold Iceberg) and Decoupled (Iceberg only) configurations.
* The bakery protocol: How ColdFront safely serializes Iceberg commits across many PostgreSQL nodes so concurrent writers never collide at the Lakekeeper catalog, including a look at verifying its safety with TLA+.
* The security model: How application roles are seamlessly onboarded with least-privilege access, reading and writing the cold tier without ever requiring superuser access or host-level file privileges.
You'll leave this presentation with a concrete look at how to seamlessly blend transactional database workloads with modern data lake storage, and an invitation to spin up the stack yourself: ColdFront is open source.
Jimmy Angelakos is a Systems and Database Architect and recognized PostgreSQL expert who has worked with, and contributed to, Open-Source tools for 25+ years. He is passionate about participating in the community, is a Significant Contributor to the PostgreSQL project, and an active member of PostgreSQL Europe. Jimmy is a regular speaker at conferences and events, sharing his insights with the community. Author of [PostgreSQL Mistakes and How to Avoid Them](https://www.manning.com/books/postgresql-mistakes-and-how-to-avoid-them), co-author of [PostgreSQL 16 Administration Cookbook](https://www.packtpub.com/product/postgresql-16-administration-cookbook/9781835460580).
🌟 Lakekeeper — Running compaction with concurrent writes
Compaction keeps Iceberg tables fast and cheap to read, but running it on a live table means competing with the writers still committing to it. This talk looks at what happens when the two collide — the kinds of conflicts that arise, and why they can quietly stall compaction on busy tables.
We'll walk through how Lakekeeper resolves this from its position as the catalog: letting compaction commit transparently so that writers always win, breaking work into many small commits so a single conflict never throws away good progress, and using delete-file compaction to keep things running smoothly. A practical look at making automatic compaction safe to run against a table that never stops taking writes.
Jan Kaul recently joined Vakamo, the company behind Lakekeeper, an open-source Apache Iceberg REST catalog written in Rust. He is the initiator of iceberg-rust, the Rust implementation of Apache Iceberg. He also built Frostbow, an in-process analytical query engine for Iceberg tables in object storage. His work focuses on materialized views and incremental view maintenance. Jan holds a PhD in mechanical engineering from TU Wien and describes himself as an engineer turned programmer.
🌟 From Data Portability to Metadata Portability
Open table formats made the data portable. A table can move across Spark, Trino, Flink, and other engines without copying it or tying it to one vendor.
But a lot of the context around that table is still stuck in the catalog: how a column is classified, who owns the table, what it costs, or what an AI agent should know about it. That metadata is still exposed through vendor-specific APIs.
This talk looks at how the Iceberg REST Catalog is starting to make that context portable too, through two recent additions: read restrictions and catalog labels.
Read restrictions let a catalog pass an access decision to a trusted engine. Catalog labels let the catalog expose its own metadata through a standard interface.
I’ll cover how both work, why the formats were kept intentionally small, and what they do not try to solve. Then I’ll look at what could come next: discovery, cost attribution, AI context, and the harder metadata problems that are still open.