Data lakes and data warehouses solve different problems. Lakes store raw data cheaply in its native format, and warehouses serve curated data fast. How you use them individually or together impacts what your analytics team can do, and the scale of modern data makes this choice even more consequential. In 2024, 402.89 million terabytes of data were created, captured, copied, or consumed each day, adding up to approximately 147 zettabytes a year.

Below, we’ll compare data lakes versus data warehouses, explain where they differ on schema, cost, performance, and governance, and how to match the right architecture to your workloads.

Highlights

• Data lakes use schema-on-read to store raw data flexibly, while data warehouses use schema-on-write to deliver fast, consistent query performance for business intelligence (BI) and reporting.

• Mature data teams generally use both systems in a layered architecture, with raw data landing in a lake and curated data flowing into a warehouse for analytics.

• The legacy payment data approach of building your own pipeline tends to be fragile since API schema changes can break pipelines.

What is a data lake?

A data lake is a centralised repository that stores data in its raw, native format. That includes structured data (tables), semi-structured data such as JavaScript Object Notation (JSON) logs, and unstructured data (text, images, video).

The defining ideal behind a data lake is schema-on-read. Data lands exactly as it’s produced, and structure is applied later at query time, when someone knows the question they’re trying to answer. That flexibility makes lakes well-suited for large-scale ingestion and exploratory analysis. You can store virtually anything without deciding in advance how to model it.

What is a data warehouse?

A data warehouse is a structured analytics system designed for fast, consistent querying.

Before data lands in a warehouse, it’s typically cleaned, transformed, and modeled into well-defined schemes optimised for analysis. This approach is known as schema-on-write: the structure and definitions are determined before the data is stored. The result is a curated environment where analysts can run queries, build dashboards, and calculate metrics without worrying about inconsistent formats or missing context.

While a data lake prioritises flexibility, a data warehouse prioritises reliability and performance for analytics.

What are the key differences between a data lake vs. a data warehouse?

The practical differences between lakes and warehouses go far beyond where data is stored. How they’re structured, who can use them, and what it costs to query are also key distinctions.

Structure

Data lakes store raw data and apply structure only when queries run. That flexibility allows for multiple interpretations of the same dataset. Data warehouses enforce structure when data is written, so everyone who queries the orders sees the same schema and definitions.

Query performance

Warehouses are built for interactive analytics. Queries against large tables in systems such as Snowflake or BigQuery can return in seconds. Querying raw files in lake storage can be slower and more expensive unless you’ve invested in optimisations such as columnar storage, partitioning, and compaction.

Data types

Warehouses excel at structured, relational data that’s used in reporting and dashboards. Data lakes are more accommodating: they can store raw logs, nested JSON, machine-learning datasets, images, and other non-relational formats.

Governance and trust

Warehouse data usually passes through validation and transformation pipelines, which makes it suitable for business reporting. Data in a lake is often raw and exploratory, so additional processing is usually required before it can support production metrics.

Cost profile

Data lakes are much cheaper for storing large volumes of raw or infrequently accessed data. Warehouses cost more per terabyte but provide faster query performance and better support for high-concurrency analytics workloads.

How do organizations use data lakes and data warehouses together?

Mature platforms tend to use both systems, with each handling the part of the pipeline for which it’s best suited. Typically, a data lake acts as the landing zone for raw data, while the warehouse serves curated, analytics-ready datasets to analysts and business tools.

A common pattern is medallion architecture, which includes:

• Bronze: Raw ingested data

• Silver: Cleaned and deduplicated datasets

• Gold: Aggregated, business-ready tables used for reporting

In many implementations, bronze and silver data live in lake storage, while gold datasets are served from a warehouse.

The downside of this layered architecture is its difficulty. Data gets duplicated across systems, pipelines move and transform it, and teams need to manage governance and access controls in multiple places. Organizations are simplifying this by experimenting with lakehouse architectures built on technologies such as Delta Lake, Apache Iceberg, or Hudi. These systems add features traditionally associated with warehouses, such as atomicity, consistency, isolation, and durability (ACID) transactions and schema enforcement, which direct to lake storage.

This allows teams to use one platform instead of two. How well it works will depend on query complexity and the maturity of the team that operates it.

How do you choose between a data lake and a data warehouse?

The right answer depends on who’s using the data and what they need from it. Generally, organisations have multiple teams with different requirements.

Here's what to consider:

Business intelligence (BI) and reporting teams

If your primary consumers are analysts building dashboards in tools such as Looker, Tableau, or Metabase, a data warehouse is usually the best foundation. These tools depend on consistent schemas, reliable metrics, and fast query responses.

Data science and machine learning teams

Training models often require raw, high-volume datasets, such as event streams, text, behavioural logs, or other complex formats. Data lakes provide the flexibility to store and explore that data before it’s shaped into structured tables.

Engineering teams that ingest data at scale

When systems generate billions of events each day, a lake is usually the most practical first destination. It’s cheaper, handles evolving schemas well, and doesn’t require upstream systems to conform to a predefined data model.

Mixed workloads

Organisations tend to combine the two: a lake for ingestion and storing raw data, a warehouse for serving curated datasets, and a transformation layer that connects the two. In this type of setup, the question is where each system fits within the overall data pipeline.

How does a payments provider fit into your data lake or data warehouse architecture?

The legacy approach to payment data is to build your own pipeline using an application programming interface (API) to handle pagination and rate limits, write the results to storage, and maintain the integration indefinitely.

That works, but it’s fragile. API schema changes can break pipelines, historical backfills require additional logic, and payment data includes sensitive financial information. That means that routing it through additional third-party extract, transform, and load (ETL) vendors creates security exposure that many finance and compliance teams aren’t comfortable with.

The Stripe Data Pipeline directly addresses these challenges. A native connector built and maintained by Stripe, it’s available to existing Stripe users and works by syncing Stripe data (transactions, customers, subscriptions, payouts) directly to a data warehouse or cloud storage destination.

Compared with third-party connectors, the native approach has a few advantages:

• Data completeness: Stripe Data Pipeline includes historical data from your account, prebuilt financial reports and curated datasets that third-party connectors often don’t expose or require custom configuration to surface.

• Reliability at scale: Because the pipeline is maintained by Stripe itself, it automatically tracks API changes, handles schema evolution, and accounts for edge cases in Stripe’s data model that external connectors sometimes miss.

• Reduced security exposure: Financial transaction data moves between Stripe and your storage destination without passing through an intermediate vendor’s infrastructure, which simplifies your data security posture.

How Stripe Data Pipeline can help

Stripe Data Pipeline allows you to do the same analysis in your data warehouse by combining your Stripe data with other business data. Stripe Data Pipeline and Stripe Sigma are both powered by the same underlying Stripe data, but Data Pipeline makes it easy to view that data in combination with other datasets.

Stripe Data Pipeline can help you:

• Sync directly to your warehouse
  Data moves to Amazon Redshift, Snowflake, or Amazon S3 without routing through a third-party connector, which keeps sensitive financial data out of additional vendor infrastructure.

• Establish a single source of truth
  Centralise your Stripe data in one place to speed up your financial close, identify top payment methods, enhance AI models and more.

• Get set up with no code
  The connection is configured in the Stripe Dashboard, with no code required. Set up Stripe Data Pipeline in minutes and automatically receive your Stripe data and reports in your data storage destination on an ongoing basis.

Learn more about how Stripe Data Pipeline can help you unlock your business data.