Skip to main content
Product & Data

Data Warehouse

A data warehouse is a central analytical store holding structured, cleaned historical data, optimised for queries that scan and aggregate millions of rows — the system of record for metrics, reporting and dashboards. Cloud warehouses such as Snowflake, BigQuery and Redshift separate storage from compute and bill for each independently.

Warehouses exist because transactional and analytical workloads fight each other. Operational databases are row-oriented, tuned for many small reads and writes; analytical queries scan entire columns across years of history, which is what columnar storage and massively parallel execution are built for. Running reporting against the production database is a latency incident with a date on it.

A warehouse of raw dumps is a swamp with a SQL interface. The value comes from modelling — conformed dimensions, well-defined marts, one agreed definition of "revenue" — which is unglamorous work that determines whether the organisation trusts its own numbers. The trigger for investing is usually the meeting where two teams argue from two different answers to the same question.

Cost governance is part of the architecture, because compute is metered per query or per credit. Ungoverned, a warehouse bill grows with every dashboard refresh and every analyst exploring with SELECT *; governed, workloads are isolated, queries are reviewed for the scans they cause, and storage tiers match access patterns. For AI systems the warehouse is increasingly an input — the feature source for models and, with tightly guardrailed text-to-SQL, structured context for agents.

A semantic layer has become the standard companion: one governed place where revenue, active user and churn are defined once, and every BI tool, notebook and agent reads the same definition. Without it the warehouse is internally consistent but the interpretations are not, and the organisation goes back to arguing about numbers — just with better infrastructure underneath the argument. The semantic layer also gives AI agents a governed target: text-to-SQL against defined metrics rather than raw tables.

Structure inside the warehouse follows a maturity path: raw landing tables, cleaned and conformed intermediate models, then marts shaped for consumption. Skipping the middle layer feels fast and produces marts built directly on raw sources, after which every upstream change breaks everything downstream. The cleanup costs multiples of the layering that was deferred, which is why "we will remodel it later" is one of the more expensive sentences in data engineering.

Codazz builds this in production — AI & ML Development.

FAQ

Data Warehouse
FAQ.

Common questions about data warehouse.

Ask Us Anything

A database runs the application — many small, fast transactional reads and writes against current state. A warehouse analyses the business — large scans and aggregations over history, optimised for query throughput rather than write latency. Most organisations need both: the database as the system of record for operations, the warehouse as the system of record for metrics.

If the workload is structured analytics and reporting, a warehouse. If it is raw, varied data for exploration and machine learning, a lake. In practice the categories are converging on the lakehouse pattern — open table formats on object storage with warehouse-grade semantics — and many teams end up with one platform serving both, chosen on governance and workload fit rather than category labels.

When the company runs on a handful of metrics one person computes from the production database. A read replica plus a BI tool carries most early-stage teams surprisingly far. The signal to invest is friction: queries slowing the production database, metrics defined differently across teams, or history you need that the application does not keep. Buy when the pain is concrete, not when the stack diagram looks incomplete.