Pyvorin vs CPython: A Total-Cost View

A total-cost comparison lives or dies on one discipline: the benchmark speedup is an input to the model, never the answer. Production cost depends on utilisation, concurrency, fixed capacity and architecture, so a measured runtime improvement converts to money only where your spend actually scales with the accelerated workload. This page builds a three-year total-cost view of running the same Python batch estate under CPython alone versus under CPython with Pyvorin, with every assumption stated and every savings figure labelled as modelled — class C, never presented as measured.

The model below is illustrative. It exists to show the shape of the calculation and the sensitivity of its answer, not to predict your bill. Swap in your own measured speedup, your own pricing and your own utilisation, and the arithmetic will serve you better than any number we could quote.

What total cost actually includes

Three cost lines dominate a compiled-Python decision over a three-year horizon.

Compute. Instance-hours, or their reserved-capacity equivalent. This is the line a speedup can move, and only the portion attributable to the accelerated workload counts — a shared cluster running databases, queues and your Python batch jobs does not shrink in proportion to the batch jobs alone.

Licence. Pyvorin's published pricing at the time of writing: Free £0, Starter £49 per month, Team £129 per month, Business £399 per month, and Enterprise on custom terms. Annual billing is priced at ten times the monthly figure (Business, for example, is £3,990 per year). Every plan carries a trial — 7 days on Starter and Team, 14 days on Business and Enterprise — which is long enough to measure your own workloads before any money moves.

Engineering time. Setup, verification and ongoing cache management. Compilation happens locally and in-process, and unsupported constructs fall back to honest CPython behaviour rather than crashing, so this line is measured in days, not quarters — but it is not zero, and a serious model does not pretend it is.

The illustrative model

Assumptions, stated in full:

• A nightly batch fleet of 10 compute instances, assumed to cost £0.40 per instance-hour. That price is an assumption, not a quote; replace it with your negotiated rate.
• The fleet runs 8 hours per night, 365 nights per year: 29,200 instance-hours per year, or £11,680 per year of compute.
• All 10 instances are attributable to the Python workload under consideration. If only half your fleet runs this workload, halve every compute figure that follows.
• Measured speedup is unknown until you measure, so three scenarios borrow figures from the published suite purely as placeholders: the suite median (1.35x), a round 2.0x, and the suite geomean (3.16x). None of them is a promise about your code.
• A realisation factor converts the theoretical resource reduction into an expected bill reduction, because infrastructure is not perfectly elastic: 50% in the conservative case, 70% expected, 85% upper. The theoretical reduction implied by a speedup s is (1 − 1/s); the modelled reduction is that figure multiplied by the realisation factor.
• Licence: Business at £399 per month (£4,788 per year), chosen because it is the published tier most teams evaluating a 10-instance estate land on. Enterprise is custom-priced; the Free and Starter tiers exist if the estate is smaller.
• Engineering: 3 days of one engineer's time in year one at an assumed £500 per day — an assumption — then 1 day per year for cache and version maintenance. No salary figure in this model is anything other than an assumption you should replace.

Read the last row slowly. Under conservative assumptions the honest answer is do not buy: a 1.35x-class result on this fleet does not cover a Business licence. The expected case is roughly break-even. Only the upper scenario — geomean-class speedup, high realisation — turns clearly positive. That is not a weakness of the model. That is the model working.

What moves the answer

Four inputs dominate the sensitivity, in order of leverage.

Your measured speedup. The single largest lever, and the only one you control before purchasing. Run python -m pyvorin bench against your actual entrypoints during the trial. The difference between a 1.35x workload and a 3x workload is the difference between the red and black rows above.

The realisation factor. Batch fleets that autoscale to zero convert runtime into cost almost one-for-one; fixed reservations convert it into headroom first and cost only at renewal. Be conservative here on purpose.

Workload attribution. If the Python workload occupies a third of a shared estate, the compute line that can move is a third as large. Models that forget this overstate savings by whole multiples.

Tier selection. The Free tier costs £0 and Starter is £49 per month. An estate that fits those tiers changes the licence line by an order of magnitude; the illustrative model used Business because a 10-instance fleet usually needs it, not because it is the default answer.

ROI, payback and honest arithmetic

The commercial summary of the model is two formulas, both of which fit on one line:

ROI = (modelled_saving − cost) / cost × 100%
payback_months = annual_cost / monthly_net_saving

Both formulas return garbage when fed a speedup instead of a saving, which is why the conversion rule comes first. In the expected scenario above the payback is immediate but the three-year net is negative two thousand pounds — the model telling you the truth at two different time horizons. A negative monthly net saving means payback never arrives, whatever the ROI formula outputs; a model that cannot say “do not buy” is not a model, it is a sales aid.

The practical sequence is short. Measure during a trial, feed the measured figure and your realisation factor into the table above, and let the conservative row carry the decision. If the conservative row says no, the answer is no — regardless of what the upper row promises.

Where the model breaks

Three cases invalidate the arithmetic entirely. If the workload is I/O- or library-bound — string parsing, URL routing, short-string compression — the published suite shows results at or below 1x, and the correct decision is no purchase. If capacity is fixed and not up for renewal, savings do not exist; there is only headroom. And if the workload cannot be compiled at all, the honest fallback keeps CPython behaviour, which is free and also worth nothing.

The model also says nothing about throughput value. A nightly job that finishes in two hours instead of four may matter more for the 6 a.m. report than for the bill. If that value is real to your business, model it separately and label it separately — do not fold it into the compute line to make the arithmetic blush.

Where to go next

• Benchmarks — the measured results that feed this model, reported in full.
• Benchmark methodology — which compiler path produced each published figure, and why it matters here.
• How to benchmark a function — replace the placeholder speedups with your own measurements during the trial.
• Pyvorin vs CPython — what changes and what stays the same when compilation joins the runtime.

Last reviewed 12 March 2026. All savings figures on this page are class C (modelled) from the labelled illustrative model above; pricing figures are class A from the published plan table (Free £0, Starter £49/mo, Team £129/mo, Business £399/mo, Enterprise custom; 7- or 14-day trials). No customer cost data was used.