A "Simple Stack" Data Architecture - Explained

architecture Mar 12, 2025

When people hear "modern data" they think about tools first, and that is backwards. A simple stack is a framework of five components, a database, ingestion, transformation, version control and reporting, that you fill with whichever tools fit your team. There are three common patterns for filling it: cloud agnostic, where you mix vendors; single cloud platform, where everything runs on Azure, AWS or GCP; and fully open source. The framework stays identical across all three, only the names in each box change. That is the whole point, because once you can see the five boxes you can read any stack, including one you have never worked on.

Key takeaways

Tools are not a strategy. The strategy most teams need is still a five component pipeline, and it has barely changed.
Cloud agnostic means spreading the architecture across vendors so you are not locked into one provider for everything.
Single cloud platform means every component comes from the same provider, which is common at companies already standardized on AWS, Microsoft or Google.
Open source means swapping the paid cloud services for self-hostable options, often Postgres, Airbyte, dbt, GitHub and Metabase.
Mixing patterns is normal. Using Azure for the database and dbt with GitHub for transformation and version control is a real and common setup.
Do not agonize over which tool is better. The right choice depends on your team's skill set and use case far more than on the tool itself.

Three common patterns

Whatever tools a team ends up with, the way they chose them usually falls into one of three approaches.

Cloud agnostic. The architecture is spread across multiple cloud tools and providers, so you are not tied to one vendor for everything.
Single cloud platform. All infrastructure comes from the same provider. Common at companies that only use Amazon, only Microsoft, or only Google.
Open source. The main components use open source options instead of paid cloud versions.

There is nuance in all three, and that is where most of the questions come up. The sections below walk through what each one looks like filled in.

Treat the tools below as examples, not rankings. Which one is better depends heavily on your skill set and your use case.

What usually decides it

In practice the pattern is chosen for you more often than by you. If the company is already all in on one provider, procurement and security will push you to stay there.

If nobody has standardized yet, you have room to pick per component. And if budget is the binding constraint, open source gets you a full pipeline for the cost of the infrastructure it runs on.

Cloud agnostic

This is the multiplatform approach. You pick the best fit for each component and accept that they come from different vendors.

One version of it looks like this:

Database: Snowflake
Ingestion: Airbyte to load the data
Transformation: dbt to move it from raw to analytics and build everything in between
Version control: GitHub to track changes and automate the workflow
Reporting: Tableau

Swapping pieces in and out

Every box has alternatives. Use GitLab instead of GitHub, Fivetran or Stitch instead of Airbyte, Power BI instead of Tableau.

Another real combination is BigQuery for the database, Airbyte for ingestion and Tableau for reporting. These are stacks I have actually used, and both read the same way on a diagram.

Single cloud: Microsoft Azure

Now the same framework, filled entirely from one provider. Start with Azure:

Database: Synapse
Ingestion: Azure Data Factory to extract and load
Transformation: Data Factory again, applying logic and building the workflow
Version control: Azure DevOps
Reporting: Power BI

You can also hybridize. Keep most of the Azure stack and swap in dbt and GitHub if you want those features.

A note on Fabric

Microsoft also has a newer platform called Fabric, which bundles a lot of these pieces together. I have not used it myself, so I cannot speak to how it works in practice.

The idea behind it is telling, though. Microsoft knows most teams need these same core components, so bringing them under one hood is meant to simplify things.

Single cloud: Amazon Web Services

The AWS version follows the identical shape:

Database: Amazon Redshift
Ingestion: AWS Glue to extract, load and ingest
Transformation: Glue again, in the same way Data Factory covers both on Azure
Version control: AWS CodeCommit
Reporting: Amazon QuickSight

As with Azure, teams regularly swap one or two of these out while keeping the rest on AWS. That is a pattern I see constantly.

Single cloud: Google Cloud Platform

GCP fills the same five boxes:

Database: BigQuery
Ingestion and transformation: Google's own data pipeline services
Version control: Google's hosted Git offering
Reporting: Looker

It all works together natively, or you swap in a couple of outside components and keep the bulk of the architecture on the platform.

The pattern across all three

Notice what repeats. Each provider has a warehouse, one service that covers both ingestion and transformation, a Git offering, and a reporting tool.

That is the same five boxes every time. Learn the boxes once and you can read a stack you have never seen before in about a minute.

Fully open source

The open source pattern replaces the paid cloud services with self-hostable tools. This is also the version I build as a hands-on playground stack, because anyone can stand it up without signing up for anything.

Database: Postgres, easy for everyone to install and follow along with
Ingestion: Airbyte, which has an open source self-hosted option, loading into raw tables
Transformation: dbt, also open source
Version control: GitHub, which is a cloud platform but free to use
Reporting: Metabase, open source with the option to self-host

One difference in the diagram

The open source diagram drops the separate database. With Postgres out of the box you cannot easily query across databases without extra work, so raw and analytics live together in one database and are separated by schema instead.

That is a good illustration of the broader point. The framework did not change, the implementation detail did.

Why the framework matters more than the tools

Every one of these stacks is the same five components wearing different labels. Once you can see that, a new tool is just a candidate for a box you already understand.

It also makes you portable. Walk into a team running Synapse and Data Factory, or Redshift and Glue, and you already know what each piece is doing and where your work fits.

That portability cuts both ways. It also means replacing one tool later is a contained change, because you are swapping the contents of a box rather than redesigning the pipeline.

Where this fits in the bigger job

Design is only one part of building a well structured architecture. Ingestion patterns, modeling, environments and workflow all still have to be worked out.

But the design is the part that determines whether the rest holds together. Get the five boxes agreed on first, then argue about what goes in them.

Key terms

Simple stack

A five component data architecture framework, database, ingestion, transformation, version control and reporting, that stays the same regardless of which tools fill it.

Cloud agnostic architecture

A stack built from tools across multiple vendors so no single provider owns every layer of the pipeline.

Single cloud platform

A stack where every component comes from one provider, typically AWS, Microsoft Azure or Google Cloud Platform.

Self-hosted tool

An open source tool you run on your own infrastructure instead of paying for a managed cloud version, such as Airbyte or Metabase.

Raw tables

The landing tables that ingestion loads into before any transformation runs, kept separate from the modeled analytics layer.

Common questions

What is a simple data stack?

It is a data architecture with five components: a database, ingestion, transformation, version control and reporting. It is deliberately bare bones, and for most teams it covers everything they need while still scaling well.

Should I go cloud agnostic or stay on one cloud provider?

If your company has already standardized on one provider, staying there is usually the path of least friction for billing, security and support. Go cloud agnostic when the best tool for a specific component is clearly not the one your provider offers. Most teams end up somewhere in between.

Can you build a modern data stack entirely with open source tools?

Yes. Postgres, Airbyte, dbt and Metabase cover database, ingestion, transformation and reporting, with GitHub for version control. The trade-off is that you host and maintain it yourself instead of paying someone else to.

Can I mix dbt into a single cloud stack?

Absolutely, and it is common. Keeping Synapse or Redshift as the database while using dbt and GitHub for transformation and version control is a normal hybrid, and you still get most of the platform's benefits.

Why does the open source example use one database instead of two?

Because Postgres cannot easily query across separate databases without extra configuration. Keeping raw and analytics in a single database, split by schema, avoids that friction while preserving the same logical separation.

Does the choice of tool matter less than people think?

For most small teams, yes. The component each tool fills matters more than the brand, and the deciding factors are usually your team's existing skills and what you already pay for.

Final takeaway

Almost every architecture I design with a client is this same five box framework with different logos in the boxes. Learn the framework and the tool selection stops being an intimidating decision, because you are only ever choosing a filler for a slot you already understand.

Additional Free Resources

Starter Guides & Checklists

Explore additional free resources built on the same patterns I use with real clients so you can build your own with structure and confidence. Topics include data architecture, modeling and more specifically for small data teams.

Browse Resources