In our high-level article, we explored the broader landscape of modern data architectures: Traditional Data Warehousing, Hybrid Data Warehousing, Data Lakehouse, Data Fabric, and Data Mesh. Today, we’re diving deep 🤿 into the one that started it all: Traditional Data Warehousing.
Quick Recap ↻
Traditional data warehousing follows a structured, schema-on-write approach. Data is ingested through ETL pipelines into a centralized data warehouse, often complemented by downstream data marts. This architecture ensures a Single Version of Truth (SVOT) by consolidating, transforming, and standardizing data before it’s used for analysis.
Designed for structured data in relational (often columnar) databases, this architecture supports historical analysis through slowly changing dimensions (SCDs). It emphasizes business needs, with dedicated ETL processes ensuring up-to-date and reliable data.
Why this architecture has been created ?
Before the explosion of cloud-native data platforms and schema-on-read paradigms, companies struggled with a common issue: operational systems were not designed for analytics. Running reports directly on operational systems slowed them down and produced inconsistent results (see why you can’t mix transactional and analytical).
The Traditional Data Warehouse (DWH) emerged to solve these problems. It offered a dedicated environment where data could be integrated, cleansed, standardized, and modeled according to business rules. More importantly, it enabled organizations to build a Single Version of the Truth (SVOT) — a reliable, unified view of enterprise data.
This architecture was often bundled as an all-in-one solution, combining ETL, storage, reporting, and dashboarding into a single package. Although today we decouple these components, the architectural logic remains influential.
A Brief History of Warehousing Philosophies
The classic DWH structure that we presented —with its staging, core, and presentation layers—is the result of decades of architectural evolution. It didn’t emerge overnight; it grew from a rich and sometimes conflicting history 🤼 of modeling philosophies, led by key figures like Bill Inmon VS Ralph Kimball.
For years, their approaches were debated and contrasted, until many organizations eventually landed on pragmatic hybrids that draw from both.
🥊 Contender n°1 : Bill Inmon
In his foundational book “Building the Data Warehouse” (1992), Bill Inmon introduced a top-down methodology where a fully normalized Enterprise Data Warehouse (EDW) is designed and implemented first. From this centralized repository, dependent data marts are created to support specific business functions. His approach emphasized consistency, data quality, and enterprise-wide integration.
Inmon’s thinking was deeply influenced by the technological constraints of the time. Storage was expensive, compute resources were limited, and in-memory processing was not viable. As such, redundant data was considered wasteful and impractical. That’s why Inmon championed normalized models and centralized control. In conjunction with OLAP cubes, this model helped reduce data duplication while supporting multi-dimensional analysis through pre-aggregated and indexed structures.
🥊 Contender n°2: Kimball (Bottom-Up)
Ralph Kimball proposed a contrasting, more agile approach in “The Data Warehouse Toolkit” (1996). He suggested building dimensional data marts directly based on business needs, using denormalized models like star ⭐ and snowflake ❄️ schemas. These marts could then be federated to form a virtual or logical warehouse.
By the time Kimball’s methodology took off, hardware costs had dropped significantly, and business demand for faster delivery of insights had increased. His model introduced intentional data redundancy as a trade-off for usability and speed. Rather than spending months designing a monolithic EDW, teams could deliver value incrementally, aligning each mart to a specific “data product”.
🏆 Winner : Real-World Hybrid
In practice, most organizations adopt a hybrid model, combining both philosophies. A normalized core layer (in 3nF-ish or in Data Vault) —🥊 often influenced by Inmon —is used to enforce consistency and governance, while dimensional marts—🥊 aligned with Kimball —deliver agility and business-aligned outputs.
Multi-Tenant vs Non-Tenant Warehousing
One common architectural decision in traditional data warehousing is whether to adopt a multi-tenant or non-tenant approach. This decision affects how data is isolated, modeled, and governed across BU/SUs, or geographic regions.
In a non-tenant (centralized) architecture, all data flows into a unified EDW, regardless of source or ownership. This model aligns with the vision of a true Enterprise Data Warehouse, where cross-domain analysis is possible and governance is centralized. It’s ideal for smaller organizations or highly integrated enterprises where business units share data models, definitions, and KPIs.
In contrast, a multi-tenant architecture separates data warehouses by tenant—often by BU, SU, country, or legal entity. Each tenant may have its own schema, ETL pipeline, and reporting logic. While this introduces data duplication and overhead, it improves autonomy, reduces interdependency, and reflects the reality of large, decentralized enterprises.
Today’s Technologies: Structured Data Warehousing
These tools are primarily aligned with traditional data warehousing patterns—centered on structured data, schema-on-write, and layered architecture. They support batch ETL and are optimized for BI workloads, often using SQL engines over columnar storage :
- SMP (limited scalability; no internode parallelism) : RDBMS with columnar support (e.g. PostgreSQL with citus)
- MPP (distributed storage & compute; optimized for large-scale structured queries):
- Cloud: BigQuery, Snowflake, Redshift, Azure Synapse
- On-prem (paid): Teradata, Oracle Exadata, IBM Db2, ParAccel, Vertica
- On-prem (open/free): ClickHouse, Greenplum
- Streaming oriented : Druid, ClickHouse, Rockset
To conclude, Is this architecture still relevant?
Traditional Data Warehousing remains in use today—particularly for structured data and business intelligence use cases. However, it is being adopted and promoted less frequently 📉, as it quickly shows its limitations when dealing with unstructured or semi-structured data.
This has paved the way for more modular and flexible architectures like Hybrid Data Warehousing, which blend the structure of traditional warehouses with the scalability of data lakes. (Of course, even this architecture has its constraints—which is where architectures like Data Fabric and Lakehouse come into play. 🤫)
👉 To learn more, check out the deep dive : Architectural Deep Dive: Hybrid Data Warehousing or check the global overview.
