The bill you were quoted is the third-largest line
When someone asks what a data warehouse costs, the answer they usually get is the cloud bill: a few hundred dollars a month, sometimes a couple of thousand. That number is generally accurate and it is also the smallest of the three costs you will carry. The big one is people, twice — once to build the thing and again, every year afterwards, to keep it working while the systems feeding it change underneath. A budget with only the infrastructure line in it will be wrong by roughly an order of magnitude, and it will be wrong in the direction that gets a project defunded in month eleven.
This is a straight cost article for someone who has to defend a number to a board, a CFO or an investment committee. The ranges below are ours, from work at this size, and they are ranges rather than prices because the spread is real. Vendor list prices move, so we describe how each pricing model charges you rather than quoting figures that will be stale by the time you read them — the model is what determines your bill anyway, far more than the headline rate.
You are probably here because
- Two proposals differ by 4x and you cannot tell what the difference buys
- Someone quoted "about $500 a month" and you suspect that is not the whole story
- Your cloud bill tripled in a month and nobody changed anything obvious
- You need a three-year number for a board paper by Friday
The three-line breakdown below is the shape of the answer. The worked example near the end is a three-year total you can adapt.
Three lines, and only one of them is the cloud bill
Build. The one-time cost of getting from nothing to a working set of reports people trust. Almost entirely people: connecting source systems, modeling the data, defining the metrics, reconciling the output against whatever the business uses today. This is where the majority of year-one money goes.
Run. The recurring bill: storage, compute, the tools that move data in, and per-seat licenses for whatever people look at it with. This is the number vendors quote, and at a company under a few hundred people it is usually the smallest of the three.
Maintain. The recurring people cost of keeping it correct. Source systems get new fields, a vendor changes an export format without warning, the business changes how it counts something, a load fails at four in the morning. This line is invisible on day one and is the one that decides whether the platform is still trusted in year three.
Ranges by company size
Assume three to six source systems — a CRM, a finance system, an operational database, perhaps a support tool and a payroll system — and a first release covering ten to twenty defined metrics. Assume senior engineers at US rates, which for this work generally run $150 to $250 an hour however they are billed.
| Company size | Build (one-time) | Run (per month) | Maintain (per year) |
|---|---|---|---|
| 20–50 people 2–4 sources, 8–12 metrics | $35,000–$80,000 | $300–$1,200 | $10,000–$25,000 |
| 50–250 people 4–8 sources, 15–30 metrics | $80,000–$200,000 | $800–$4,000 | $25,000–$60,000 |
| 250–1,000 people 8–20 sources, several teams reading | $200,000–$600,000 | $3,000–$20,000 | $60,000–$200,000 |
| Multi-entity or post-acquisition Two of everything, different definitions | Add 40–80% | Add 20–40% | Add 30–60% |
The run column excludes per-seat reporting licenses, which are usually $20 to $80 per user per month and scale with how many people you give access to rather than with how much data you hold. Give it to forty people at $50 and that is $24,000 a year, which is more than the warehouse itself at the smaller sizes. It is also money well spent if those forty people stop asking someone to run a query for them.
The multi-entity row is the one most often missed in a budget. Two companies that were merged have two definitions of a customer, two chart-of-accounts structures and two sets of historical data with different quality. The engineering is not much harder. The agreement is, and agreement takes calendar time that lands on the build line.
What actually moves the infrastructure bill
Not the amount of data you have. That surprises people, and it is the single most useful thing to understand before you sign anything. Storage is close to free at these volumes — object storage runs a few cents per gigabyte per month, so a company holding a terabyte is spending tens of dollars, not thousands. What you pay for is work: how often something reads the data, and how much of it each read touches.
That means the bill is driven by refresh frequency, by how many dashboards auto-refresh, by whether queries are written to read a slice or the whole table, and by how long compute sits idle waiting for the next request. Two companies with identical data can differ tenfold on the same platform for those reasons alone.
What drives the monthly bill — our ranking at this company size
Our ordering for companies between twenty and a thousand people. Storage last is not a typo; at these volumes it is a rounding error.
The three pricing models, in plain terms
Pay for what each query reads. You are charged by the volume of data each query touches. It is genuinely cheap for light, occasional use, and it punishes carelessness precisely: a dashboard that reads an entire history table every fifteen minutes costs the same as an analyst doing it, and it never gets bored. The lever is how the tables are laid out, so that a query for last month reads last month rather than eight years.
Pay for the time compute is switched on. You are charged for the seconds a cluster runs, so the controls that matter are how quickly it suspends when idle and how large you sized it. A cluster set to stay warm for ten minutes after each query, hit by a job every eleven minutes, is paying for a full day. Turning that idle window down is often the largest single saving available on this model, and it takes minutes.
Pay a fixed rate for reserved capacity. A set monthly amount whether or not anyone runs anything. Predictable, which finance likes, and wasteful at small scale, because a warehouse serving thirty people is idle most of the day. It becomes the cheaper option once usage is heavy and steady enough that the reserved capacity is genuinely busy.
You do not need to pick correctly on day one, and you should not agonize. What you should do is put a spend alert on the account in the first week and look at the bill every month for the first quarter. Almost every runaway bill we are asked about was visible in the second week and noticed in the fourth month.
Where the surprise charges come from
A dashboard that refreshes for nobody. A reporting tool set to refresh every widget every fifteen minutes, on a page four people open on Mondays, generates thousands of queries a week. Set refresh from usage, not from habit.
Development environments nobody turned off. A copy of the warehouse spun up for a migration and left running is the most common single line item in a bill that doubled. Put an expiry on anything created for a project.
Row-priced data movement. Tools that charge by rows changed are excellent value on stable tables and brutal on one particular kind: a table your operational system rewrites nightly, where every row counts as changed every day. One table can dominate the invoice. Check which of your tables behave that way before signing an annual commitment.
Seats handed out generously. Per-user licensing is fine until the count doubles quietly. Review the seat list quarterly and reclaim the ones nobody has opened in ninety days — every vendor's admin console can tell you.
Egress on the way out. Moving large volumes out of a cloud provider is charged, and it shows up when you migrate or when a partner pulls a bulk extract regularly. It is rarely large at this size, but it is the one that arrives without warning.
The people line, and why it is the big one
Roughly seventy to eighty-five percent of the three-year cost of a data platform at this size is people. That ratio is worth internalizing before comparing proposals, because it means the choice between two platforms whose bills differ by a few hundred dollars a month is nearly irrelevant next to the choice of who builds it and how much maintenance the design creates.
A well-built platform is cheap to own: few moving parts, loads that are easy to re-run when they fail, transformations someone else can read, and a written definition for every metric. A badly built one is expensive forever, and the expense is not visible in any invoice — it appears as an engineer spending a third of their week on breakages, which is a $60,000 to $90,000 annual cost hiding inside a salary line.
That is also the main argument for spending more on the build than the cheapest quote. The gap between a $60,000 build and a $110,000 build is usually the reconciliation, the tests, the failure alerting and the written definitions — precisely the things that determine the maintenance line. Buying the cheaper one often means paying the difference every year instead of once.
Want the three-year number for your own situation?
Email your source systems, roughly how many people would read the reports, and the metrics you need to contact@precisionfederal.com. You get back a written build, run and maintain estimate with the assumptions stated, in one business day. No charge and no meeting.
contact@precisionfederal.comA worked three-year total
A composite, not a client: a 120-person services business with a CRM, a finance system, an operational database and a support tool, wanting eighteen defined metrics and thirty people reading reports.
| Line | Year 1 | Years 2–3 each | Note |
|---|---|---|---|
| Build | $120,000 | — | About 10 weeks of one senior engineer plus part-time business owners |
| Warehouse and pipeline tooling | $18,000 | $21,000 | Grows with data movement, not headcount |
| Reporting seats | $14,400 | $16,800 | 30 seats at $40, growing to 35 |
| Maintenance | $15,000 | $30,000 | Partial in year one; roughly 25% of build thereafter |
| Total | $167,400 | $67,800 | Three-year total about $303,000 |
Two things to take from that table. The infrastructure and tooling line is about eleven percent of the three-year total, so optimizing it hard is not where the money is. And year two and three together cost more than the build, which is the fact most often absent from a board paper. If your three-year case only funds the build, it is not a case, it is a first instalment.
When not to build one
The honest answer is sometimes no, and a firm that never says it is not giving you advice.
One system holds nearly everything. If ninety percent of what you need to report lives in one platform, its own reporting is probably sufficient and a warehouse adds a copy to keep in sync. Revisit when the second system starts mattering.
The question is a handful of numbers. Three recurring figures can often be produced by a scheduled script writing into a shared sheet, for a few thousand dollars, running for years. Not fashionable, entirely adequate.
A source system is about to be replaced. Building on the outgoing CRM buys work you will discard. Wait, and spend the interval writing metric definitions, which survive the migration.
The disagreement is about definitions. If nobody can say what an active customer is, a warehouse will report the confusion faster. Settle the definitions first; see a single source of truth people actually use.
What to ask before you sign
- Which of build, run and maintain does this quote cover, in writing
- What the monthly bill looks like at three times current usage
- Which tables are rewritten wholesale each night, if the tool is row-priced
- What annual commitment is required and what happens if usage stays flat
- Who maintains this in year two, by name, and at what cost
- What we own at the end — code, models and definitions, in our repository
- What it takes to leave — how the data comes out and at what egress cost
The ownership question is worth pressing. Transformations expressed in a vendor's proprietary interface are not portable, and a platform you cannot leave will be priced accordingly at renewal. Plain SQL in your own repository, with the definitions written down beside it, is the cheapest insurance in this whole budget.
Budget mistakes we see most
- Funding the build with no maintenance line, then calling the decay a technology failure
- Comparing quotes that cover different scopes and picking the smallest number
- Optimizing the platform bill while the people line is five times larger
- Signing an annual commitment before a month of real usage exists
- Counting the reporting seats as free because they are billed to a different budget
- No spend alert, so a runaway job is discovered on an invoice rather than on the day
- Treating the pilot bill as the steady-state bill; usage roughly doubles once people trust it
Bottom line
At twenty to a thousand people, a data warehouse is a people cost with a modest cloud bill attached. Expect the build to run tens of thousands at the low end and low hundreds of thousands at the high end, the infrastructure to be a few hundred to a few thousand a month, and maintenance to run fifteen to twenty-five percent of the build every year forever. Budget all three or the project will be defunded around month eleven, when the invoice for a year of upkeep meets a business case that only ever funded the build. And spend your negotiating energy on scope, ownership and who maintains it — not on shaving the smallest line on the page.
Common questions on the budget
Two proposals differ by four times. What usually explains it?
Almost always scope, and specifically the invisible parts: reconciliation against what the business uses today, tests, failure alerting, written definitions and handover. The cheap proposal usually delivers working dashboards; the expensive one delivers dashboards someone has proven correct and someone else can maintain. Ask both to state what happens when a load fails at 4 a.m. and who finds out. The answers will explain most of the gap.
Can we start smaller and grow into it?
Yes, and you should. A first release covering eight to twelve metrics from two or three systems is a genuine deliverable, it costs a fraction of the full build, and it tells you whether the organization actually changes its behaviour. What does not work is starting smaller on quality — skipping reconciliation and tests to save two weeks produces a platform nobody trusts, which is not a smaller version of the outcome, it is a different one.
Is an in-house hire cheaper than an outside team?
Over three years, often yes on the raw arithmetic; a data engineer at market salary plus overhead is real money but it buys full-time capacity. The catch is that one hire is a single point of failure, recruiting takes three to six months, and the first hire will design the platform they know rather than the one you need. A common middle path is an outside team for the build with an internal owner alongside them from week one, who inherits it.
Our bill tripled last month and nothing changed. What happened?
In our experience the usual suspects are, in order: a dashboard refresh schedule someone turned up, a development environment left running, a table that started being rewritten in full each night, and a query that used to read a partition and now reads everything after a change upstream. All four are visible in the platform's own query history within a day. Set a spend alert first, then look at the ten most expensive queries of the month; that list almost always contains the answer.
Frequently asked questions
For twenty to fifty people with two to four source systems, the platform and pipeline tooling typically runs $300 to $1,200 a month, plus $20 to $80 per user per month for whatever people read reports with. That is the recurring infrastructure only. The build that gets you there is usually $35,000 to $80,000, and maintenance afterwards runs $10,000 to $25,000 a year.
Because storage at these volumes is a few cents per gigabyte per month, which is negligible, while every query consumes compute that is billed either by the data it reads or by the seconds the cluster runs. A company with a terabyte and heavy dashboard refreshes will pay far more than a company with ten terabytes that is read twice a day. Refresh frequency and query shape are the levers, not volume.
Fifteen to twenty-five percent of the build cost per year, and closer to the top of that range if you have many source systems or vendors who change their exports. It covers source-system changes, definition changes, failed loads and the ordinary drift of a live system. A platform funded with no maintenance line degrades quietly for around nine months and is then written off as a failed investment.
Scope, by a wide margin. The major cloud warehouses are all more than adequate for a company under a thousand people, and the difference between them is smaller than the difference between a well-defined and a vague set of requirements. Pick the one your team can already operate or your cloud provider already bills you for, and spend the saved deliberation on deciding which metrics matter.
Keep transformations as plain SQL in your own version control rather than inside a vendor's proprietary editor, keep raw extracts in your own cloud storage, and write metric definitions in a document that is not attached to any tool. Then ask, before signing, exactly how data comes out and what the egress costs. Portability is mostly a matter of where the logic lives, and it is far cheaper to arrange at the start than to retrofit at renewal.