Data warehouse consulting: what you are buying

Data warehouse consulting is one thing: someone senior, from outside, taking responsibility for the part of your data stack that nobody inside owns. You buy it in three shapes — an assessment that tells you what to fix, a build or migration that does the fixing, or an ongoing seat that keeps it honest. If you already have a senior platform owner, or your data fits on one machine and nobody is complaining about the numbers, you do not need any of them.

What follows is the buyer's side of the table, written by someone who sells this. My prices are in here because you cannot compare what you are not shown. They are my prices, not the market's: I am a solo practitioner, and a twelve-person firm costs what a twelve-person firm costs.

What you are actually buying

Not hours. Not a warehouse — you can buy that yourself with a credit card in ten minutes. You are buying judgement about decisions that are cheap to make and expensive to unmake: what to model and how, where the data lands, what runs when a load fails at 3am, and which pricing choices turn into next year's bill.

That judgement gets sold in three shapes.

An assessment, or audit. A fixed-price week or two spent on your real systems, ending in a written plan. This is the right first purchase almost every time. It is small enough that a bad outcome costs you little, and it converts a vague worry into a ranked list with numbers on it. Mine is the Data Platform Audit: $3,000 fixed, 12–20 hours over one week, and I only recommend it after seeing your warehouse cost export. If day one shows no credible opportunity, you pay nothing.

A build or a migration. Someone builds the path — sources into a warehouse, warehouse out to dashboards people trust — or moves you from the warehouse you have to the one you should have. This is where the money is, and where the risk is, because the work is long enough that a bad fit takes months to become obvious. Mine is the Data Platform Build: $15–40k depending on scope, delivered in weeks, with the $3,000 audit fee credited in full. The honest comparison is the $150–200k fully-loaded cost of the senior hire you would otherwise make, and the months of recruiting before they write a line of code. I wrote that comparison out in full in consultant vs. full-time hire.

An ongoing seat. A day a week of senior attention after the platform exists: reviewing changes, deciding the hard ones, keeping the cost curve flat, and being the person your engineers can ask before they commit to something awkward. Mine is $3–4k a month, one day a week, advisory only, with a three-month minimum. Three months is not a lock-in tactic — a seat that ends in week six has only ever been an expensive opinion.

Most engagements should move down that list in order, and stopping after any step should leave you with something you can use.

What it costs, and how it is priced

The pricing model tells you more than the number does.

Firms usually price one of three ways. Time and materials — a day rate per person, billed as used. A statement of work — a fixed scope, a fixed price, milestones. Staff augmentation — bodies at an hourly rate, managed by you. All three are legitimate. They fail in different directions: time and materials rewards a slow start, a fixed scope rewards arguing about what "in scope" means, and staff augmentation quietly makes you the delivery manager for people you did not hire.

I price fixed or by milestone, and I do not publish a day rate. The reason is an incentive, not a secret: the faster and more experienced I am, the less an hourly model pays me, which rewards padding. The full reasoning, and the whole rate card, is in what data engineering costs and how I price it.

Whatever the model, insist on two things. The price should be attached to a deliverable you can describe in a sentence. And the range should be explained by drivers you recognise — number of sources, how clean they are, batch or streaming, how much modelling and testing the numbers need, whether governance is in scope. A range with no drivers behind it is not a range. It is a guess with a decimal point.

Before any of it, get your own number for what the warehouse itself costs. The Snowflake cost calculator on this site takes your real figures and gives you something to hold a proposal against.

What a good deliverable looks like

A good deliverable is specific enough that it could only have been written about your company.

Here is the shape I use. Every entry in the fix-list names the problem, what it costs, the fix and the effort, and the list is ranked so the first line is the best return on an hour. An illustrative entry, not from a client:

• Problem — the transformation warehouse auto-suspends after 10 minutes, but a scheduled job queries it every 9, so it never suspends.
• What it costs — the warehouse is billed as if it were always on, every hour of the month, and the settings page shows nothing wrong.
• Fix — batch the job to run hourly, or cut the suspend window to 60 seconds.
• Effort — under an hour.

Four lines, and you could act on it without the consultant in the room. That is the test. Alongside the list I deliver a cost model comparing current spend to a lean rebuild, a small proof-of-concept built on your own stack, and a written roadmap that is yours whether or not we work together again.

The proof-of-concept matters more than it sounds. A recommendation that has been run against your data has survived contact with the thing everyone underestimates: your data.

Questions to ask before you sign

Nine questions. Each one exists because the answer changes what you are buying.

1. Who is doing the work, and are they on this call? In firms, the senior who sells is often not the senior who delivers. That is not dishonest, but you should know which one you met.
2. What do I have in my hands at the end, and can I read it? Code, models, documentation, a roadmap. If the answer is "a presentation", the engagement ends when the meeting does.
3. Do you earn anything from the platform you recommend? Partner margin, referral fees, rebates, certification tiers. A partner can still be right — but you need to know the recommendation was not free of charge to them.
4. Which warehouse would you talk me out of, and why? Someone who has never advised against their default is selling one answer to every question.
5. What runs in week one? A real pipeline, end to end, however small. A first month of workshops is a month you find out nothing.
6. What happens when a load fails at 2am? This separates people who build platforms from people who build demos. Ask how the failure reaches a human.
7. What does this cost to run each month after you leave? Get the number before the build, not in the first invoice after it.
8. Who owns the code and the models? It should be you, with nothing licensed back and nothing phoning home. Mine is written down on how I work, along with payment terms, timezones and the liability cap.
9. What would make you tell me not to do this? Anyone with real capacity has work they turn down. Someone who can say no to you is someone whose yes is worth something.

Red flags

Platform-reseller incentives, undeclared. A partner earning margin on the warehouse they recommend has a thumb on the scale. Declared, it is a fact you can weigh. Undeclared, it is the reason the answer was always the same product.

A discovery phase with no written deliverable. Discovery paid by the week that ends in a verbal summary and a proposal for the next phase is a sales process you are funding.

Hourly bodies with no outcome attached. If the contract describes people and rates but not a result, you have hired staff without hiring staff — and the incentive runs the wrong way.

Architecture decks with no working code. A diagram is free to draw and has never once failed in production. Ask to see something running against real data before the big number is signed.

One reference architecture for every client. Watch whether their questions are about your business or about which of their templates you fit.

A migration proposal that starts before anyone asked whether you need the warehouse. This one is common enough that I wrote the decision framework separately: do you actually need a data warehouse?

A firm or an independent

Both are right, for different jobs. Being fair about this is the only way the rest of the post is worth reading.

Hire a firm when: you need several people at once and cannot wait; the programme spans multiple teams and needs coordination as much as engineering; procurement, security review or regulation requires a vendor with insurance, certifications and a formal process; you need a support contract with named response times; or the work must survive one person being ill for two weeks. A firm sells continuity, and continuity is a real product.

Hire an independent when: the job is one senior person's judgement applied quickly; you want the person who scoped the work to be the person who writes the code; the scope is clear enough that coordination is overhead rather than value; or the budget is real but not programme-sized. You also get a much shorter path from a question to an answer, because there is no one to escalate to.

The trade-offs are honest ones. An independent has a bus factor of one, no bench to surge from, and holidays. A firm has depth, process and cover — and you pay for all of it, including the people who are not on your project.

What both should give you is verifiable evidence rather than logos. Mine is that the systems I build are public and running: I run ClickHouse in production behind my own product Ansaar, and build on DuckDB, ClickHouse and Postgres depending on the workload. The systems page documents them so you can check the claims before you hire me, not after.

When you should not hire anyone

Three situations where the right answer is to keep your money.

You already have a senior platform owner. Then you do not need judgement bought in, you need their time protected. Hand them the checks from the audit, published in full — free, no email — and let them run it themselves. Most teams find something expensive in the first hour.

You have forty hours a week of data work, indefinitely. Then hire. A consultant is the wrong instrument for permanent, sustained demand, and $150–200k a year buys someone who accumulates context you cannot rent. Bring outside help in to scope the role if you like, but the role is the answer.

Nobody has decided what the company wants to measure. No warehouse fixes that, and no consultant can decide it for you. A week spent agreeing what the five numbers are that the business runs on is worth more than a quarter of engineering against a moving target.

And one softer case: if your data is small, your users are few, and your dashboards are fine — do nothing. A stack that matches the weight of the problem is allowed to be boring.

If you are weighing this up and want the outside view without buying anything, read what a data engineering consultant does day to day, or run the free teardown against your own stack. The scoping call is free and there is no pitch: two audits a month, one full-time engagement at a time, so it is in nobody's interest to sell you the wrong one.