The modern data stack for mid-market B2B, without the hype

The modern data stack has a marketing problem: the people defining "modern" are the same people selling the tools. Somewhere between employee 20 and employee 500, someone will put an architecture diagram in front of you with 19 logos on it. A warehouse, an ELT tool, a transformation layer, a CDP, reverse ETL, a data catalog, a semantic layer, an observability platform, a metrics store. For a company your size, most of that diagram is procurement theater. You need four tools, a build order, and two people who understand the whole thing.

We covered why your numbers don't match in an earlier post. This one is the buying guide: which warehouse, which pipeline tool, what dbt actually does for you, and the two traps that catch mid-market teams: buying a CDP too early, and letting one analyst become a single point of failure.

Pick the warehouse in a week, not a quarter

BigQuery and Snowflake are both excellent, which is exactly why the evaluation shouldn't take long. At mid-market volumes, say under a few terabytes of active data, the honest differences come down to ecosystem and billing model.

BigQuery is serverless and you pay per query: roughly $6.25 per TiB scanned on demand, with the first TiB each month free. There are no clusters to size and nothing to switch off at night. If you run GA4, Google Ads, or anything on GCP, the native exports make it the default; GA4 streams into BigQuery at no charge, which alone settles the question for a lot of marketing-led teams. The trap: a BI tool running SELECT * over an unpartitioned events table can burn a month's budget in an afternoon. Partition your tables and set cost controls on day one.

Snowflake bills compute per second through credits, and its warehouse model gives you real workload isolation: the ELT job, the BI dashboards, and the data scientist's experiments each run on their own compute, so nobody slows anyone down. Data sharing is stronger, and it runs on AWS, Azure, and GCP. The trap at small scale is paying for idle compute because someone left auto-suspend at 10 minutes on a warehouse that runs one query per hour.

At 20 to 500 people, either bill lands in the hundreds of dollars per month when configured with adult supervision. Choose by ecosystem: Google-centric goes BigQuery, AWS-heavy with teams that need isolated compute goes Snowflake. And here's the part vendors won't say: this decision matters far less than what comes after it. We've watched teams run a three-month warehouse evaluation and then define "active customer" in a Slack thread. That's backwards.

Fivetran or Airbyte, the honest version

ELT is plumbing. You want it boring.

Fivetran has the best connectors in the business and asks for close to zero maintenance. Pricing is based on monthly active rows, and for a typical mid-market source list (CRM, billing, ad platforms, support desk) the bill runs $500 to $1,500 per month. It gets expensive when you push high-volume tables through it, so don't: product event streams belong on a direct export to the warehouse, not on a per-row-priced pipe.

Airbyte is open source. Self-hosted, it costs infrastructure plus engineering hours, and the hours are real: connector upgrades, schema-change surprises, the occasional sync that dies on a Friday. Airbyte Cloud closes most of that gap with volume-based pricing. Pick Airbyte when you already have platform engineers on staff, or when you need a long-tail connector Fivetran doesn't cover.

Our default is Fivetran for the first five to ten connectors, with a calendar reminder to revisit once the bill crosses $2,000 a month. Engineer-hours spent babysitting pipelines are the most expensive line in a data budget, and they never show up in the tool comparison spreadsheet.

dbt is where the stack earns its keep

The warehouse and the pipelines are commodities. The transformation layer is where your company's actual logic lives, and this is where dbt is non-negotiable.

dbt is where "customer," "MRR," and "closed-won" get defined once, in version-controlled SQL, with tests. When the Salesforce admin renames a field, a schema test fails loudly instead of a board metric drifting quietly. When finance and marketing argue about CAC, the argument gets settled in a pull request instead of a meeting. Your RevOps system is only as trustworthy as these definitions.

dbt Core is free. dbt Cloud runs about $100 per developer per month and buys you scheduling and hosted docs. A realistic mid-market project is 40 to 120 models, and a competent analytics engineer gets the first revenue and pipeline marts live in four to six weeks.

You almost certainly don't need a CDP

The CDP is the most oversold product in the data stack for a company between 20 and 500 people. The pitch sounds great: collect every event once, unify identities, route data anywhere in real time. The reality for a B2B company with one product, one website, and five downstream destinations is that your warehouse already does this, minus the real-time layer you probably don't need and the five-figure annual invoice you definitely don't.

The warehouse-first pattern covers it: send product events directly to BigQuery or Snowflake, model identity in dbt, and when a team needs data pushed into HubSpot or an ad platform, add a reverse ETL tool like Census or Hightouch for that specific case. Every sync you add is justified by a real workflow, not by a platform license.

A CDP earns its keep when you have multiple customer-facing products, real-time personalization across web, email, and ads, and a growth engineering team to feed it. Under 500 people, that describes almost nobody. Buy the use case, not the category.

The one-person dashboard, and the build order that avoids it

The most common failure we see in mid-market data isn't a tool choice. It's a person: the analyst who built all 60 dashboards, holds every metric definition in their head, and wrote the SQL directly inside the BI tool. When they leave, and they leave, the numbers freeze. Nobody dares touch a dashboard they can't rebuild, trust decays within a quarter, and the exec team quietly goes back to spreadsheets. That's the bus factor at its most expensive.

The fix is structural, not heroic. Metric logic lives in dbt, versioned and reviewed. The BI layer stays thin: Metabase or Looker Studio reading from clean marts, not 400-line queries pasted into chart editors. Two people, minimum, can run every pipeline end to end. There's a runbook. If you're 30 people and can't justify two data hires, the second person can be fractional, but a bus factor of one is a decision, and it's the wrong one.

The build order that works, over and over:

Weeks 1-2: stand up the warehouse, connect CRM, billing, and product events. Weeks 3-6: dbt models for revenue and pipeline, with tests, reviewed by finance and sales ops. Weeks 7-8: dashboards for the exec team, sales, and marketing, reading only from modeled tables. After that: orchestration, alerting, and new sources one at a time.

All-in tooling at the 100-person mark: $800 to $2,500 per month. The real cost is people, either a senior analytics engineer (a $120K-plus hire in the US market) or a team like ours running the stack part-time. And if AI is on your 2026 roadmap, this is the prerequisite: agents built on inconsistent data automate the inconsistency.

This is the stack we build in our Data practice, and it's the exact set of questions behind the Data dimension of the DGTL Readiness Index. Eight weeks in, the Monday metrics argument ends, because everyone's reading the same table.

Related: Data Infrastructure for B2B → · Revenue Operations for B2B → · The Data practice →