Batch Job Cost Optimisation

Batch jobs are the clearest case where a runtime improvement becomes money. A service must stay up all day; a batch job only needs to finish before its deadline. If the pipeline shortens, you can run fewer instances for less time, move to cheaper interruptible capacity, or pull the job out of expensive peak-rate windows entirely. Every savings figure on this page is class C — modelled, with assumptions stated, never a customer result. The one number that is not modelled is the speedup, and even that has to come from measuring your own pipeline.

Why batch converts cleanly

The conversion rule for compute spend is simple: shorter runs convert to lower cost only where spend scales with the accelerated workload. Batch infrastructure usually passes that test better than any other shape. Instances are spun up for the job and torn down after it; the bill is instance-hours times hours; halve the hours and the bill follows. There is no minimum fleet, no warm pool, no reserved baseline — unless you chose one.

Two preconditions still apply. The job must be CPU-bound in Python execution: the published suite's weaker categories — string parsing, short-string compression — sit at or below 1x, and an I/O-bound pipeline gains nothing. And the job must be measurable: one python -m pyvorin bench run against the real entrypoint, on real data, beats any suite statistic as a planning input.

An illustrative model

Assumptions, stated in full:

• A nightly ETL pipeline runs on 10 instances, assumed at £0.40 per instance-hour — an assumption, not a quote.
• It runs for 6 hours per night, every night: 60 instance-hours per night, £24 per night, £8,760 per year.
• Measured speedup of 2.0x on this pipeline — an assumption chosen to be ordinary; the suite median is 1.35x and its geomean 3.16x, so bracket your own measurement between pessimism and hope and plan on the measured number.
• Elastic infrastructure sized to the job, so the modelled bill reduction equals the theoretical resource reduction of 50%, with no realisation discount.
• Licence: Team at £129 per month, £1,548 per year — chosen as the published tier a single pipeline team would typically start from; trials run 7 days on Team and 14 on Business, so the measurement can happen before payment.

The modelled net saving is £2,832 per year for one pipeline, with payback inside the first month of the licence. The arithmetic is trivial. The discipline is not using a faster number than you measured: had the pipeline measured 1.35x instead of 2.0x, the modelled annual compute would fall to £6,489 and the net saving to £723 — still positive, but a different decision if the engineering time to wire compilation into the pipeline costs more than that.

The spot lever

Interruptible spot capacity sells at a discount in exchange for the possibility of reclaim. Job length drives the risk: a six-hour job meets far more interruption windows than a three-hour one. Halving the job does not just halve the bill at the on-demand rate — it can qualify the job for deeper-discount capacity pools that were previously too risky, because the whole run now fits comfortably inside the interruption horizon. Model spot pricing with your own cloud's reclaim statistics; no figure here invents one.

Spot discipline is a property of the pipeline, not the compiler. Checkpoints or idempotent stages let a reclaimed job resume instead of restart, and the job is only spot-eligible if every stage is. A pipeline whose final stage cannot be retried safely belongs on on-demand capacity whatever the speedup says — one corrupt nightly output costs more than a year of instance discounts.

The scheduling lever

A pipeline that finished at 4 a.m. under CPython and finishes at 1 a.m. under Pyvorin is not just cheaper — it is movable. Work that previously straddled the boundary of peak-rate windows can be pulled fully into off-peak hours, and jobs blocked behind the nightly pipeline get a three-hour head start. Whether that is worth money depends on your provider's rate structure; it is a scheduling benefit first and a billing benefit only where peak and off-peak prices differ.

Shorter jobs also change failure economics. A nightly pipeline that overruns its window forces a choice between late data and a daylight rerun at peak rates. A job with three hours of slack absorbs an overrun that would previously have cost a full rerun — availability, in effect, purchased with runtime rather than hardware.

Before you bank it

Three checks turn the model into a plan. Verify correctness on real data: the bench command compares compiled output against the CPython oracle and reports correct: True before timing anything — keep that record. Confirm amortisation: compilation time is reported separately, so a job called nightly absorbs its compile cost hundreds of times over, while a monthly job barely does. And re-measure after any source change, because a new data dependency can move the pipeline from the suite's winning categories into its losing ones. Batch cost optimisation is a loop, not a purchase.

The loop needs an owner. In practice the pipelines that keep saving money are the ones with a dashboard and a quarterly re-measurement habit, and the ones that quietly stop saving money are the ones where the compiled function was refactored away six releases ago and nobody noticed. Assign the pipeline, not just the project.

Where to go next

• How to benchmark a function — measure the pipeline before changing anything.
• Benchmarks — the suite results, including the categories that do not win.
• Pyvorin vs CPython: a total-cost view — scaling the same model across an estate.
• Unsupported code and the fallback path — what happens to the parts of a pipeline that do not compile.

Last reviewed 20 March 2026. All savings figures are class C (modelled) from the labelled illustrative model above; benchmark inputs are class B from the canonical 2026-09-13 artefact; the licence figure is class A from the published plan table. No customer pipeline data was used.