Lakehouse Day

For years, the "Data Lakehouse" was a buzzword owned by individual vendors. In 2026, the narrative has shifted. A powerful, community-driven ecosystem has emerged—the Apache Lakehouse—a modular architecture built entirely on open-source standards that rivals the performance and governance of proprietary warehouses.

At the heart of this movement is a "Separation of Concerns" that gives organizations ultimate freedom.

The Foundation (The Table Format): Why Apache Iceberg, Hudi, and Paimon have won the "format wars" by providing ACID transactions and schema evolution on top of simple object storage.

The Control Plane (The Catalog): How Apache Polaris (incubating) and Apache Gravitino (incubating) are solving the "metadata silos" by providing a centralized, REST-based source of truth for all engines.

The Streaming Lakehouse: A look at newer projects like Apache Fluss (incubating) that bridge the gap between real-time streaming and historical analytics without data duplication.

The decomposed nature of Lakehouse makes observability challenging. We'll share the practices we've found most effective for monitoring our managed multicloud (AWS, GCP, Azure) and multi-engine (Spark, Trino, Flink, and more) Iceberg Lakehouse at Datadog. Topics include monitoring lineage, data quality, usage costs, performance metrics, query pattern analysis, data access audits, and orphan files management. We'll discuss which real-time monitors prove to be the most helpful, and which of them should page you.

Apache Iceberg is the de facto table format for modern lakehouse architectures, but its real value emerges when it supports diverse workloads. In this talk, we share how Akamai built Egnatia, an Iceberg platform that delivers seven-figure annual cost savings.

You’ll learn how we run two demanding workloads on Apache Iceberg:

• CDN batch analytics: Upsert-heavy, join-intensive pipelines with complex lineage
• Security event data: Faced with rising Splunk costs, we migrated security telemetry to Iceberg, enabling near–real-time ingestion of high-volume data, enriched with internal context and used for threat detection, analytics, alerting, and investigation
• We’ll also share key architectural decisions and lessons learned running Iceberg across batch and streaming workloads.

By the end of the session, you will gain:

• How to integrate Iceberg for batch and real-time workloads
• How to operate upsert-heavy pipelines with complex dependencies
• How Iceberg supports security analytics, alerting, and orchestration as a SIEM
• Practical patterns to reduce costs and modernize data platforms

Strict data lake workloads—like star schema ETLs—suffer from torn multi-table reads and partial writes. While Apache Iceberg provides robust single-table commits, cross-table atomicity remains an active frontier. Workarounds like eventual consistency, Git-like branching, or single-engine warehouses either compromise correctness, add operational complexity, or break the open, multi-engine lakehouse promise.

This session explores an engine-neutral proposal bringing warehouse-grade BEGIN/COMMIT semantics to the Iceberg REST Catalog. We will break down this architecture into four pillars and demonstrate them live via an Apache Polaris (incubating) PoC:

1. Stateless Coordination: Delegating atomicity to the catalog's backing DB.
2. TxnSnapshots: Lightweight handles guaranteeing consistent reads across multiple engines (Spark, Flink) and apps.
3. Selectable Isolation Levels: Flexible choices from READ COMMITTED to REPEATABLE READ.
4. Retryable Subtransactions: Overcoming Optimistic Concurrency (OCC) limits using pessimistic locking to safely retry transient failures.

In 2017, Mark Raasveldt and Hannes Mühleisen (who went on to create DuckDB) presented a VLDB paper entitled “Don’t Hold My Data Hostage – A Case For Client Protocol Redesign.” Their paper proposed the use of columnar serialization to achieve order-of-magnitude improvements in query result transfer performance. Eight years later, this talk revisits Raasveldt and Mühleisen’s argument and describes the central role that the Apache Arrow project has played in realizing this vision—through the dissemination of Arrow IPC, Arrow Flight, Arrow Flight SQL, Arrow over HTTP, and ADBC across numerous open source and commercial query systems. The talk concludes with a call to action to introduce Arrow-based transport to the systems that continue to “hold data hostage.”

DataSource V2 (DSv2) is a core but often overlooked part of Apache Spark. It connects Spark’s engine to many data sources, from Apache Iceberg to JDBC and Parquet, allowing Spark to push down optimizations and use source-specific features.

This talk covers recent progress in Spark–Iceberg integration. New features like the procedure catalog and row identifiers enable better table management and row-level operations. Improvements to MERGE INTO and INSERT INTO bring safer schema evolution and more reliable writes, while better data filtering improves query performance.

We’ll also cover DML summaries for clearer write visibility, cache fixes for correctness, and deeper Change Data Feed (CDF) support for incremental processing.

Looking ahead, DSv2 is enabling new SQL features like constraints, default values, and generated columns. Spark’s design here is not just evolving itself—it’s also influencing Apache Iceberg, helping close the gap with data warehouses.

As AI/ML workloads grow, the need for a scalable, secure, and vendor-neutral data layer becomes critical. Using Open Table Formats (OTF) provided by catalogs like Apache Polaris, organizations can now transform S3-compatible storage into a first-class Data Lakehouse. However, manual orchestration of these layers often leads to configuration drift and security gaps.

This session breaks down a production-ready integration pattern designed for automation and high security: The Control Plane: Using a Kubernetes-native approach with a "Glue-Operator" and CRDs to orchestrate resources across different service

The Data Plane: Achieving seamless integration with compute engines like Spark for high-performance AI/ML querying. The Security Layer: Moving beyond static Access/Secret keys by implementing Zero-Trust through vended credentials, ensuring short-lived, scoped access for every workload.

The session concludes with a comprehensive live demo.

Apache Spark is a foundational engine behind OpenAI’s hyperscale lakehouse and many of our most critical data pipelines. In this talk, we’ll share how we run Spark in production on a rapidly evolving platform, covering the design and architecture of key systems such as cluster lifecycle management, job submission and scheduling, access control, dynamic scaling, and release management.

Beyond architecture, we’ll dive into the realities of day to day operations: managing shuffle heavy workloads, supporting PySpark pipelines, and processing large scale semi structured data. We’ll also show how we use AI to accelerate failure diagnosis and performance debugging, and how we are evolving the lakehouse into an AI native platform.

Beyond architecture, we’ll dive into the realities of day to day operations: managing shuffle heavy workloads, supporting PySpark pipelines, and processing large scale semi structured data. We’ll also show how we use AI to accelerate failure diagnosis and performance debugging, and how we are evolving the lakehouse into an AI native platform.

Apache Iceberg V3 changes what's possible for Lakehouse governance -- but most discussions focus on batch scenarios. This session explores what V3 means for organizations streaming real-time data into their Lakehouse, where governance and lineage must evolve beyond batch assumptions.

We'll show how Lakehouse-native streaming integrates with Iceberg V3 and REST catalogs to bring fine-grained governance to continuously ingested data. The centerpiece is row-level lineage: understanding not just which table data came from, but which specific records and transformations produced it, even as data arrives continuously. We'll also cover schema evolution patterns for streaming sources -- where schemas change without warning and pipelines can't just stop and restart.

The talk introduces a Bring Your Own Lineage (BYOL) model: how to integrate your preferred lineage systems alongside your catalog without disrupting streaming pipelines. This session shows how Iceberg V3, catalog governance, and Lakehouse-native streaming deliver trustworthy, auditable data from the moment it's ingested.

Apache Iceberg™ requires a catalog to discover and interact with Iceberg tables and ensure consistency across writers. But with so many catalog implementations out there, how do you choose?.

In this session, we’ll herd the cat(alogue)s for you and break down the Iceberg catalog landscape. We’ll begin with why catalogs are essential and their general requirements. From there, we’ll look at the advent of the REST catalog and its impact on Iceberg’s ecosystem. Finally, we’ll survey some of the most widely used Iceberg catalogs—like HIVE, JDBC, Nessie, Snowflake, Apache Polaris™ and more—to see their metadata storage approaches, table discovery mechanisms, and integration with both open-source and commercial platforms. Along the way, we’ll highlight the strengths, trade-offs, and key considerations for each.

By the end of this session, you’ll have a clear understanding of how Iceberg catalogs function, what differentiates them, and how to select the best one for your needs.

As on-prem lakehouses scale to billions of objects, a new bottleneck emerges: Data Lifecycle Velocity. In platforms powered by Apache Iceberg and Delta Lake, frequent snapshot expiration, compaction, and medallion pipelines generate massive transient data.

In a petabyte scale deployment on Apache Ozone, deletion throughput could not keep pace with ingestion causing storage growth, metadata bloat, and rising query latency.

This session shares our production journey fixing this bottleneck. We trace deletes across Ozone's 3 tier architecture , expose scaling limits, and present optimizations that delivered a 33x improvement in deletion throughput via parallel traversal, refined locking, and snapshot aware GC. We also show how Apache Ozone Recon + Grafana enabled real time visibility into deletion backlogs.

Key Takeaways:

1. Ozone deletion pipeline internals.
2. Scaling garbage collection in production.
3. Snapshot safe reclamation strategies.
4. End to end observability.
5. Lessons learned from production.

We are living through the "Iceberg Era." If you listen to any data architect today, the conversation is dominated by table formats. We have become obsessed with the "House"—perfecting ACID transactions, governance, and structured schemas.

But while we decorate the House, the Lake is rising.

By 2035, the world faces a 2 Yottabyte Shock. 75% of that data—roughly 1.5 billion petabytes—will be the "Nebula": unstructured images, PDFs, sensor logs, and video. Today, our Lakehouse architectures treat the Nebula as "dark data" or storage exhaust, hidden behind brittle S3 paths and messy IAM policies.

This lightning talk argues that a Lakehouse that only manages tables isn't a Lakehouse—it's just a scalable warehouse built on cheap storage. We will explore the three fundamental gaps (Access, Context, and Standards) failing our unstructured data and propose a move toward Managed Volumes. It’s time to stop treating 75% of the world's data as a second-class citizen and start engineering the Lake for an AI-driven, yottabyte-scale future.

Imagine being able to see every change made to your database, no matter how long ago, not just for days or weeks, but for years.

Change Data Capture (CDC) has become a fundamental element of contemporary data architectures. Most CDC data integration tools enforce primary keys from source tables on target lakehouse tables resulting in limited retention of the change trail that makes CDC valuable. The keyed tables approach is unable to cope with the demands of long-lived retention as metadata files balloon, query planning slows, and operational overhead becomes unsustainable.

In this talk, we present a different approach developed at Yelp. Using Flink CDC, we stream row-level changes from MySQL into an append-only lakehouse table powered by Apache Paimon, which is purpose-built for streaming workloads. Out-of-the-box Flink CDC does not support append-only lakehouse tables. We addressed this gap via FLINK-38413. By treating every insert, update, and delete as a first-class, immutable event, we preserve the complete history of data indefinitely without the large metadata overhead.

At LinkedIn, we ingest 4k+ tables (~2PB total logical size) from online databases into our data lake, processing billions of CDC upserts daily for analytics & AI/ML workloads.

This talk covers practical tradeoffs between streaming ingestion (eq deletes) & batch merge-pattern (pos deletes) for encoding upserts at scale. We'll share how we optimized read performance for high-churn tables processing hundreds of millions of daily upserts—through frequent delete-file compaction, periodic rewrites & tunings.

We'll discuss real-world challenges: high HDFS read I/O amplification, conflicts between concurrent merge & compaction jobs & balancing data freshness against rewrite costs/runtime via budgeted data compaction built in LinkedIn.

We'll also cover leveraging Iceberg's Write-Audit-Publish (WAP) branching for zero-downtime full table rebootstraps & how merge-pattern building validation tooling to ensure consistency between source databases & Iceberg tables.

Attendees will leave with actionable optimizations & battle-tested lessons from operating CDC pipelines on Iceberg at LinkedIn scale.

Modern lakehouse engines push performance through native execution layers such as Velox and Apache Gluten, but achieving high performance often introduces subtle correctness challenges.

This talk explores the tradeoffs between correctness and performance in native lakehouse execution. Using real examples, we examine issues such as ANSI vs non-ANSI behavior, null semantics, type coercion, and function parity when accelerating queries beyond traditional Spark execution.

We highlight lessons learned from integrating native engines, including where performance optimizations diverge from expected semantics, how to detect these gaps, and strategies for maintaining correctness without sacrificing performance.

The session provides a practical perspective on building and evaluating high-performance lakehouse systems, focusing on the engineering realities behind modern execution engines.

The "Delta to Iceberg" bridge has long been a vital piece of the ecosystem, but as table formats evolve, maintaining seamless compatibility feels like hitting a moving target. Apache Iceberg with V3 Spec it gets compability with Delta Lake Tables.

In this session, I will explore the technical journey of building a robust bridge between Delta Lake v3-7 and the cutting-edge Apache Iceberg Spec v3. Instead of relying on costly and time-consuming "Create Table As Select" (CTAS) operations, we focus on high-efficiency, zero-copy metadata conversion.

I will break down the architectural challenges of mapping incompatible metadata layers while keeping underlying data files untouched, ensuring a fast and storage-optimized migration. Attendees will see the new tooling in action through a live demo and gain insights from a real-world production case study.

Whether you are planning a migration or curious about the internals of Iceberg v3, you will walk away with a blueprint for transitioning to a modern data stack without the migration tax.

Open table formats such as Apache Iceberg have made data portable across engines, but governance architectures must also remain extensible as ecosystems evolve. Durable lakehouse governance requires clear separation between table formats, catalog control planes, and policy engines so that each can evolve independently.

This talk explores how Apache Iceberg and Apache Polaris illustrate this layered design in practice. We discuss why Iceberg intentionally avoids embedding governance in table metadata, how Polaris serves as an enforcement point for access and operations, and how pluggable interfaces enable integration with existing policy systems.

Using these examples, we examine how separation of concerns helps build data governance systems that are composable, interoperable, and adaptable, and why these architectural boundaries matter when evolving governance capabilities across open table formats and catalog interfaces.

Iceberg gave us a great foundation for durable, replayable analytics data. The problem started when we needed the same datasets to satisfy very different access patterns: dashboards and joins that need sub-seconds latency, alongside large historical scans. We could make either case work in isolation, but not both reliably without introducing a hot tier and a clear boundary.

This talk covers how we evolved to a tiered design where StarRocks serves the hot tier natively and federates into Iceberg for cold history. We’ll briefly explain how StarRocks’ Iceberg integration behaves (planning/metadata work, pushdown, caching), why federation helps but isn’t free, and how we model tier boundaries in dbt so consumers see one dataset. Finally, we’ll show how we operationalized the architecture with Airflow workflows that route datasets into Iceberg or StarRocks based on workload pattern and freshness SLA, plus the optimizations that made performance predictable.

What are you trying to tell me? That I can read data fast? No, User. I’m trying to tell you that when you are ready, you won’t have to.

Everyone’s heard about how fast Apache Iceberg and maybe you’ve even heard a few notes about “predicate pushdown” and “file metrics” but you’ve been left wanting more. You want to know the nitty gritty of how a predicate from a query engine is actually transformed and applied to Iceberg metadata. In this talk we will show you just that, we’ll work through the actual code of the Iceberg project showing how the metadata is read, how predicates are transformed, and finally how file tasks are actually broken up and sent to execution engines. We’ll talk in detail about all of the properties which control Iceberg planning and see the classes in which those parameters actually take effect. This is definitely more detail than any user of an Apache Iceberg table would actually need to know, but don’t you want to know?

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 simplifies real-time architecture, and where this new paradigm is headed

This talk explores how CloudNativePG-managed PostgreSQL clusters serve as the "last mile" serving layer in Lakehouse architectures.

We'll examine three integration patterns:

"Shared Object Storage"

Lakehouses (Delta Lake, Iceberg, Hudi) and CloudNativePG backups/WAL archiving share S3-compatible storage, enabling unified policies, security models, and simplified operations.

"Foreign Data Wrappers"

PostgreSQL's FDW enables direct queries against Parquet files and Lakehouse tables, joining hot operational data with cold analytical data without complex ETL.

"pgvector for Embedding Retrieval"

Lakehouses process unstructured data into embeddings via Spark or Flink. CloudNativePG's pgvector support provides the high-performance retrieval layer, completing the pipeline to millisecond-latency similarity search.

Attendees will leave with architectural patterns for deploying CloudNativePG as the bridge between batch-processed Lakehouse data and real-time applications.

Open table formats like Apache Iceberg, Apache Hudi, and Delta Lake have transformed modern data platforms by separating storage from compute and enabling multiple engines to operate on the same data. In this architecture, the catalog layer became the control plane for the open lakehouse—standardizing how engines discover tables and metadata.

However, lakehouses still primarily expose tables and SQL. While this works for analysts, newer consumers—applications, data agents, and AI-native systems—need semantic context such as entities, relationships, and shared metric definitions.

Today this logic is scattered across tools and pipelines. This raises a key question:

The catalog standardized how lakehouses discover tables. Should it also define what those tables mean?

In this talk, we explore architectural options for introducing semantics into the lakehouse:

• BI-centric semantics
• Pipeline-centric semantics
• Engine-centric semantics
• Catalog-centric semantics
• Service-based semantics

and discuss the trade-offs for governance, interoperability, and multi-engine environments.

Apache Iceberg, an open table format, has emerged as a critical component in modern lakehouse architectures, but operating it at enterprise scale surfaces challenges that span infrastructure, performance, and security. This presentation shares practical lessons applicable to any organization investing in the lakehouse pattern.

This talk covers three areas common to production Iceberg environments: infrastructure evolution, performance engineering and enterprise requirements.

Attendees will walk away with a practical understanding of how to evolve their catalog infrastructure, tune Parquet and Spark configurations for real-world Iceberg workloads, and approach encryption and audit requirements in lakehouse environments. We will also discuss how observability and metrics collection lay the foundation for ML-driven query optimization.

Machine learning and feature engineering workloads often rely on very wide tables where columns are frequently updated or added. In Apache Iceberg today, even small column changes require full file or full table rewrites, leading to unnecessary I/O and cost.

This talk explores approaches for efficient column updates in Iceberg, where only the modified columns are written instead of rewriting entire data files. We then look ahead to column families, a complementary concept that vertically splits wide tables to address issues like unbalanced row groups, large blob columns dominating storage, and suboptimal compression and read performance.

Together, these ideas aim to make Iceberg a better foundation for scalable feature evolution in Lakehouse architectures.

Apache Iceberg's commitment to interoperability and vendor neutrality means users often explore new cloud environments and diverse catalog implementations. As the ecosystem matures, seamlessly migrating existing tables and views becomes essential. This talk covers bulk migration of Iceberg assets between catalogs and storage locations without duplicating data.

The session begins with migration motivations, then dives into core APIs like `registerTable` and the recently proposed `registerView`. It focuses on challenges of large-scale migrations and features a "CLI tool" from the Apache Polaris community that streamlines metadata transfer through a live demo. Finally, it explores Spark’s `rewrite_table_path procedure` for moving data across storage providers while keeping metadata synced and data immutable.

Attendees will gain a practical framework for automated migrations and understand how Iceberg’s design enables seamless, vendor-neutral transitions.

As AI pipelines demand data across the full type spectrum — from structured tables and JSON logs to vector embeddings — the open lakehouse must evolve beyond traditional analytics.

This talk explores how Apache Doris serves as a multi-modal analytics layer on Apache Paimon and Apache Iceberg, covering three capabilities:

• Structured: High-performance MPP SQL on Paimon and Iceberg with native Deletion Vector and real-time streaming update support.
• Semi-structured: The VARIANT type delivers schema-free JSON analytics in a columnar engine — ideal for observability and event-driven AI workloads.
• Vectors & unstructured: Native HNSW/IVF indexing and hybrid search unify structured filters, full-text retrieval, and ANN similarity in a single SQL query — enabling RAG and semantic search directly on lakehouse data.

Attendees will learn how one open-source engine bridges the full data spectrum to make the lakehouse AI-ready — without added infrastructure complexity.

What if one Iceberg table could power your entire analytics stack—from interactive queries in DuckDB to batch processing in Spark, ad-hoc exploration in Trino, and real-time dashboards in StarRocks?

This talk explores how Apache Iceberg enables true multi-engine interoperability through its open table format, catalog decoupling, and rich metadata model. We’ll cover practical patterns for building a shared data layer across diverse engines without sacrificing consistency, flexibility, or performance.

We’ll also discuss how QueryFlux, our open-source multi-engine query router, helps turn this model into something operational by routing queries to the right engine based on workload type and execution needs.

Whether you’re modernizing a warehouse or building a new lakehouse, this session shows how to write once, govern once, and query everywhere.

This breakout session offers an engineering-focused look behind the curtain of how STACKIT designed, built, and operates a Lakehouse as a Service offering on top of OSS projects such as Kubernetes, Apache Iceberg, NATS, ZooKeeper, and others.

Topics that will be touched:

• OSS at the Core: Insights into the general setup of the service and how open-source projects like Apache Iceberg, Kubernetes and others play a central role.
• Order to Deployment: Technical walkthrough from API interaction and resource provisioning in the cluster to the automated setup using self-written Kubernetes Operators.
• Engineering Hurdles and Solutions: Details about the most significant challenges we faced.
• Operationalizing the Service: Context for engineering decisions we made, things that went wrong, and a focus on the critical operational aspects.

Attendees will gain practical and relatable insights into the complexities of platform engineering for data infrastructure from our experience in bringing a demanding, cutting-edge data service to market as a managed offering

Apache Iceberg's metadata layer is what makes schema evolution, partition evolution, and predicate pushdown possible . But at petabyte scale, that metadata itself can balloon to hundreds of gigabytes or more. When planning slows down the execution, something has to give.

This talk explores how Iceberg's metadata is structured through manifests, partition summaries, and column-level metrics, and why each layer exists to enable fast analytical queries. We'll then walk through Iceberg's native APIs, procedures and practical strategies for applying them to keep metadata size in check at scale. Finally, we'll preview proposals in the Iceberg v4 spec that aim to make metadata more compact and scalable by default.

You'll walk away with a clear picture of where all those gigabytes of metadata actually come from, a playbook for keeping them in check in an iceberg's own way, and enough context on the v4 spec to start contributing and where the format heads next.

Apache Impala is a hybrid, massively parallel query engine: its query planning and metadata handling are implemented in Java, while its execution engine is written in C++. This architecture presents unique challenges when integrating Apache Iceberg, whose reference implementation and ecosystem are primarily Java-based. Attendees will gain insight into the practical challenges of bringing Iceberg to non-JVM query engines.

We will explore how Iceberg features are implemented in a distributed C++ query engine, and where Impala can reuse existing Iceberg libraries versus where custom implementations are required. We will dive into concrete examples, including metadata handling and row-level operations. The session will also highlight opportunities this model creates, such as rethinking how merge-on-read is implemented.

Finally, attendees will also learn about the current state of Iceberg support in Impala and how our progress is going toward adopting Iceberg V3.

AI agents fail in production because they're overwhelmed with data but starved for context. LLM models aren’t the problem. The bottleneck is the data stack: fragmented silos, inconsistent definitions, and logic hidden in tribal knowledge. Agents need structured, reliable, and interpretable context—not just data access.

In this session, we'll show how Apache Iceberg becomes the backbone of AI-ready pipelines. You’ll learn how to elevate your Iceberg implementation from a storage format to a live context layer that powers structured retrieval-augmented generation (RAG), schema-aware agents, and autonomous reasoning grounded in truth.

What we’ll cover:

1. Iceberg Foundations for AI - from ACID to Time Travel
2. From Rows to Relationships - The role of the semantic layer
3. Structured RAG in Practice - Fully open source

The session includes a live demo of a fully open-source Structured RAG stack built on Apache Iceberg, featuring semantic query translation, hybrid retrieval, and governed agent reasoning. Expect architecture diagrams, real code, and practical guidance.

The open lakehouse has become the dominant architecture for modern data platforms, but it's still evolving fast. Table formats, catalogs, storage layers, and compute engines are all advancing independently, and the people building these projects don't always get the chance to sit down together and talk about where it's all headed.

This panel brings together leaders and committers from across the lakehouse ecosystem to discuss what comes next. What hard problems remain unsolved? Where do the boundaries between formats, catalogs, and compute need to shift? How should these projects evolve to support emerging workloads like AI/ML, real-time analytics, and agentic data access? And where should the community focus its energy to have the greatest impact?

=

Whether you're a contributor to one of these projects or an engineer building on top of them, this session offers a rare cross-project conversation about the future of the open lakehouse that's grounded in the perspectives of the people actually doing the work.