How to centralize your data without being a big company

A data warehouse isn't just for corporations with 20-person engineering teams. This guide explains how mid-sized companies can centralize their data in weeks, using open source tools and without multi-year projects.

Bosanova did it in three weeks. Before the project, each store managed its own spreadsheet, orders came in through WhatsApp, and the real inventory count was known only to the warehouse manager. Three weeks later, they had sales and stock centralized in one place, with reports running automatically every night.

It wasn’t a two-year project. It didn’t require a team of fifty engineers or a seven-figure budget. It was a data warehouse built with open source tools, designed right from the start.

If that sounds like something that doesn’t apply to your company, this article is for you.

Why do mid-sized companies think a data warehouse isn’t for them?

The most common belief is that centralizing data is enterprise infrastructure — Oracle, SAP, specialized teams, multi-year projects. And for a long time, that belief had some truth to it: the available tools were expensive, complex to maintain, and required specialized technical knowledge.

That world no longer exists.

Over the past five years, the open source data stack matured to the point where a 50-person company can have the same architecture as a 5,000-person one, at a monthly infrastructure cost that fits into any IT budget.

The problem is no longer access to tools. The problem is that most mid-sized companies never stopped to ask: where does our data live today, and what decisions are we making worse because it isn’t all in one place?

What is a data warehouse in business terms?

Before talking about technology, let’s talk about what it’s for.

A data warehouse is a centralized place where all business data lives, organized so it’s easy to ask questions. It doesn’t replace your ERP or CRM. It complements them: it takes data from all those systems, brings it together, cleans it, and makes it ready for analysis.

The practical result: when the sales manager wants to know which customers bought more than three times last quarter but haven’t purchased in six months, the answer doesn’t depend on someone spending two hours merging two Excel exports. It’s available in seconds.

Multiply that by every question your team needs to answer each week, and that’s the value of having your data centralized.

When does it make sense for a mid-sized company?

Not every company needs a data warehouse. There are clear signals for when it does:

When reporting requires recurring manual work. If someone on your team spends more than four hours a week exporting data from a system, pasting it into Excel, and formatting it for a presentation, you’re paying the cost of not having centralized data — it just doesn’t show up on any invoice.

When numbers don’t match across departments. Sales says they closed 30 customers last month. Finance says they invoiced 27. Operations has 32 in their system. Nobody’s lying — each one measures differently because there’s no shared source of truth.

When important decisions depend on data that arrives late. If month-end close takes five days because you need to consolidate information from multiple sources, you’re making next month’s decisions with last month’s numbers.

When you want to implement AI and your data is scattered. Any AI model needs clean, centralized data to work. Without that, there’s no AI — just automated confusion.

When does it NOT make sense?

It’s also worth being honest. A data warehouse isn’t the solution if:

• Your company has fewer than 20 employees and the data fits reasonably into two or three well-maintained spreadsheets.
• Your decisions don’t depend on combining information from multiple systems.
• You don’t have anyone who can interpret the data once it’s available — the problem may be analytical culture, not infrastructure.

A data centralization project that nobody uses is worse than not building it: it creates technical debt and unmet expectations.

How it works in practice: a healthcare client case

Without naming the client, here’s a case we worked on this year with a healthcare organization in Latin America.

They had three systems: an HIS (Health Information System) for clinical records, an ERP for finance and billing, and an in-house scheduling system. Each worked fine on its own. The problem was that nobody could answer simple questions like: how many patients seen last month came back within 30 days? What’s the average revenue per visit type? Which doctors have the highest occupancy rates?

To answer any of those questions, someone exported data from all three systems, merged it in Excel, and produced a report that took two to four days.

The project went like this:

Week 1: Source mapping. We identified what data each department needed for their most critical decisions, where that data lived, and how it was structured in each system.

Week 2: Pipeline construction. We connected the three systems to the data warehouse with extraction processes that run automatically every night. Data arrives raw, gets cleaned, and is transformed into tables ready to query.

Week 3: Report construction. With centralized data, we built the dashboards the leadership team needed: occupancy, billing, patient retention, performance by department.

By end of month, the leadership team had access to information that previously took days to consolidate. The finance department closed the first month with numbers ready the day after close — not five days later.

The tools we use (and why they’re open source)

There’s no reason to pay licensing fees when open source alternatives do the same job:

Layer	Tool	Purpose
Storage	PostgreSQL	Data warehouse database
Extraction	Airbyte or Python scripts	Connect source systems and pull data
Transformation	dbt	Clean, model, and document data
Visualization	Apache Superset or Metabase	Dashboards and reports for the team
Orchestration	Apache Airflow or n8n	Automate data pipelines

The infrastructure cost for this complete stack, for a mid-sized company, is between $200 and $600 USD per month depending on data volume. No software licensing.

When this model applies — and when it doesn’t

This stack works well when:

• Data volumes are reasonable (millions of records, not billions)
• The technical team can maintain pipelines in Python or SQL
• Source systems have APIs or structured exports

It may not be enough if:

• Volumes are massive and require distributed processing (that’s where Spark, Databricks come in)
• Legacy systems have no standard way to extract data
• The team has no internal technical capacity to maintain the stack

In those cases, the solution exists but requires a different architecture — and that’s exactly the kind of diagnosis we run in a Smart Blueprint before proposing anything.

What you can do this week

You don’t need to start with an infrastructure project. Before that:

1. Take inventory of your data sources. List every system where business information lives: ERP, CRM, production systems, shared spreadsheets, SaaS platforms. Note what data each one produces and who uses it.

2. Identify your three most expensive decisions. Which business decisions have the biggest impact on your results and are currently made with incomplete or delayed information? Those are the ones a data warehouse solves first.

3. Calculate the real cost of the current chaos. Add up the weekly hours your team spends manually merging data. Multiply by hourly cost. Annualized, that number is usually larger than the cost of building the right infrastructure.

If that exercise reveals a real problem, the next step is mapping the right architecture for your specific case. That’s what we do in the first ten hours of work with a new client.

Frequently asked questions

How long does it take to get the data warehouse running?

It depends on the number of source systems and the complexity of the data. For a company with two or three well-documented systems, between three and six weeks from kickoff to having the first reports working. More complex projects can take two to three months.

Do I need to hire an internal data team?

Not necessarily. The most common model for mid-sized companies is to have an external partner build and maintain the infrastructure, while the internal team focuses on interpreting the data and making decisions with it. What you do need internally is at least one person who understands the business data and can validate that the reports make sense.

What happens to the data we already have in spreadsheets?

Spreadsheets are valid data sources and can be incorporated into the pipeline. The extra work is in standardizing the format and ensuring the structure stays consistent. In many cases, part of the project is migrating those spreadsheets to more structured systems.

How is the data warehouse kept up to date?

The extraction pipelines run automatically at whatever frequency you need — it can be every night, every hour, or in real time for specific cases. Once built, maintenance is low as long as the source systems don’t change their data structure.

---

Is your data scattered across multiple systems and reporting requires manual work? We run the full diagnosis in ten hours: we identify the sources, the critical decisions, and the right architecture for your case. Let’s talk.

---

Related:

• When two reports from the same business give different numbers
• Your company doesn’t have an AI problem. It has a data problem.