A Modern Data Stack for Small Companies: What You Actually Need (and What You Don't)

By Clayton Severson, Principal Consultant · Published August 20, 2026

A small company needs four layers: somewhere to put data, something to move it there, transformation logic in version control with tests, and a way to look at the results. That is the entire requirement. Nearly everything else marketed as essential solves a problem you will meet later, if at all.

The modern data stack was designed for companies with data teams, and it is sold to companies with one analyst and a spreadsheet habit. The tooling is genuinely good. The problem is that the reference architecture in every vendor diagram assumes a scale most small companies will not reach for years, and buying it early does not accelerate you — it gives you eight systems to maintain and no more answers than you had before.

What follows is what to build, in what order, and an explicit list of what to leave alone.

What is a modern data stack?

That four-layer shape is right. The disagreement is only about how much machinery each layer needs, and for a small company the honest answer is: much less than the diagram shows.

What does a small company actually need?

Layer	What you need	What you get sold
Warehouse	One managed warehouse — or Postgres, honestly	A lakehouse with three storage tiers
Ingestion	Scheduled scripts, or a small managed tier for awkward sources	An enterprise connector platform priced on row volume
Transformation	dbt Core in version control, with tests	A commercial transformation platform with a semantic layer
BI	One dashboard tool everyone actually opens	A licence per seat for a tool that needs a consultant
Orchestration	Cron, or your CI system on a schedule	A distributed workflow engine

One clarification worth making before you compare vendors: ingestion and transformation are different jobs, and the tools most often named together are not alternatives to each other. Fivetran moves data; dbt models it once the data has landed. The two companies merged in June 2026, which makes the point harder to see on a pricing page and no less true.

Read the middle column as a complete specification, not a starter kit. A company with a managed warehouse, a few scheduled extractors, dbt models under code review, and one dashboard that leadership actually opens on Monday is ahead of most companies three times its size.

Where should the money go?

The warehouse, and almost nowhere else at first. It is the one component everything attaches to, the one whose choice is genuinely hard to reverse, and the one where managed beats self-run by the widest margin. Everything else in the stack can be swapped in an afternoon; migrating a warehouse is a project.

The realistic options at small scale fall into three shapes. A managed cloud warehouse with serverless or auto-suspending compute is the default — you pay for what you query and nothing when idle, which suits bursty small-company usage. Postgres is a legitimate warehouse at low volume and is often already running. And for single-node analytical work, an embedded analytical engine like DuckDB is remarkably capable, runs inside your existing pipeline, and costs nothing.

Choose on the basis of where your data already lives and who has to operate it on a Tuesday afternoon, not on benchmark charts. Query performance is not your bottleneck at this size. Your bottleneck is that nobody has time to maintain it.

Can you just use Postgres?

Often, yes, and more people should. Postgres handles analytical workloads comfortably into the tens of millions of rows, supports the SQL you need, and — decisively — is a system your engineers already know how to back up, monitor, and restore.

One firm rule: do not run analytics against your production application database. Use a separate instance or a read replica. A heavy analytical query against the same database serving your product is a straightforward way to cause an outage, and it will happen at the worst possible moment because that is when someone runs the big report.

You have outgrown it when behaviour tells you so, not when a row count crosses a threshold:

• Queries on your largest tables take longer than anyone is willing to wait, and indexing has stopped helping.
• Analytical load is visibly affecting the application, even on a replica.
• You need to join across sources that will not sensibly live in one Postgres instance.
• Concurrent analytical users are contending with each other.

Until one of those is true, moving to a cloud warehouse buys you a migration and a bill. If your data ends up in the tens of billions of rows or you inherit a legacy platform, that is a different article — see the Teradata to Databricks migration piece for what that end of the spectrum involves.

What you can skip

Each of these solves a real problem. The question is whether it is your problem yet.

Thing	Skip until
Streaming and real-time pipelines	A decision genuinely changes within minutes. Daily batch is fine for nearly every small company
Data catalog / governance platform	People cannot find tables. With forty models, the repo is the catalog
Reverse ETL	You are manually copying warehouse data into a SaaS tool often enough to resent it
Semantic layer	Two teams define the same metric differently and both are shipping it
Dedicated orchestrator	Cron genuinely stops working — real dependencies, retries, backfills
Lakehouse / open table formats	You have unstructured data or scale that a warehouse cannot hold economically
Data observability platform	dbt tests are running and still missing things
ML platform	You have a model in production. Not a plan for one

The pattern is that every row describes a symptom, not a milestone. Adopt on symptom. A tool bought before its symptom appears is pure carrying cost — you pay for it, you maintain it, you train people on it, and it solves nothing.

The one discipline worth having from day one

Transformation in version control, with tests. This is the cheapest thing in the stack and the most commonly skipped, and skipping it is what produces the situation every small company eventually finds itself in: three dashboards showing three different revenue numbers, and no way to tell which is right.

Concretely that means dbt Core in a git repository, models reviewed like application code, and tests asserting the things you would be embarrassed to get wrong — primary keys are unique and not null, foreign keys resolve, revenue is never negative, row counts do not silently collapse. It costs an afternoon to set up.

The alternative is SQL living in saved queries and BI tool definitions, where logic is invisible, undocumented, unreviewed, and duplicated with small variations. That is not a tooling preference. It is the difference between numbers you can defend and numbers you hope are right.

A note on licences

Check the licence before you standardize on an open-source tool, particularly in the BI layer. Several popular open-source dashboarding and BI tools ship under the AGPL, which is entirely fine for internal self-hosted use but carries obligations if you ever embed the tool in something you distribute or offer to customers. Permissive licences — MIT, Apache 2.0, BSD — carry no such condition.

This matters more than it sounds for small companies, because the internal analytics tool has a way of becoming the customer-facing reporting feature two years later. Knowing which licence you are standing on before that happens is much cheaper than finding out afterwards.

What it costs, roughly

Less than the vendor conversation implies. A serviceable small-company stack — managed warehouse with auto-suspending compute, a handful of scheduled extractors, dbt Core, one BI tool — typically lands in the low hundreds of dollars a month, and the warehouse dominates it. Managed ingestion is usually the component that pushes it higher, which is why it is worth deferring until connector maintenance actually hurts.

Two cost warnings. Consumption pricing means an unbounded dashboard refreshing every five minutes can generate a genuinely surprising bill, so set budget alerts on day one, before the first dashboard ships. And the largest real cost is rarely on an invoice: it is the engineering time spent maintaining infrastructure that was bought before it was needed.

How to sequence it

1. Write down the questions. Five to ten numbers that would actually change a decision. If a number would not change behaviour, it does not need a pipeline.
2. Stand up the warehouse. Managed, or Postgres on its own instance.
3. Land the two or three sources those questions require, raw, on a schedule. Not every source. The ones the questions need.
4. Model in dbt, in git, with tests, from the very first model.
5. Ship one dashboard and watch whether anyone opens it. This is the real acceptance test, and it is failed far more often than anyone admits.
6. Add tools on symptom, using the table above.

Steps one and five are the ones that get skipped, and they are the ones that determine whether any of this was worth doing. A stack nobody queries is not infrastructure, it is a subscription.

Frequently asked questions