What a PDF render costs: compute is the cheap part

We wanted to know, not guess, what producing one PDF costs. This post is the measurement we did on 3 November 2026, using list prices for serverless compute in Mumbai. Prices will drift, but the shape of the result is what matters, and it surprised us.

The setup being priced

Rendering runs on a native Typst 0.15.1 compile service in Mumbai, on arm64 serverless compute with 2 GB of memory and a 70 second ceiling. In front of it sits the API itself, which handles authentication, quotas, the database, 24-hour PDF storage and the async queue. The compile service is the part that scales with every render, so that is what we measured first.

Three documents, three very different renders

Document	Pages	PDF size	Compute time	Peak memory
Invoice	2	14 KB	about 4 ms	46 MB
Report	30	539 KB	about 305 ms	109 MB
Long report	300	5.4 MB	about 3.6 s	690 MB

Compute is billed by memory multiplied by time, so a two-page invoice costs almost nothing to compute. The 300-page report costs about a thousand times more to compute.

Picking the memory size

Serverless compute allocates CPU in proportion to memory, so the memory setting is really a speed setting. We swept it:

• 1 GB was about 3.3 times slower than 2 GB. Less CPU, and the long report was close to the memory limit.
• 4 GB was only about 8% faster than 2 GB, at twice the price per second. Typst is mostly single-threaded, so extra cores sit idle.

2 GB is the sweet spot, and it is what the service runs at.

The cost per render

A render has three costs: the compute, a fixed fee per request, and moving the finished PDF out of the compute provider. This is how each render's cost splits between them:

Document	Compute	Request	Moving the PDF out	Relative to the invoice
2-page invoice	about 5%	about 15%	about 80%	1×
30-page report	about 13%	under 1%	about 87%	about 35×
300-page report	about 14%	under 1%	about 86%	about 350×

The result we did not expect: moving the PDF out is 85 to 90% of the cost of a larger document, not compiling it. Cost is close to proportional to PDF size, with compute included. A template with embedded photos or many fonts produces a bigger PDF and costs more than this text-heavy test, regardless of how fast it compiles.

Two lessons we took from this

First, a 300-page render costs over 300 times a two-page one, so plans that count renders rather than pages quietly subsidise long documents. Since November 2026 a PDF counts once for every 50 pages started, so a 120-page report counts as three. Short documents, which are most of them, still count as one.

Second, since PDF size drives cost, the most effective optimisation is not a faster compiler but smaller output: subsetting fonts, compressing images, and not embedding a 2 MB logo on every invoice. Typst already subsets fonts. The other two are up to the template.