The Mid-Market Data Stack: A Pragmatic Reference Architecture
Most mid-market data stacks are either over-engineered for enterprise scale or held together with spreadsheets. Here is the reference architecture that fits the middle.
13 min read · Published May 16, 2026
The shape of the problem
Mid-market data architectures usually fail in one of two predictable ways. The first is over-engineering: the team adopts the enterprise reference stack (Snowflake + Fivetran + dbt + Looker + Hightouch + an MDS toolchain) and pays $200K/year for capacity they will not use for three years. The second is under-engineering: data lives in 12 SaaS tools, gets exported to Google Sheets weekly, and nobody can answer a basic business question without two days of stitching.
The right architecture for most mid-market companies sits in the middle: a real warehouse, a small set of opinionated tools, and enough discipline around governance to keep the data trustworthy. This guide is the reference for what that looks like in 2026.
The honest reframing
You do not need every layer of the modern data stack. Most mid-market companies need a warehouse, an ingestion tool, a transformation layer, and a BI tool. The rest is optional and frequently premature.
The four layers that matter
1. Warehouse — the source of truth
Where all your operational data lands and lives queryable. The single most important architectural decision in the stack. Modern options: Snowflake, BigQuery, Databricks, or Postgres with pg_analytics extensions for smaller scale. Pick one and commit; the cost of switching later is real.
2. Ingestion — how data gets into the warehouse
Connectors that pull from SaaS systems (HubSpot, Stripe, NetSuite, Shopify) into the warehouse on a schedule. Modern options: Fivetran, Airbyte (cloud or self-hosted), Stitch, or Meltano. Build custom connectors only for systems no vendor supports.
3. Transformation — turning raw data into trustworthy models
The layer that converts raw source tables into the clean, documented, business-meaningful tables analysts and apps consume. dbt is the dominant choice and increasingly the only choice worth seriously evaluating. SQLMesh is an emerging alternative worth watching.
4. BI / consumption — how humans see the data
The dashboards, reports, and ad-hoc query interfaces. Modern options: Looker, Tableau, Metabase, Hex, Mode, Sigma. Many companies use two — a power-user tool (Looker, Hex) plus a self-serve tool for the broader org (Metabase, Sigma).
Layer-by-layer: what to pick and what to skip
Warehouse
Snowflake
- •Best mid-market default — broad ecosystem, separation of compute and storage
- •Pricing predictable once you understand the model; expensive if you misuse it
- •Best support across ingestion + BI + transformation tools
BigQuery
- •Best if you are already in GCP — billing simplicity matters
- •Excellent for analytics on large unpredictable volumes
- •Slot reservation can be tricky to size correctly
Postgres + extensions
- •Right answer for companies with under ~100GB of analytics data and a Postgres skillset
- •DuckDB, pg_analytics, Citus all extend Postgres for analytical workloads
- •Cheapest to operate; not the right answer once you cross terabyte scale
The honest answer for most mid-market
Snowflake is the safe default. BigQuery if you are already deep in GCP. Postgres-with-extensions if you are early enough that you genuinely have under 100GB and want to defer the warehouse decision. Skip Databricks unless you have data engineering team and a real ML workload.
Ingestion
Ingestion tools have converged on a similar feature set. The decision is mostly about pricing model and breadth of connectors for your specific source systems.
- Fivetran — broadest connector library, MAR-based pricing that surprises teams at scale, premium positioning
- Airbyte (cloud) — Fivetran competitor with usage-based pricing that can be cheaper for high-MAR workloads
- Airbyte (self-hosted) — open-source; significant operational cost; right answer if you have data engineering capacity and Fivetran/Stitch pricing genuinely hurts
- Stitch — Talend's lower-cost option, smaller connector library, often a fine choice for mid-market
- Meltano — open-source Singer-based platform, more engineering-flavored, good for teams already running Python infrastructure
When to build a custom connector
Only when the source system has no vendor connector AND the data is critical enough to justify the engineering cost. Maintaining connectors is real work — vendors absorb that cost on the supported ones. Custom connector to a stable internal API: reasonable. Custom connector to a third-party SaaS: usually a mistake.
Transformation
dbt has eaten the transformation layer for a reason. Models in version control, documentation as a first-class artifact, tests on every table, lineage graphs that show downstream impact — these are not nice-to-haves for a mid-market stack, they are the practices that keep data trustworthy enough to act on.
- dbt Core (open-source) — free, runs anywhere, requires you to host the orchestration
- dbt Cloud — managed orchestration, IDE, scheduling, monitoring; per-developer pricing
- SQLMesh — newer alternative with virtualized environments and proper SQL semantics — worth evaluating if starting fresh
- Coalesce, Datafold, Lightdash — adjacent tools that extend the dbt ecosystem
BI / consumption
Power-user tools
- •Looker — strong LookML semantic layer, predictable but expensive
- •Hex — modern, notebook-flavored, fast to iterate, growing share
- •Mode — SQL-first, less semantic-layer-heavy
- •Sigma — spreadsheet-style interface that finance loves
Self-serve / broader org
- •Metabase — open-source, free for self-hosted, the mid-market default for a reason
- •Sigma — also works as a broader-org tool
- •Hightouch's Lightdash — open-source BI built on dbt
- •Power BI — right answer if you are already deep in Microsoft 365
Embedded analytics
- •Cube + custom frontend — for analytics inside your product
- •Sigma, Metabase, Hex all have embed options of varying quality
- •Custom Recharts/Plotly when fully owned UX matters
The optional layers (mostly premature for mid-market)
Reverse ETL
Tools that sync warehouse data back out to SaaS systems (Hightouch, Census, Polytomic). Genuinely useful when you have models in the warehouse that need to drive operational systems — sales segments pushed to HubSpot, churn-risk scores pushed to support tools. Skip until you have specific use cases; not foundational.
Data observability
Monte Carlo, Bigeye, Soda, Elementary. Worth investing in once your warehouse is mission-critical and you have multiple consumers depending on it. dbt's built-in tests cover most of what mid-market needs in year one.
Data catalog / governance
Atlan, Alation, Collibra. Heavyweight enterprise tools. dbt's docs + Slack discoverability is usually enough for mid-market. Consider a real catalog when you have 50+ analysts, regulated data, or genuine cross-functional confusion about where data lives.
Semantic / metrics layer
Cube, dbt's semantic layer, MetricFlow. The promise is consistent metric definitions across every consuming tool. The reality in 2026 is the space is still settling, and most mid-market companies do fine with metric definitions in dbt models and discipline about reusing them.
Real cost ranges (mid-market all-in, annual)
- Warehouse: $12K-$60K/year (Snowflake or BigQuery for typical mid-market volume)
- Ingestion: $6K-$30K/year (Fivetran scales with MAR; Stitch and self-hosted cheaper)
- Transformation: $0 (dbt Core) to $12K-$30K/year (dbt Cloud at 5-15 developers)
- BI: $0 (Metabase self-hosted) to $60K+/year (Looker for a mid-sized org)
- Optional layers: skip them in year one; budget $15K-$50K/year if you add them later
Total realistic year-one budget
Most mid-market companies can stand up a functional, trustworthy data stack for $30K-$90K/year in tooling, plus implementation work. If your data stack vendor recommendations are pushing you past $200K/year in year one, the architecture is wrong for your scale.
The phased implementation that actually works
Phase 1 (weeks 1-4): Warehouse + ingestion for top 3 sources
Pick the warehouse. Land the 3 most-business-critical SaaS sources (typically: CRM, billing, product analytics). Skip everything else for now. Goal: queryable raw data in one place.
Phase 2 (weeks 5-8): dbt models for top 5 business questions
Identify the 5 questions stakeholders ask most often (revenue by month, customer cohort retention, pipeline by source, etc.). Build the dbt models that answer them. Document and test each model. Goal: trustworthy answers to known questions.
Phase 3 (weeks 9-12): BI tool, first dashboards, broader org access
Stand up the BI tool. Build the dashboards for the questions from phase 2. Give stakeholders access. Start ad-hoc analyst work as questions surface. Goal: people are using the data without asking the data team.
Phase 4 (ongoing): Expand sources, models, and consumers
Add the next sources as needs surface. Add models as new business questions emerge. Maintain test coverage and documentation as the stack grows. Resist adding optional layers until you have specific use cases.
Common mistakes to avoid
- Picking the warehouse based on a vendor pitch instead of your actual data shape
- Adopting every modern-data-stack tool because the blogs say to — most are premature for mid-market
- Skipping dbt because 'SQL is just SQL' — the testing, documentation, and lineage are why it wins
- Ingesting everything from every source on day one — focus on the data your stakeholders actually need
- Letting raw tables become the consumption layer — always go through dbt models, even for ad-hoc queries
- Underinvesting in documentation — undocumented metrics get re-derived inconsistently by every consumer
- Choosing Looker because everyone has Looker — for many mid-market companies, Metabase + a power-user tool is the better split
What this looks like as an engagement
Most of our data stack engagements run 8-12 weeks for the foundational build (phases 1-3 above), followed by a retainer or per-project model for expansion work. We typically do not recommend ripping out an existing functional stack — if your warehouse + ingestion combo works, keep it and build on top. Migration projects are real work and rarely the best use of budget unless the current stack is genuinely broken.
If you take one thing away
Stand up the four core layers — warehouse, ingestion, dbt, BI — before you consider anything else. Most mid-market companies are running fine on that stack for years. Optional layers are real costs without obvious payback at this scale; add them only when you have a specific use case.
Download the The Mid-Market Data Stack: A Pragmatic Reference Architecture as PDF
One email gets you the formatted PDF + future guides as we publish them. No spam, unsubscribe any time.
Ready to put this into practice?
Most of our engagements start with the framework you just read. If you want help executing it, a discovery call is the fastest way to find out if we're a fit.