What is a data lakehouse architecture?

A data lakehouse is a unified data platform that combines the cheap, flexible storage of a data lake with the structured query performance and governance of a data warehouse. Instead of maintaining two separate systems, a lakehouse stores raw data in open file formats on object storage and adds a metadata and transaction layer on top. This means you can run both analytical SQL queries and machine learning workloads from a single source of truth. Below, we work through the key questions teams ask when evaluating this architecture, how it compares to older approaches, what it’s good at, and how it fits modern deployment patterns like Kubernetes and data mesh.

At the end, we cover how the Stackable Data Platform (SDP) supports open source lakehouse deployments specifically.

How does a data lakehouse combine a data lake and a data warehouse?

A lakehouse stores data in open formats on cheap, scalable object storage, then layers structured metadata, ACID transactions, and a query engine on top. You get the storage economics and schema flexibility of a lake alongside the reliability and performance that analysts expect from a warehouse, without duplicating data across two systems.

The key mechanism is an open table format like Apache Iceberg or Delta Lake. These formats sit between raw storage and the query layer, tracking which files belong to which table version, enforcing schema evolution rules, and enabling transactional writes. Because the format is open and file-based, multiple engines can read from the same table, whether that’s a SQL analytics engine like Trino, a batch processing framework like Apache Spark™, or a streaming pipeline built on Apache Kafka®.

The result is a single storage tier that serves diverse workloads without the data movement and synchronization overhead that comes with keeping a lake and a warehouse running in parallel.

What are the key components of a data lakehouse architecture?

A lakehouse is built from four layers that work together: object storage, an open table format, a catalog, and one or more query or processing engines. Each layer has a clear responsibility, and because every component uses open standards, the layers are independently replaceable.

Object storage: The foundation, typically S3-compatible storage, holds data as Parquet or ORC files. It’s inexpensive, highly durable, and decoupled from compute.
Open table format: Apache Iceberg or a comparable format adds table semantics, ACID transactions, time travel, and schema evolution on top of raw files.
Metadata catalog: A catalog like Apache Hive™ Metastore tracks table definitions, partitions, and statistics so query engines can plan efficiently.
Query and processing engines: Tools like Trino handle interactive SQL, while Apache Spark™ handles large-scale batch transformation and machine learning pipelines. Both read from the same underlying storage layer.

Governance and access control are often treated as a fifth layer, covering role-based permissions, data masking, and audit logging. In practice, these are implemented at the catalog and engine level rather than as a separate physical component.

What’s the difference between a data lakehouse and a data lake?

The core difference comes down to structure and reliability. A data lake stores raw files in object storage with minimal schema enforcement. Ingestion is fast, but querying is inconsistent and governance is hard. A lakehouse adds a transactional metadata layer on top of that same storage, bringing ACID guarantees, schema enforcement, and query optimization, without giving up the lake’s storage flexibility.

In practice, data lakes tend to accumulate what teams sometimes call “data swamps”: large volumes of files with unclear provenance, inconsistent formats, and no reliable way to track changes or roll back bad writes. The lakehouse table format addresses this directly. Every write is tracked, every schema change is versioned, and you can query historical snapshots of a table without maintaining separate backup copies.

Query performance is another real difference. A raw data lake requires significant engineering effort to partition data correctly and maintain file-size hygiene. A lakehouse table format handles much of this automatically through compaction, statistics collection, and partition pruning, so query engines spend less time scanning irrelevant data.

What’s the difference between a data lakehouse and a data warehouse?

The key difference is where data lives and who controls it. A data warehouse stores processed, structured data in a proprietary internal format managed by the warehouse engine itself. A lakehouse stores data in open file formats on object storage that you own, with the query engine reading from those files rather than managing its own storage layer.

This distinction has several practical consequences:

Cost: Object storage is significantly cheaper than managed warehouse storage, and compute can be scaled independently.
Flexibility: Because data is in open formats, you’re not tied to a single vendor’s query engine. You can switch or add engines without migrating data.
Workload coverage: Traditional warehouses are optimized for structured SQL analytics. A lakehouse also handles semi-structured data, unstructured data, and machine learning workloads from the same storage layer.
Governance trade-offs: Mature data warehouses often have more polished built-in governance tooling. A lakehouse requires assembling governance capabilities from separate components, which adds configuration complexity.

For teams that need strict SQL performance on fully structured data and prefer a managed experience, a warehouse is still a reasonable choice. For teams that need to support multiple workload types, maintain data sovereignty, or avoid proprietary storage formats, a lakehouse architecture is generally the more flexible path.

What use cases is a data lakehouse best suited for?

A lakehouse works best for organizations that need to run multiple types of workloads, SQL analytics, batch processing, and machine learning, against a single, consistent dataset without duplicating storage. It fits particularly well where data volumes are large, data types are mixed, and long-term flexibility matters more than short-term convenience.

Specific use cases where a lakehouse performs well include:

Unified analytics and ML: Data scientists and analysts work from the same tables, eliminating the synchronization lag between a warehouse copy and a lake copy used for model training.
Regulated industries: Time travel and full audit history built into the table format support compliance requirements in financial services and healthcare without additional tooling.
Large-scale ETL pipelines: Apache Spark™ can write directly to Iceberg tables, making the lakehouse a natural landing zone for complex transformation workflows.
Event-driven architectures: Streaming data from Apache Kafka® can be landed in lakehouse tables incrementally, enabling near-real-time analytics without a separate stream processing store.
Multi-team data sharing: Open formats and a shared catalog allow different teams to read the same data with their preferred engine, reducing the need for data copies.

How does a data lakehouse support data mesh architectures?

A lakehouse gives data mesh architectures a solid technical foundation for domain-oriented data ownership. In a data mesh, individual teams own and publish their own data products. A lakehouse gives each domain a consistent, interoperable storage layer where they can manage their own tables in open formats, expose them through a shared catalog, and let other domains query them without transferring ownership or copying data.

The open table format is central to this. Because Apache Iceberg tables are engine-agnostic, a domain team can write data using Apache Spark™ while a consuming team queries it with Trino. The catalog acts as the contract layer, registering what data is available and in what schema, which aligns naturally with the data mesh concept of treating data as a product with a defined interface.

Governance in a mesh context is handled through policies applied at the catalog and engine level, supporting the federated computational governance principle that data mesh advocates. Each domain retains control over its own data while still making it discoverable and accessible to the broader organization.

You can see how these patterns come together in the SDP demo environments, which show data mesh and lakehouse setups running on Kubernetes.

How do you deploy a data lakehouse on Kubernetes?

Deploying a lakehouse on Kubernetes means running each component of the architecture, storage connectors, catalog, and query engines, as containerized workloads managed by the cluster. Kubernetes handles scheduling, scaling, and restarts, while operators or Helm charts manage the configuration of individual tools like Trino, Apache Spark™, and the Hive™ Metastore. The result is a reproducible, infrastructure-as-code deployment that runs consistently across on-premises clusters and any cloud provider.

A typical Kubernetes-based lakehouse deployment involves:

Object storage connectivity: Configure an S3-compatible endpoint, whether MinIO on-premises or a cloud bucket, that all components can reach.
Table format and catalog: Deploy a Hive™ Metastore or compatible catalog service to track Apache Iceberg table metadata.
Query engine: Deploy Trino as a distributed query service, pointing it at the catalog and object storage.
Processing engine: Deploy Apache Spark™ for batch and streaming ingestion jobs, writing data into Iceberg tables on the same storage layer.
Monitoring and access control: Integrate with Kubernetes-native observability and policy tools to enforce governance at the platform level.

The main operational challenge is keeping these components version-compatible and correctly configured as they evolve independently. This is where Kubernetes operators add real value: they encode the operational knowledge needed to run each tool correctly, handle upgrades, and surface health information through Kubernetes-native APIs.

How Stackable helps with data lakehouse architecture

The Stackable Data Platform (SDP) is a modular, Kubernetes-native platform that provides the components needed to run an open source data lakehouse without assembling them from scratch. Specifically, the SDP includes:

Operators for core lakehouse components: The SDP ships Kubernetes operators for Trino, Apache Spark™, Apache Kafka®, and Apache Hive™ Metastore, each encoding the operational knowledge needed to run that tool correctly on Kubernetes.
Apache Iceberg support: The platform is designed to work with Apache Iceberg as the open table format, enabling ACID transactions, schema evolution, and time travel on object storage you control.
Infrastructure as code: All configuration is declarative and version-controlled, making deployments reproducible across on-premises, cloud, and hybrid environments.
Data sovereignty by design: Because the SDP is 100% open source and cloud-agnostic, your data stays in your own storage layer in open formats, with no proprietary lock-in at any layer of the stack.
Federated governance support: The platform’s modular design aligns with data mesh principles, allowing domain teams to manage their own data products while sharing a common infrastructure layer.

If you’re evaluating a lakehouse deployment and want to understand how the SDP fits your specific setup, get in touch with the Stackable team to talk through your requirements.