Is Photon worth it? Databricks Photon cost break-even explained

Short answer: Photon pays off when it speeds your job up by more than it raises the hourly cost. On classic compute, Photon multiplies the DBUs an instance burns per hour, but the VM price stays the same. At today's list prices that puts the break-even at roughly 1.54× to 1.86× faster for common 8-vCPU instances. Databricks says Photon helps most on long-running queries over large datasets, and little on queries that finish in under two seconds. Measure before you decide.

How Photon is priced

Photon doesn't have its own line item. Databricks says "Photon instance types consume DBUs at a different rate than the same instance type running the non-Photon runtime" (Databricks docs). In our data, the $/DBU for Photon SKUs equals the standard rate (for example $0.15 for AWS Jobs Premium). What changes is the DBU count per hour:

• AWS m5d.2xlarge, Jobs Compute: 1.37 → 3.97 DBU/hour (2.90×).
• Azure D8ds v5, Jobs Compute: 2 → 5 DBU/hour (2.50×), from the Photon multiplier in Microsoft's pricing feed.
• All-Purpose Compute uses a lower multiplier than Jobs on all three clouds in our data (see the table below).

Photon is always on for SQL warehouses and serverless compute, so there's no decision to make there. The decision is on classic jobs, all-purpose and pipeline compute, where "Databricks enables Photon by default" in the UI, while the Clusters and Jobs APIs need runtime_engine set to PHOTON explicitly (Databricks docs). If your team clicks through the UI, you're probably paying Photon rates already, measured or not.

The break-even formula

Photon pays off when the job runs at least this many times faster:

break-even speed-up = (Photon DBU/h × $/DBU + VM $/h) ÷ (standard DBU/h × $/DBU + VM $/h)

The VM term is the part most people forget. Photon doesn't make the VM more expensive, so the more of your bill is VM, the lower the bar. That's why the break-even is well under the raw DBU multiplier:

Per node, Premium tier, on-demand VM list prices in us-east-1 (N. Virginia), Azure East US and GCP us-central1 (Iowa). The DBU-only ratio is what you'd need if VMs were free.

Across all 271 AWS instance types with Photon ratings and EC2 prices in us-east-1, the Jobs Compute break-even ranges from 1.50× (m6idn.12xlarge) to 1.90× (i8g.metal-24xl), with a median of 1.71×. Instance choice moves the bar a lot.

What speed-up should you expect?

There's no honest single number. Here's what Databricks itself claims, all vendor figures on their chosen workloads:

• "An additional 2x speedup per the TPC-DS 1TB benchmark," and "customers have observed 3x–8x speedups on average, based on their workloads" (Databricks Photon page).
• Photon "provides the greatest benefit for longer-running queries that process large datasets." Queries that "normally complete in under two seconds don't see meaningful improvement" (Databricks docs).
• Photon doesn't support UDFs, RDD APIs or Dataset APIs, and it doesn't support stateful streaming. Unsupported operations fall back to the regular Spark engine (Databricks docs). You keep paying the Photon DBU rate on those parts, with no speed-up.

Treat these as a reason to test, not a forecast. A Python-UDF-heavy job might see almost nothing, while a big join-and-aggregate SQL job can clear the break-even easily.

Worked example

Example with assumed speed-ups, not measurements. Assumptions: AWS us-east-1 (N. Virginia), Premium Jobs Compute, 1 driver + 4 workers of m5d.2xlarge (8 vCPU, 32 GB), on-demand EC2. The cluster costs $3.29/hour without Photon and $5.24/hour with it, so the break-even is 1.59×. For a job that takes 60 minutes without Photon:

The pattern holds everywhere. Below break-even, Photon finishes faster but costs more. Above it, you save money and time. If the job sits on a critical path, a faster finish at a slightly higher cost can still be the right call. Just make it on purpose.

How to test Photon on a real job

1. Pick a job that runs regularly and takes more than a few minutes. Databricks suggests jobs that run regularly "should be evaluated to see whether they are not only faster but also cheaper with Photon" (Databricks docs).
2. Run it a few times with Photon off and on, same cluster, same data volume. Use the median runtime.
3. Check how much actually ran in Photon. In the Spark UI, Photon operators show in orange (docs). Lots of fallback means you're paying for little.
4. Compare DBUs in system.billing.usage, which flags Photon usage in product_features.is_photon (docs). Add VM hours from your cloud bill.
5. Divide the old runtime by the new one and plug that speed-up into the calculator.

Rules of thumb

• Keep Photon on heavy SQL/DataFrame ETL, large joins and aggregations, and Delta writes and MERGEs.
• Test turning it off on Python-UDF or RDD-heavy jobs, small jobs that finish in seconds, and stateful streaming.
• Check your VM prices. If you run spot or reserved VMs, your VM term is smaller, so the break-even rises toward the DBU-only ratio. Enter your real VM price in the calculator.
• Don't compare Photon in isolation. If you're also weighing serverless (which always runs Photon), read serverless vs. classic.