You have a Databricks problem — a stalled migration, a DBU bill that doubled, a lakehouse that exists mostly in slides — and not enough senior hands to fix it. The market will happily sell you help. Some of it is excellent. Some of it is a certified logo wall in front of a bench of juniors. This guide is how to tell the difference before you sign anything.
Consultant, agency, or managed service?
Start by matching the shape of your problem to the shape of the help, because they price and fail differently.
- An independent consultant fits decision-shaped problems: architecture reviews, Unity Catalog migration planning, cost teardowns, performance triage, "is this design right?" You get one accountable senior, fast start, no overhead. It's what I sell on my consulting page, so weigh my bias accordingly.
- An agency or SI fits build-shaped problems: a 6–18 month delivery program that genuinely needs five-plus engineers, project management, and someone to absorb staffing risk. You pay a blended rate for that machinery — reasonable when you need the machinery, expensive when you needed one senior brain.
- A managed service provider (MSP) fits operate-shaped problems: you have a working platform but nobody wants to own patching, monitoring, job failures, and cost governance at 2 a.m. That's ongoing operations, not consulting — the model behind databricks.support.
Most bad engagements start with a shape mismatch: hiring an agency to answer a one-week question, or hiring a lone consultant to staff a year-long build.
What Databricks consulting actually costs
Nobody publishes audited numbers, so treat these as typical published and quoted ranges I see across the market in 2026 — useful for sanity-checking, not gospel:
- Independent freelance consultants: roughly $120–$300/hour. The low end is generalist data engineers with some Databricks exposure; the high end is genuine platform specialists who have led multiple production migrations. Above $300 exists but should come with a very specific, verifiable track record.
- Agencies and SIs: blended rates commonly $150–$250+/hour, quoted as day rates or fixed bids. Remember what "blended" means: you're averaging the partner you met in the sales call with the associates who do the typing.
- Offshore and nearshore teams: roughly $40–$90/hour. Real savings for well-specified execution work; a false economy for ambiguous architecture decisions, where a wrong call costs more in DBUs and rework than the rate saved.
Rate is the least interesting number. A $250/hour specialist who resolves your question in six hours beats a $90/hour team that takes three weeks and leaves you a deck. Compare cost-to-outcome, not cost-per-hour — and be suspicious of anyone who can't estimate the outcome.
10 interview questions that expose real Databricks depth
Certifications prove someone can pass an exam. These questions prove production time. You don't need to fully understand the answers — you need to hear specifics, tradeoffs, and war stories rather than marketing language.
1. "What actually changes when you migrate from hive_metastore to Unity Catalog?"
Weak answer: "better governance." Strong answer covers the three-level namespace (catalog.schema.table), rewriting grants because the permission model is different, external locations and storage credentials replacing mount points, cluster access modes, and the long tail of jobs with hard-coded two-part table names. Anyone who has done it will mention the tail.
2. "When does Photon pay for itself — and when doesn't it?"
Photon compute carries a higher DBU rate, so it only wins when the speedup beats the multiplier. Strong candidates say this unprompted: great for SQL-heavy, scan-and-join workloads; little help for Python UDF-bound or driver-bound jobs. If they present Photon as "always on, always faster," they've never checked a bill.
3. "DLT (Lakeflow Declarative Pipelines) or plain Jobs — how do you choose?"
Strong answer: declarative pipelines earn their premium when you want managed dependencies, expectations for data quality, and easy incremental processing; plain Jobs with notebooks or wheels win when you need fine-grained control, custom libraries, or the cheapest possible compute. The red flag is dogma in either direction.
4. "Liquid clustering versus partitioning and Z-ORDER — what's your default now?"
Strong candidates know that hand-tuned partitioning goes wrong constantly (high-cardinality keys, tiny files) and that liquid clustering is the modern default for new Delta tables precisely because it adapts without rewrites. They should also say when they'd still partition — very large tables with a stable, coarse filter key.
5. "What are the tradeoffs of serverless compute?"
Listen for both sides: near-zero startup time, no idle cluster babysitting, per-second billing — versus less control over instance types and networking, egress and connectivity constraints, and workloads where a right-sized classic cluster with spot instances is still cheaper. "Serverless everything" and "serverless never" are both wrong answers.
6. "A nightly job's cost doubled with no code change. Walk me through your first hour."
You want a concrete sequence: check data volume growth, look at the Spark UI for spill and skew, check whether autoscaling is flapping, compare cluster events, review recent table history for a compaction or vacuum gap. Vague answers ("I'd optimize the cluster") mean they've never been paged for this.
7. "How do you keep a large Delta MERGE fast?"
Strong answers mention file sizes and compaction, deletion vectors, pruning the source before merging, and clustering the target on the merge keys. Bonus points for knowing when to redesign into an append-plus-dedupe pattern instead of merging at all.
8. "How do you handle schema evolution across bronze, silver, and gold?"
They should describe permissive ingestion at bronze (schema evolution on, rescue columns), enforced contracts at silver, and deliberately versioned changes at gold — plus who gets woken up when an upstream team renames a column. Process answers matter as much as syntax here.
9. "What's your approach to controlling DBU spend across a workspace?"
Listen for: cluster policies as guardrails, auto-termination, job vs. all-purpose compute (running scheduled work on all-purpose clusters is the classic money leak), tagging for attribution, and system tables for monitoring. Anyone whose answer starts and ends with "buy a reserved commit" is selling, not engineering. If you want to calibrate their answer — or fix the bill yourself first — my 23-point Databricks cost optimization checklist covers exactly what a strong answer includes.
10. "Tell me about a Databricks engagement that went wrong."
The only wrong answer is not having one. Real practitioners have a migration that slipped, a streaming job that silently dropped late data, an optimization that made things worse. You're testing for honesty under pressure — the exact quality you'll need from them in month two.
Red flags that should end the conversation
- Certifications with no production stories. Certs are table stakes (I hold three Databricks certifications myself — they prove baseline knowledge, nothing more). If every answer cites a course instead of an incident, keep looking.
- "We'll need a discovery phase" for a one-hour question. Discovery is legitimate for large builds. When it's the answer to "why is this job slow?", it's a billing strategy.
- Bench-and-switch. You interview a principal, you get an associate. Ask directly: "Will the person in this call do the work?" Get the named delivery team in writing.
- No opinion on cost. Anyone senior on Databricks has strong, specific views on DBU economics. Silence on cost usually means they've never owned a bill.
- Rates only revealed after a sales call. Pricing that hides until you're emotionally committed is a negotiating tactic, not a service.
- Everything is a rebuild. If the first recommendation is to re-platform before they've read your Spark UI, they're selling a program, not solving your problem.
Match the engagement model to the problem shape
- One hard question (architecture call, go/no-go, cost review) → a paid session or two with a specialist. Hours, not weeks.
- A bounded fix (slow pipeline, failing migration step, UC permission mess) → a short fixed-scope engagement with a defined deliverable.
- Ongoing judgment (design reviews, "am I doing this right?" on tap) → a retainer or mentoring arrangement.
- A real build program → an agency or staff augmentation, ideally with an independent advisor sanity-checking the big calls.
- Keeping the lights on → a managed service like databricks.support, with SLAs instead of statements of work.
The checklist
Before you sign anything, you should be able to tick every box:
- The problem shape matches the engagement shape (question → consultant, build → team, operate → MSP).
- You know the rate and roughly what the outcome will cost — before any sales call.
- The person you interviewed is the person doing the work, in writing.
- They passed at least a few of the 10 questions above with specifics, tradeoffs, and at least one scar.
- They have public proof — talks, code, writing — not just logos and testimonials.
- The first deliverable is small enough that firing them after it costs you almost nothing.
That last point is the real safety net. Never start with a six-month commitment. Start with a session, a review, a week. Good consultants welcome small first engagements because they know the work will sell the next one.
Full disclosure: I'm one of the options
I'm Scott Bell — 3x Databricks certified, and I do exactly the consultant-shaped work this guide describes. My rates are published, sessions start at $350, and there's no discovery phase. Judge me by the checklist above.
Here's exactly what I charge →Or email scott@databricks.expert — and yes, feel free to open with question #10.