Snowflake Up 37%, Databricks Up 80%

Data Engineer Skills

Databricks passed a $7B run-rate and Snowflake grew product revenue 37% to $1.49B. What the numbers say about Data Engineer platform skills.

Published: Proudly published by: Jeff Wahl9 min read

What this post covers

01

Snowflake Fiscal Q2 2027 Results: Product revenue, net retention, and $1M customer counts from the 8-K

02

Reading Platform Growth as a Hiring Signal: What vendor growth does and does not say about job demand

03

Why Run-Rate Is Not Audited Revenue: Company-defined metrics versus SEC-reported results and how to read both

04

Databricks Passes a $7B Run-Rate: Growth rate, funding round, valuation, and run-rate definition caveats

05

Three Quarters of Accelerating Snowflake Growth: Product revenue trend from Q4 FY26 through Q2 FY27

06

Lakebase Passes $100M Run-Rate: Managed Postgres adoption as a signal for OLTP skills

07

Platform Skills to Show in Data Engineer Interviews: Consumption cost awareness, governance, and cross-platform design questions

08

Compute Cost Pressure Behind the Growth: Rising warehouse spend and what it asks of engineers

Snowflake and Databricks both posted their strongest numbers in years within 3 weeks of each other. On August 13, 2026, Databricks said it passed a $7B revenue run-rate growing more than 80% year over year, and raised $5B at a $190B valuation.[1] On September 2, 2026, Snowflake reported fiscal Q2 2027 product revenue of $1.49B, up 37%, with net revenue retention of 126%, and raised full-year product revenue guidance to $6.07B, or 36% growth.[2]

If you've been waiting for the Snowflake vs Databricks fight to end with one winner, these numbers say you'll keep waiting. Both platforms are accelerating at the same time. For Data Engineers, that changes 3 things: which platform skills are worth building, which skills the growth is actually rewarding (cost control, mostly), and how much weight a vendor's growth should carry when you're reading a job posting or an offer.

I'll report the numbers first, then tell you what I think they mean. Some of these numbers are audited and some aren't; I'll flag which is which.

Prepare for the interview
01 / Open invite
02min.

Know the patterns before the interviewer asks them.

a system design query, the same shape a screen would give you.
The diff against expected. Where ties broke. What you missed.
sandbox
1source → bronze → silver → gold
2 ingest : CDC + Kafka
3 transform : dbt + Airflow
4 serve : Snowflake
5
Execute your solution0.4s avg.
PayPalInterview question
Solve a problem

What Snowflake and Databricks Reported

Snowflake Earnings Q2 Fiscal 2027

Snowflake's fiscal Q2 2027 ended July 31, 2026. Total revenue was $1.55B, up 35%; product revenue, the consumption business, was $1.49B of that.[2] Remaining performance obligations hit $9.00B, up 30%, and 828 customers now spend more than $1M in trailing 12-month product revenue, up 27%.[2]

The single quarter matters less than the trend. This is the third straight quarter of acceleration:

QuarterProduct revenueYoY growthNet revenue retention
Q4 FY2026 (ended Jan 31, 2026)$1.23B30%125%
Q1 FY2027 (ended Apr 30, 2026)$1.33B34%126%
Q2 FY2027 (ended Jul 31, 2026)$1.49B37%126%

Sources: Snowflake Q4 FY2026, Q1 FY2027, and Q2 FY2027 results.[4][3][2]

CFO Brian Robins put it this way in the release: "Q2 marks our third consecutive quarter of product revenue growth acceleration, driven by strength in both our core data platform and a meaningful step-up in AI revenue."[2] Full-year product revenue guidance moved from $5.84B to $6.07B.[2]

Databricks Revenue 2026

Databricks is private, so its disclosures come from a press release, not a filing. The headline: a run-rate above $7B, growth above 80%, and a $5B round led by Coatue with Blackstone, MGX, T. Rowe Price, and Sixth Street Growth among the participants.[1]

The product-level detail is more useful to a working engineer than the valuation. Databricks says its warehousing product passed a $1.5B run-rate growing over 100%, and Lakebase, its managed Postgres offering, passed $100M.[1] It also reported more than 1,000 customers above a $1M run-rate and more than 100 above $10M.[1]

So: 2 companies, both over 35% growth, both with their large customers spending more every year. Neither is eating the other.

Run-Rate Is a Company Metric; Read It Like One

Before you treat "$7B" and "$1.49B" as comparable, notice they measure different things.

Snowflake's $1.49B is one quarter of recognized revenue in an SEC-filed 8-K. Databricks' $7B is a run-rate: recent revenue annualized, usually a month times 12 or a quarter times 4. There's no standard definition, no auditor signing off on it, and no requirement that Databricks calculate it the same way twice. Multiply Snowflake's quarter by 4 and you get roughly $6B in product revenue, which puts the 2 companies closer in size than the headlines suggest.

None of that means the Databricks number is wrong. Private companies report this way, and Databricks has every incentive to keep the figure defensible ahead of any IPO. It means the Databricks number deserves a slightly wider error bar than the Snowflake number, and you should read it that way.

I learned this lesson the expensive way. Years ago I took an offer at a startup whose recruiter quoted an "ARR" figure in every call. Six months in, I was building the revenue pipeline and found out that ARR included signed-but-not-live contracts and a pilot that had already churned. The pipeline was fine. The number was marketing.

Takeaway: Audited quarterly revenue and self-reported run-rate both carry signal, but only one has an auditor behind it. When a company quotes growth at you in an interview, ask which kind it is.

The Margin Line Is Where Data Engineering Work Shows Up

The most interesting number in Snowflake's release gets the least attention. Non-GAAP product gross margin was 74.7% in Q2, and Snowflake cut its full-year margin guidance to 74% from 76%, attributing the change to increased AI workload utilization.[2] In the same release, it raised non-GAAP operating margin guidance to 14.5% from 13.5%.[2]

Here's my read. Customers are running heavier, more compute-intensive work on these platforms, and that compute costs the vendor more to serve. It costs the customer more, too. The customer is your employer, and the person who gets asked why the bill went up is you.

The survey data lines up with that. In dbt Labs' 2026 State of Analytics Engineering report, 57% of the 363 practitioners surveyed said warehouse and compute spend increased, while only 36% said their team budgets increased.[5] Spend is growing faster than the headcount meant to manage it.

Both vendors bill on consumption, so their growth and your employer's bill are the same number viewed from 2 sides. A 126% net revenue retention rate means the average existing Snowflake customer spent 26% more this year than last.[2] Some of that is new workloads that create real value. Some of it is a SELECT * on a 4XL warehouse that someone scheduled hourly and forgot about. I've personally found 2 of those in a single week at one job; between them they cost more per month than the analyst who wrote them.

Vendor Growth Is a Weak Hiring Signal on Its Own

The tempting conclusion is "Snowflake and Databricks are growing fast, so jobs on those platforms are growing fast." The evidence for that is thinner than you'd hope.

Snowflake's own headcount grew to 9,060 employees as of January 31, 2026, up 15.6% from 7,834 a year earlier, per its fiscal 2026 10-K.[6] That's healthy hiring, but in Q4 of that same fiscal year product revenue grew 30%.[4] Revenue is outrunning headcount at the vendor itself, and there's no reason to assume the ratio is better at the customers.

Vendor revenue tells you companies are spending more on these platforms. It doesn't tell you how many engineers those companies hire to run them. A team can double its Databricks spend by pointing 3 new AI workloads at it without adding a single person. I don't have a clean dataset that maps platform revenue to Data Engineer job postings, and I'd be suspicious of anyone who claims they do.

What the numbers do support: the platform market is expanding, existing customers are deepening their usage, and the work on these platforms is getting heavier. That's a good environment for engineers who already know the platforms well. It's a weak argument for cramming a certification as a job-search shortcut.

Analysts Are Slowing the Store Down

> Analytics queries against the production database are slowing the live application. Move analytics onto its own warehouse fed from the database's change log, while a merchant dashboard shows new orders within fifteen minutes on a path of its own.

+ Source
+ Transform
+ Storage
+ Quality
+ Consumer
+ Queue
Bronze
Silver
Gold
Custom
Pipeline Architecture
Sketch the architecture.

Click or drag a node from the toolbar above. Right-click the canvas for the full menu.

Drag from a node's right port to another node's left port to wire data flow.

Data Engineer Skills 2026: What the Numbers Point To

Cost Literacy Is the Skill the Growth Rewards

Every number above comes back to consumption. If you can explain where a team's credits or DBUs go, you're solving the problem the CFO is actually worried about. In interviews this shows up as follow-up questions: "this works, now what does it cost to run daily?" Most candidates freeze. Don't be most candidates.

On Snowflake, start with ACCOUNT_USAGE. This is the first query I run when I join a team:

-- Credits by warehouse over the last 30 days
SELECT
warehouse_name,
SUM(credits_used) AS credits_30d,
SUM(credits_used_compute) AS compute_credits,
SUM(credits_used_cloud_services) AS cloud_services_credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY credits_30d DESC;

On Databricks, the equivalent lives in the billing system tables. Tie usage to the jobs that generated it, because "the platform is expensive" isn't actionable and "job 4471 costs more than everything else combined" is:

-- DBUs by job over the last 30 days
SELECT
usage_metadata.job_id AS job_id,
sku_name,
SUM(usage_quantity) AS dbus_30d
FROM system.billing.usage
WHERE usage_date >= DATE_SUB(CURRENT_DATE(), 30)
AND usage_metadata.job_id IS NOT NULL
GROUP BY usage_metadata.job_id, sku_name
ORDER BY dbus_30d DESC
LIMIT 20;

Neither query is clever. That's the point. The skill underneath is the same one I've been preaching forever: understand the data model, understand the grain, know why a query scans what it scans. Pruning, clustering, partitioning, warehouse sizing, auto-suspend, job vs all-purpose compute; those are platform-specific knobs on top of the same concept. If you want to practice talking through those tradeoffs out loud, the Snowflake interview questions and Databricks interview questions are worth working through side by side.

OLTP Is Back on the Data Engineering Menu

A $100M run-rate is small next to $7B, but Lakebase is a Postgres product sold by an analytics company.[1] Databricks is betting that AI applications need transactional state living next to analytical data. Whether that bet pays off, it means more Data Engineers will be asked about indexes, transactions, and connection behavior; topics plenty of warehouse-only engineers haven't touched since their first job.

I came up through transactional databases before I ever saw a warehouse, and I've watched that background quietly become an advantage again. If row stores, isolation levels, and write patterns are fuzzy for you, brush up on OLAP vs OLTP fundamentals. You don't need to become a DBA. You need to not flinch when an interviewer asks why an agent hammering a table with point lookups behaves differently than a nightly aggregation.

Both Platforms, One Set of Concepts

Both companies are growing over 35% with expanding customers. My experience says a lot of those customers are the same customers. Plenty of teams run both: one for the serving layer, one for heavy processing and ML prep, with governance glued across the seam.

That pushes design questions toward "which workload goes where, and why," and that's a pipeline architecture question at heart. The candidate who can say "this table is read 10,000 times a day by dashboards and rebuilt once, so put it where concurrent reads are cheap" beats the candidate who recites feature lists. Concepts transfer across tools; tool knowledge doesn't transfer across concepts.

How Data Engineers Should Read Platform Signals in an Offer

When you're evaluating a team, the platform they run tells you less than how they run it. Here's what I ask now, after more interview loops than I'd like to admit:

  • Who owns the bill? If nobody on the data team can tell you last month's warehouse spend within 20%, you're inheriting a cost problem, and you'll be the one explaining it in a quarter.
  • Is spend growing faster than the team? Given the dbt Labs numbers, the answer is probably yes.[5] Ask whether there's a plan, or whether the plan is you.
  • Which platform is new and which is legacy? A team mid-migration between Snowflake and Databricks is a great place to learn and a terrible place to have a quiet quarter.
  • If the company quotes growth, which kind? Audited revenue, run-rate, ARR, "bookings." Ask. The answer tells you how the leadership talks about numbers internally too.

None of these questions will cost you an offer. Asking about cost ownership has helped me in every loop where I've done it; it signals you've been the one paged for a runaway bill before.

What to Watch Next

3 things will tell you whether this trend holds:

  • Snowflake's Q3 FY2027 report. A fourth straight quarter of acceleration would confirm the trend in the table above. Watch product gross margin alongside it; if margin keeps sliding while revenue climbs, AI workloads are getting heavier, and so will the cost conversations at your job.
  • Any Databricks S-1. If Databricks files to go public, you'll finally see audited revenue next to the run-rate figures. That's when the error bar on "$7B" closes.
  • Lakebase adoption. If managed Postgres inside the lakehouse keeps growing, OLTP knowledge moves from nice-to-have to expected in Databricks-heavy shops.

In the meantime, don't pick a side; both sides are winning. Pick the concepts under both: data modeling, query cost, and the ability to explain where the money goes. Then practice saying it out loud on real practice problems, because the platform that wins the next 5 years will still bill your employer per query, and somebody will still need to explain the invoice.

References

  1. Databricks, "Databricks grows >80% YoY, surpasses $7B revenue run-rate," August 13, 2026. databricks.com
  2. Snowflake via Business Wire, "Snowflake Reports Financial Results for the Second Quarter of Fiscal 2027," September 2, 2026.
  3. Snowflake via Business Wire, "Snowflake Reports Financial Results for the First Quarter of Fiscal 2027," May 27, 2026.
  4. Snowflake via Business Wire, "Snowflake Reports Financial Results for the Fourth Quarter and Full-Year of Fiscal 2026," February 25, 2026.
  5. dbt Labs, "2026 State of Analytics Engineering Report," April 2026. getdbt.com
  6. Snowflake Inc., "Form 10-K for fiscal year 2026," SEC EDGAR. sec.gov

Snowflake vs DatabricksDatabricks revenue 2026Snowflake earnings Q2 fiscal 2027data engineer skills 2026data engineering platform demand
02 / Why practice

Try the actual problems

  1. 01

    Reading a solution is not the same as writing one

    Every engineer who has frozen on a query they had read a dozen times knows the gap. The only preparation that closes it is producing the answer yourself, under time, before the interview does it for you

  2. 02

    76% of hiring managers reject on the coding task, not the resume

    From HackerRank's 2024 Developer Skills Report. Candidates who look strong on paper still fail the live screen if they haven't done timed, executable practice

  3. 03

    System design comes down to the calls you defend out loud

    Ingestion, batch vs streaming, the bronze/silver/gold layers, idempotency, backfill and replay. Sketching the pipeline and naming the failure modes is the signal, not the boxes