A data warehouse is a central analytical database consolidating data from your product database, third-party tools, and event streams.
A data warehouse is a central analytical database — Snowflake, BigQuery, Redshift, Databricks — that consolidates data from your product database, event stream, and SaaS tools (Stripe, HubSpot, Zendesk, Amplitude) into one place where you can run cross-source SQL. It exists because the alternative — 'analytics via CSV exports emailed between spreadsheets' — collapses somewhere around 30 employees or when the second person asks the same question and gets a different answer.
Signals that the warehouse investment is due: (1) You have 3+ SaaS tools with important data (billing, CRM, product analytics, support) and questions require joining them. (2) Someone runs the same analysis monthly from CSVs. (3) Different teams answer the same question with different numbers. (4) Your production database is being queried for analytics and it's affecting latency. Any two of these justify the effort. Building a warehouse earlier is fine — the tools are cheap enough now that startup-scale warehousing runs $500-5000/month all-in. Building later is expensive because every dashboard, alert, and workflow in the SaaS-tool era has to be rebuilt.
The reference architecture: (a) Ingestion — Fivetran, Airbyte, or Stitch pull data from SaaS APIs into the warehouse. (b) Storage/compute — Snowflake, BigQuery, or Redshift. BigQuery is the cheapest to start (pay per query); Snowflake is easiest to operate and reason about; Redshift is the AWS-integrated choice. (c) Transformation — dbt owns this layer. Raw source tables become cleaned, joined analytics-ready models. (d) BI — Looker, Mode, Metabase, or Hex for dashboards and exploration. (e) Reverse ETL (Hightouch, Census) sends warehouse data back into operational tools. Total cost for a 30-employee company: $2-5K/month, growing roughly linearly with data volume.
dbt's convention that has become universal: raw layer (identical to source, immutable), staging layer (light cleaning, renamed columns, consistent types — one staging model per source table), marts layer (business-facing models joining across sources — customers, subscriptions, revenue). Analysts and dashboards query marts, never raw. This separation means source system changes are absorbed in staging without breaking every downstream dashboard. Skipping this structure and querying raw directly is fine for the first month; unmaintainable by month six.
The most expensive kind of analytics disagreement: two teams reporting different MRR because they defined it differently. Solve this with a semantic layer — dbt Semantic Layer, Cube, LookML, or a strong convention that every metric is defined once in dbt marts and every dashboard references that definition. The rule: no metric exists in a dashboard that isn't defined in the warehouse. When someone asks 'what's ARR?', there's one SQL query that answers it, and every dashboard produces the same number.
The organizational shift matters as much as the tooling. Culture that works: every business question that requires numerical answer starts with 'is this in the warehouse?'; if not, an analyst adds it to a mart, and now the question can be answered repeatedly. Culture that doesn't: individual teams keep spreadsheets alongside the warehouse, definitions drift, and the warehouse becomes 'that thing the data team uses' rather than the source of truth. Executive sponsorship for warehouse-first — including in board decks — is what makes the culture stick.
Investor directory · Fundraising library · Articles A–Z · Company funding database