What Is a Data Warehouse? How Data Warehousing Has Evolved

In 2022, I published an article on Built In explaining data warehousing. I defined a data warehouse as follows:

That definition still captures the central purpose of a data warehouse: bringing data together and preparing it so an organisation can understand its performance and make informed decisions.

However, the definition now feels incomplete.

The phrase “periodically archiving” suggests that data arrives mainly through scheduled batch processes. “For business intelligence purposes” positions the warehouse primarily as a source for reports and dashboards.

Both were reasonable ways to explain data warehousing. Today, however, platforms such as BigQuery support a much wider data lifecycle. They help teams ingest, transform, test, document, govern and analyse data. They can also support machine learning, AI applications and continuously updated operational use cases.

The data warehouse has not stopped being a place for current and historical information. It has expanded from an analytical destination into a broader data platform.

A data warehouse is a system that integrates information from multiple sources and organises it for analysis.

It normally contains both current and historical data, allowing an organisation to study changes over time. A warehouse might combine customer records, website events, product information, advertising data, sales transactions and financial results.

Instead of examining these sources independently, the organisation can use the warehouse to answer questions that cross several systems:

Oracle describes a data warehouse as a system designed to support business intelligence and analytics by consolidating information from many sources. Qlik similarly emphasises unified historical data, but extends its uses to data analysis, artificial intelligence and machine learning.

The defining value of the warehouse remains consistent: it turns fragmented operational data into information that people can understand and trust.

The technology has evolved, but several fundamental characteristics remain important.

Information from different systems rarely arrives in a consistent format. Two applications might use different customer identifiers, currencies, date formats or definitions of revenue.

A warehouse provides a place to reconcile those differences and create common business definitions.

Operational applications usually focus on the latest state of a transaction. A warehouse preserves changes over time.

Historical records allow teams to compare periods, identify trends, measure the effect of decisions and train forecasting models.

A transactional database is designed to record activities such as purchases, payments and account updates. A warehouse is designed to analyse large groups of records.

Separating these workloads allows organisations to run complex analytical queries without placing unnecessary pressure on the systems that operate their products.

A powerful warehouse cannot repair an unclear business definition automatically. If two teams calculate active customers differently, moving their data into the same platform will not make the disagreement disappear.

A warehouse still needs ownership, documentation, testing and agreed definitions.

It would be inaccurate to describe the change since 2022 as a transition from traditional on-premises warehouses to modern cloud warehouses.

Cloud data warehouses were already firmly established. BigQuery was already serverless and scalable, with separate storage and computing layers. Teams were using it for SQL analysis, ELT, business intelligence, streaming workloads and machine learning.

The more useful comparison is:

Around 2021 and 2022, BigQuery frequently acted as the central analytical database within a larger collection of tools. Data ingestion, transformation, workflow orchestration, data quality, documentation and governance could involve custom pipelines or separate products.

Those external tools have not disappeared. What has changed is how many of these responsibilities are now available within, or closely integrated with, the warehouse ecosystem.

Google currently describes BigQuery as an “AI-ready data platform,” rather than only as a cloud data warehouse. That positioning reflects the expansion of its role.

The evolution is cumulative. Many modern capabilities existed in some form several years ago. They have since become more integrated, accessible and central to how data warehouse platforms are designed and presented.

A data warehouse was often described as the final destination of a data pipeline.

Data was extracted from operational systems, cleaned and transformed, loaded into the warehouse and then accessed through a business intelligence tool.

That sequence still exists, but it no longer captures the whole platform.

A modern BigQuery environment can participate in several parts of the data lifecycle:

The warehouse is no longer only where the pipeline ends. It is also where a growing amount of data engineering, governance and analysis happens.

A warehouse is only useful when data can reach it reliably.

Several years ago, teams commonly relied on custom pipelines or dedicated integration products to extract data from their applications. Those approaches remain valuable, especially for complex requirements, but warehouse platforms now provide more managed ingestion options.

The BigQuery Data Transfer Service automates scheduled data movement into BigQuery. Its supported sources span Google services, SaaS platforms, marketing systems, operational databases, other data warehouses and cloud storage.

Scheduled transfers are only one option. A contemporary BigQuery architecture can use:

This makes “periodically archiving data” only one part of modern data warehousing.

Some datasets still arrive once a day or once a month. Others are continuously updated. In some cases, the data does not need to be moved into the warehouse before it can be queried.

The traditional ETL sequence is extract, transform and load. Data is prepared before it reaches the warehouse.

Cloud computing encouraged greater use of ELT: extract, load and transform. Teams load data first and use the warehouse’s computing engine to transform it.

ELT was already well established by 2022. The newer development is not the invention of ELT, but the availability of more integrated tools for managing transformation workflows.

Dataform allows analysts and engineers to develop, test, document, version and schedule SQL transformations in BigQuery.

With Dataform, a team can:

This treats SQL transformations more like software.

Consider a revenue table used by senior leaders. Without a managed workflow, its logic might live in a long scheduled query understood by one analyst. If that query changes, the team may struggle to see who changed it, why it changed or which reports depend on it.

With a managed transformation project, the logic can be reviewed, tested, documented and traced through its dependencies.

The warehouse is therefore becoming more than the engine that executes SQL. It is part of a development environment for producing trusted analytical data.

Reports and dashboards remain central data warehouse use cases. They help teams monitor sales, understand customers and measure business performance.

Modern warehouses also support a broader group of users and workloads.

Databricks includes reporting, analytics, data applications and machine learning preparation among current data warehouse uses. BigQuery provides integrated capabilities for machine learning, geospatial analysis, search, notebooks and Python-based workflows.

The same governed dataset might now support:

For example, a table containing customer orders might feed a finance dashboard, help train a demand forecast and provide context to an AI assistant.

The warehouse has become a shared foundation for decisions, models and applications—not only visual reports.

Traditional data warehouses were associated with structured, carefully modelled data. Data lakes provided inexpensive storage for raw, semi-structured and unstructured information.

This created a relatively simple distinction:

The distinction has become less rigid.

The lakehouse model combines the flexibility of data-lake storage with capabilities associated with data warehouses, including reliable tables, governance and analytical performance. Databricks presents the lakehouse as an evolution of the traditional warehouse architecture.

Warehouse platforms have moved in the other direction by supporting more data types and external storage patterns. BigQuery can work with structured and unstructured data and supports open table formats such as Apache Iceberg, Delta and Apache Hudi.

It can also query some data stored in Cloud Storage, operational databases, Google Sheets and other external sources.

This does not make every warehouse a lakehouse or remove the architectural differences between them. It does mean that organisations have more flexibility over where data is stored and how it is accessed.

The important question is no longer simply whether an organisation needs a warehouse or a lake. The better question is how different users and workloads can access reliable data without unnecessary movement, duplication or complexity.

As the warehouse supports more data and more users, discovering and understanding that data becomes harder.

A table name alone rarely explains:

Modern platforms increasingly address these questions through integrated governance capabilities.

BigQuery currently includes features for metadata management, discovery, lineage, data quality and controlled sharing. Dataform complements these capabilities by documenting transformations, declaring dependencies and testing datasets.

Governance is not only about restricting access. It helps people decide whether a dataset is appropriate for a particular analysis.

As the warehouse becomes easier to populate, this context becomes more important. More data does not automatically produce more useful information. Without ownership and documentation, a warehouse can become a collection of tables that people are afraid to use.

This comparison does not imply that every organisation uses all these capabilities. Nor does it mean they appeared overnight.

It shows that the expected scope of a data warehouse has expanded.

A modern BigQuery environment might operate as follows:

In this architecture, BigQuery is not simply the database at step four. It participates in data movement, transformation, governance, analysis and delivery.

Greater integration can reduce manual work, but it does not eliminate the risks associated with data warehousing.

Source systems can still send incomplete or incorrect information. Schema changes can still break pipelines. A transformation can run successfully while applying the wrong business logic.

Modern platforms also introduce new concerns:

Tools such as Dataform, metadata catalogues and data quality tests help teams manage these problems. They do not replace careful engineering or communication between technical teams and business stakeholders.

The quality of a warehouse still depends on the quality of the decisions behind it.

My 2022 definition focused on storage, historical information and business intelligence:

The essence of that definition remains valid. I would now expand it:

Under this updated definition, data warehousing is not only the periodic archiving and reshaping of data. It is the ongoing practice of moving, modelling, testing, documenting, governing and serving data across an organisation.

The data warehouse still helps a business look back. It preserves history, supports reporting and provides consistent measures of performance. What has evolved is its reach. A modern warehouse can also help an organisation understand what is happening now, predict what may happen next and build products that act on those insights.