What is a Data Foundation?

The phrase "data foundation" has entered every vendor pitch. It now covers everything from a single warehouse to a multi-region lakehouse with a semantic layer and column-level access controls. Buyers reach the end of the demo without a clear answer to "what is the thing".

Every company already has data. It sits in the CRM, the ERP, the billing system, the marketing tools, the support tickets, the product database, and several hundred spreadsheets. Each system has its own version of the customer, the product, the contract, and the revenue. When leadership asks a question that spans systems, someone runs around and reconciles by hand. A data foundation removes the running around.

The full layer has four parts working together:

1. Ingestion. Data flows in from operational systems on a schedule, in real time, or both.
2. Storage. A warehouse or lakehouse holds the raw data and the modelled tables that downstream consumers actually query.
3. Modeling. Raw data gets shaped into the tables that match how the business thinks. Customer, product, order, revenue.
4. Governance. Who can see what, who changed what, how do we know the numbers are right.

None of the four is optional in production. Skipping storage gives you batch jobs that have nowhere to land. Skipping modeling produces reports that mean different things in different rooms. Skipping governance puts the project one regulator visit away from rebuild.

Three signals show up consistently before a company decides it has outgrown the SaaS-tool jungle:

Reports disagree. Marketing reports one revenue number. Finance reports another. Sales has a third. The differences come from each team pulling exports from different systems at different times and applying different rules. The CFO stops trusting the dashboards.

Cross-system questions take a week. "How much revenue do we get from customers who use feature X and renewed last quarter" requires data from billing, the product database, and the CRM. The answer comes back five days later, half right, and the question has moved on.

AI projects stall on raw data. A team starts building an AI agent or a forecasting model. Two months in, 80 percent of the work is still cleaning exports and joining tables by hand. The actual model never gets to production because the data layer underneath is too fragile.

Company size correlates with these signals but does not cause them. We have seen 40-person companies need a foundation because they sell into regulated industries. We have seen 300-person companies survive without one because they run a single product on a single platform. The honest test is whether the questions you want to answer cross system boundaries on a weekly basis.

Four real decisions that shape the build. Each has a defensible answer in both directions.

Cloud-native vs self-hosted. Cloud-native (Snowflake, BigQuery, Databricks) is faster to set up and removes most ops work. Self-hosted (Postgres on a VM, ClickHouse, DuckDB) is cheaper at small scale and avoids egress fees. Nordic mid-market companies on a controlled cost trajectory often land on Postgres or DuckDB for the first 12 months, then migrate to a cloud warehouse once data volume crosses the threshold where ops cost exceeds licence cost.

Warehouse vs lakehouse. A warehouse holds structured tables. A lakehouse adds cheap object storage for raw files alongside tables. Companies handling only structured data (sales, finance, product analytics) tend to pick a warehouse. Companies dealing with documents, logs, images, or audio (legal, healthcare, manufacturing) tend to pick a lakehouse. Databricks dominates the lakehouse category. Snowflake has been adding lakehouse features to catch up.

Real-time vs batch. Most reporting needs do not require sub-minute freshness. Batch updates every hour or every night handle 90 percent of cases at one-tenth the cost. Real-time matters for fraud detection, operational monitoring, and customer-facing analytics. Build batch first. Add real-time pipelines later for the specific use cases that justify it.

Custom data apps vs BI tools. The Jourier position is direct: build the analytics layer as real product-grade apps the client owns. Proper frontend framework (React, Next.js, Vue). Proper backend framework (FastAPI, Express, Django). Visualisation libraries inside the app (D3, Recharts, ECharts). Deployed in the client's accounts. Every BI-tool category is legacy in this view. Commercial BI (Power BI, Tableau, Looker, Qlik) pays per-seat fees and locks the company in. Open-source BI (Metabase, Superset, Lightdash) constrains the work to what the project's developers built. Rapid-prototyping frameworks (Streamlit, Plotly Dash, Gradio) look and feel like Streamlit apps and do not scale to product-grade UX. Low-code internal-tool builders (Retool, Internal.io) trade vendor lock-in for build speed. The exception across all these categories is procurement-mandated environments where a specific tool is contractually required. There, the foundation serves it while a migration plan to custom apps runs in parallel.

Open-source vs commercial infrastructure. The current generation of open-source tools (Postgres, dbt, DuckDB, Iceberg, Trino) covers what most Nordic mid-market companies need. Commercial infrastructure (Snowflake, Databricks, BigQuery) earns the licence fee where it materially outperforms on query performance at scale, on multi-region setups, or on specific compliance certifications. Pick commercial infrastructure where the gap is real. Pick open source where the gap is not.