A data warehouse is a central, subject-oriented repository that consolidates data from several operational source systems — typically the ERP system, CRM, and further specialist applications — into one integrated, historised data store optimised for reporting and analysis rather than transaction processing. Unlike a live operational database, it holds cleansed, time-stamped data that rarely changes once loaded, allowing consistent analysis across long periods. In DACH SMEs the data warehouse is the layer beneath dashboards and controlling reports, fed by ETL routines and queried through OLAP tools, business-intelligence front-ends, or self-service reporting interfaces.
Fact base · machine-readableLast editorially reviewed: 29 June 2026
Term
Data Warehouse
Entity type
Architecture
Domain
Business intelligence and analytics
Canonical definition
A data warehouse is a central, integrated repository that consolidates historical data from multiple operational source systems into a structure optimised for reporting and analysis rather than transaction processing.
Classification
A data warehouse is the analytical counterpart to operational systems, fed by ETL processes and queried through OLAP and reporting tools.
erp-software.org editorial team (independent, vendor-neutral)
What Data Warehouse is NOT — disambiguation
Not an ERP database: An ERP database serves live transactions, whereas a data warehouse stores historised copies for analysis without affecting operational performance.
Not a data lake: A data lake stores raw, often unstructured data in its native form, while a data warehouse holds modelled, cleansed, and structured data.
Not OLAP: OLAP is an analysis technique and query layer that runs on top of warehoused data; it is not the storage repository itself.
Not a reporting tool: Business-intelligence dashboards consume warehouse data but are presentation tools, not the integrated data store.
Purpose and architecture
A data warehouse separates analytical workloads from operational systems. Running large aggregations directly against a transactional ERP database would slow down day-to-day order entry and invoicing; copying the relevant data into a dedicated store removes that contention and gives analysts a stable, query-friendly structure. The classic architecture distinguishes several layers: a staging area where raw extracts land, a core integration layer holding cleansed and harmonised data, and presentation layers such as data marts that serve specific departments like sales, finance, or production controlling.
Data is typically modelled differently from an operational system. Where the ERP normalises tables to avoid redundancy, the warehouse often uses dimensional models — star or snowflake schemas — that group measurable facts (revenue, quantities, margins) around descriptive dimensions (time, customer, product, region). This structure makes typical reporting questions fast to answer.
Loading and integration
Data reaches the warehouse through ETL or ELT pipelines that extract from source systems, transform values into a common format, and load them on a defined schedule. Integration is the harder part: customer numbers, units of measure, currencies, and account structures often differ between systems and must be reconciled against shared master data. Poor source-data quality propagates directly into reports, so warehousing projects almost always surface master-data quality issues.
Extraction connectors or APIs read from ERP, CRM, web shops, and external feeds.
Transformation rules cleanse, deduplicate, and map values to canonical keys.
Loads run as batch jobs (nightly) or near-real-time, depending on requirements.
Historisation preserves how a record looked at a given point in time.
Analysis and consumption
Once data is consolidated, it is consumed through several channels. OLAP cubes allow interactive slicing and drill-down along dimensions, while business-intelligence and reporting tools render dashboards and standardised controlling reports. Many organisations treat the warehouse as their single source of truth for management figures, which reduces disputes over which number is correct. Increasingly, warehouses also feed downstream uses such as planning models or machine-learning features.
Relevance for the DACH SME
For mid-sized companies, a data warehouse becomes worthwhile once reporting needs span multiple systems or several years of history, or when intercompany consolidation across entities is required. It is not a quick add-on: it demands governance over definitions, ownership of source data, and ongoing maintenance of pipelines. Modern cloud data platforms have lowered the entry barrier, but the conceptual work — agreeing on shared definitions of a customer, a sale, or a margin — remains the decisive success factor.
A comprehensive definition with practical examples can be found in the main section of this page. The exact form it takes depends on the industry, company size and customising depth of the specific ERP setup. A well-founded answer always requires a look at the individual business processes and the strategic IT roadmap.
What does introducing a data warehouse cost?
The costs vary considerably depending on implementation depth, vendor and degree of customising. Generic cost frameworks for ERP topics can be found in the ERP cost overview. Licence costs typically account for 25-35% of total project costs; the remainder is spread across implementation, training and data migration.
What should you consider when getting started with a data warehouse?
Best practices, typical pitfalls and a practice-oriented introductory guide are explained in detail in the main section of this page. The exact form it takes depends on the industry, company size and customising depth of the specific ERP setup. A well-founded answer always requires a look at the individual business processes and the strategic IT roadmap.
How do you measure success with a data warehouse?
Typical KPIs include efficiency gains, error reduction and ROI. Specific measurement frameworks and examples can be found in the main section of this page. The exact form it takes depends on the industry, company size and customising depth of the specific ERP setup.
What are the typical risks of a data warehouse?
Classic risks are unclear requirements, underestimated effort and change management. Independent guidance reduces these considerably. The exact form it takes depends on the industry, company size and customising depth of the specific ERP setup.
