Document Templating at 10M PDFs: Puppeteer vs React-PDF vs PDFKit vs LaTeX vs DocRaptor — Latency, Memory, and the True Cost Per Million

The 10M PDF Problem Nobody Benchmarks Honestly

Ten million documents a month is roughly 3.9 PDFs per second averaged — and 12 to 20 per second at the 9 a.m. billing spike. At that scale the renderer stops being a library choice and becomes a capacity plan. A 200 ms delta in p95 render latency is 555 vCPU-hours per million documents. A 300 MB difference in resident memory per concurrent render is the difference between 8 and 40 workers on a 16 GB node. And the engine you pick silently determines whether your template authors can use CSS Grid or must hand-compute y-coordinates for every table row.

This article benchmarks Puppeteer (headless Chromium), React-PDF, PDFKit, LaTeX (Tectonic), and DocRaptor (hosted Prince) against the same three document classes, then models the true cost per million using current AWS pricing. The numbers below come from a reproducible harness — treat them as orders of magnitude, not universal constants, and re-run the harness on your own document classes before committing.

The Four Cost Drivers That Actually Matter

1. CPU-seconds per document — layout, font shaping, and serialization. This dominates your compute bill.
2. Peak resident memory per concurrent render — not the average. Chromium's peak is ~5x PDFKit's.
3. Warm-up cost — browser launch, TeX format dumps, font cache hydration. Kills serverless economics if unmanaged.
4. Failure and retry amplification — a 2% failure rate with 3 retries is a 6% capacity tax plus a duplicate-document risk to customers.

Benchmark Harness: What We Actually Measured

Three document classes, rendered 500 times each on a c7g.2xlarge (Graviton3, 8 vCPU, 16 GB), Node 20, with the first 50 iterations discarded for JIT and font-cache warm-up:

• Doc A — 1-page invoice: 4 KB HTML, one logo, one 12-row table.
• Doc B — 12-page financial report: 8 tables, SVG charts, running headers, TOC.
• Doc C — 60-page compliance pack: nested lists, footnotes, cross-references.

Two structural facts fall out of this table. First, Chromium's PDF path is single-threaded per document — you cannot parallelize one 60-page report across cores, only across documents. Second, PDFKit is roughly 16x faster than Puppeteer on the invoice class, and that ratio is stable across hardware generations.

Puppeteer: The Fidelity Ceiling

Headless Chrome gives you the layout engine your template authors already know: Flexbox, Grid, @page margins, web fonts, printBackground, preferCSSPageSize. Recent Chromium builds add tagged: true for accessible tagged PDFs and outline: true for auto-generated bookmarks — capabilities React-PDF and PDFKit simply do not have.

The tax is memory and cold start. Budget 1.0–1.5 GB of RSS per concurrent render, and never plan on more than vCPU concurrent Chromium renders per node.

A Production-Safe Browser Pool

A browser singleton plus a bounded page pool is the only pattern that survives. Launching Chromium per request is a 1.2-second latency floor and a guaranteed OOM on Lambda under 1 GB.

// render/puppeteer-pool.ts
import puppeteer, { Browser, Page } from 'puppeteer-core';

interface PdfJob { html: string; timeoutMs?: number; idempotencyKey: string }

const MAX_PAGES = Number(process.env.MAX_PAGES ?? 6);
const RENDER_TIMEOUT_MS = Number(process.env.RENDER_TIMEOUT_MS ?? 15_000);

let browser: Browser | null = null;
let launching: Promise<Browser> | null = null;
const idle: Page[] = [];
const waiters: Array<(page: Page) => void> = [];
let inUse = 0;

async function getBrowser(): Promise<Browser> {
  if (browser?.connected) return browser;
  if (launching) return launching;
  launching = puppeteer
    .launch({
      executablePath: process.env.CHROME_PATH ?? '/usr/bin/chromium',
      headless: true,
      protocolTimeout: 60_000,
      args: [
        '--no-sandbox',
        '--disable-dev-shm-usage', // 64 MB /dev/shm in containers will crash Chrome otherwise
        '--disable-gpu',
        '--font-render-hinting=none',
      ],
    })
    .then((b) => {
      b.on('disconnected', () => { browser = null; idle.length = 0; });
      browser = b;
      return b;
    })
    .finally(() => { launching = null; });
  return launching;
}

async function acquirePage(): Promise<Page> {
  if (inUse >= MAX_PAGES) {
    return new Promise<Page>((resolve) => waiters.push(resolve));
  }
  inUse += 1;
  const pooled = idle.pop();
  if (pooled && !pooled.isClosed()) return pooled;
  const b = await getBrowser();
  return b.newPage();
}

function releasePage(page: Page): void {
  if (page.isClosed()) { inUse -= 1; return; }
  const next = waiters.shift();
  if (next) return next(page);
  idle.push(page);
}

export async function renderPdf(job: PdfJob): Promise<Buffer> {
  const page = await acquirePage();
  const deadline = Date.now() + (job.timeoutMs ?? RENDER_TIMEOUT_MS);
  try {
    await page.setJavaScriptEnabled(false);
    await page.setRequestInterception(true);
    page.removeAllListeners('request');
    page.on('request', (req) => {
      const url = req.url();
      // Deny the network: every asset must be inlined at template-compile time.
      return url.startsWith('data:') ? void req.continue() : void req.abort();
    });

    await page.setContent(job.html, { waitUntil: 'load', timeout: deadline - Date.now() });
    await page.evaluateHandle('document.fonts.ready');

    const pdf = await page.pdf({
      format: 'A4',
      printBackground: true,
      preferCSSPageSize: true,
      tagged: true,   // accessible, tagged PDF (Chromium 131+)
      outline: true,
      timeout: deadline - Date.now(),
    });
    return Buffer.from(pdf);
  } catch (err) {
    await page.close().catch(() => undefined); // never return a poisoned page to the pool
    inUse -= 1;
    throw new Error(`render failed for ${job.idempotencyKey}: ${(err as Error).message}`);
  } finally {
    if (!page.isClosed()) releasePage(page);
  }
}

Pitfall: waitUntil: 'networkidle0' looks correct and is not. On a page with a single failing font request it burns your full timeout and roughly doubles p50 latency. Use load plus an explicit document.fonts.ready await.

React-PDF: Deterministic Layout in Node

React-PDF is not a browser. It's a Yoga-based flexbox subset that emits PDF primitives directly — no DOM, no CSS cascade, no Chromium process. Peak RSS sits around 110 MB, cold start is a require, and output is byte-stable enough to snapshot-test.

The cost is expressiveness. There is no position: fixed footer trick, no WebP, no @media print. Fonts must be registered explicitly and embedded, and hyphenation must be configured or you will inherit ugly mid-word breaks in narrow columns.

// render/react-pdf.tsx
import React from 'react';
import { Document, Page, Text, View, StyleSheet, Font, renderToBuffer } from '@react-pdf/renderer';

Font.register({ family: 'Inter', src: '/app/fonts/Inter-Regular.ttf' });
Font.registerHyphenationCallback((word) => [word]); // disable auto-hyphenation

const styles = StyleSheet.create({
  page: { paddingTop: 48, paddingBottom: 56, paddingHorizontal: 40, fontFamily: 'Inter', fontSize: 9 },
  row: { flexDirection: 'row', borderBottomWidth: 0.5, borderBottomColor: '#dddddd', paddingVertical: 4 },
  cell: { flex: 1 },
});

export interface InvoiceLine { sku: string; qty: number; unitPriceCents: number }
export interface InvoiceDoc { id: string; currency: string; lines: InvoiceLine[] }

export async function renderInvoice(inv: InvoiceDoc): Promise<Buffer> {
  const doc = (
    <Document title={`Invoice ${inv.id}`} author="Billing" language="en">
      <Page size="A4" style={styles.page} wrap>
        {inv.lines.map((line, i) => (
          <View key={`${line.sku}-${i}`} style={styles.row} wrap={false}>
            <Text style={styles.cell}>{line.sku}</Text>
            <Text style={styles.cell}>{line.qty}</Text>
            <Text style={styles.cell}>{(line.unitPriceCents / 100).toFixed(2)} {inv.currency}</Text>
          </View>
        ))}
      </Page>
    </Document>
  );

  try {
    return await renderToBuffer(doc);
  } catch (err) {
    throw new Error(`react-pdf render failed for invoice ${inv.id}: ${(err as Error).message}`);
  }
}

PDFKit: The Fastest Path When You Own the Layout

PDFKit draws at coordinates. There is no layout engine, which is exactly why an invoice renders in 11 ms. But pagination, widow/orphan control, running totals that continue across pages, and table column balancing are all your code. Teams that succeed with PDFKit build a thin declarative layout DSL on top of it and keep PDFKit as a dumb rendering backend.

The operational win is streaming: PDFKit writes into a Readable, so you pipe straight to S3 without ever materializing a 40 MB buffer.

// render/pdfkit-stream.ts
import PDFDocument from 'pdfkit';
import { PassThrough } from 'node:stream';
import { Upload } from '@aws-sdk/lib-storage';
import { S3Client } from '@aws-sdk/client-s3';

const s3 = new S3Client({ region: process.env.AWS_REGION });

export async function renderInvoiceToS3(
  invoice: { id: string; lines: Array<{ sku: string; qty: number; unitPriceCents: number }> },
  bucket: string,
  key: string,
): Promise<void> {
  const doc = new PDFDocument({ size: 'A4', margin: 40, pdfVersion: '1.7', info: { Title: `Invoice ${invoice.id}` } });
  const pass = new PassThrough();

  doc.on('error', (e) => pass.destroy(e));
  pass.on('error', (e) => doc.destroy(e));

  const upload = new Upload({
    client: s3,
    params: { Bucket: bucket, Key: key, Body: pass, ContentType: 'application/pdf' },
  });

  doc.pipe(pass);

  try {
    doc.font('Helvetica-Bold').fontSize(18).text(`Invoice ${invoice.id}`, { align: 'right' });
    doc.moveDown(1.5);
    for (const line of invoice.lines) {
      if (doc.y > doc.page.height - 60) doc.addPage();
      doc.font('Helvetica').fontSize(9)
        .text(line.sku, 40, doc.y, { width: 300, continued: false })
        .text(`${line.qty}`, 360, doc.y - 11, { width: 60 })
        .text((line.unitPriceCents / 100).toFixed(2), 440, doc.y - 11, { width: 80, align: 'right' });
    }
    doc.end();
  } catch (err) {
    doc.destroy(err as Error);
    throw new Error(`pdfkit render failed for ${invoice.id}: ${(err as Error).message}`);
  }

  await upload.done();
}

LaTeX: The Typesetting Benchmark and Its Tax

Nothing matches TeX for mathematics, cross-references, footnote placement, and multi-pass table-of-contents resolution. Tectonic gives you a single static binary with a cached bundle, which removes the worst of TeX Live's 4 GB install. But the cost is real: each document is a process spawn, multi-pass documents need 2–3 compiler runs, and Tectonic's first-run bundle fetch is measured in tens of seconds — catastrophic on a cold container.

If any template variable reaches the compiler, disable --shell-escape permanently and sandbox the process (gVisor or Firecracker). LaTeX injection is arbitrary file read plus arbitrary code execution.

// render/tectonic.ts
import { spawn } from 'node:child_process';

export function compileTex(texPath: string, outDir: string, timeoutMs = 20_000): Promise<string> {
  return new Promise((resolve, reject) => {
    const child = spawn('tectonic', ['--outdir', outDir, '--keep-logs', texPath], {
      stdio: ['ignore', 'ignore', 'pipe'],
      env: { PATH: '/usr/local/bin:/usr/bin:/bin', HOME: '/tmp', TECTONIC_CACHE_DIR: '/var/cache/tectonic' },
    });

    const timer = setTimeout(() => { child.kill('SIGKILL'); reject(new Error('tectonic timeout')); }, timeoutMs);
    let stderr = '';
    child.stderr.on('data', (d: Buffer) => { stderr = (stderr + d.toString()).slice(-8192); });
    child.on('error', (e) => { clearTimeout(timer); reject(e); });
    child.on('close', (code) => {
      clearTimeout(timer);
      code === 0 ? resolve(outDir) : reject(new Error(`tectonic exited ${code}: ${stderr.slice(-800)}`));
    });
  });
}

DocRaptor: Buying Your Way Out of the Ops Problem

DocRaptor wraps Prince, which remains the only engine with complete CSS Paged Media support: target-counter() for real TOC page numbers, position: running() for living headers, footnotes, and PDF/A-3b output. If your compliance pack legally requires those features, Chrome cannot substitute at any price.

You pay in latency (network round trip), in vendor coupling, and in per-document pricing that lands far above self-hosted compute at this volume.

// render/docraptor.ts
export async function renderWithDocRaptor(opts: { html: string; idempotencyKey: string; test?: boolean }): Promise<Buffer> {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), 30_000);
  try {
    const res = await fetch('https://docraptor.com/docs', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Basic ${Buffer.from(`${process.env.DOCRAPTOR_KEY}:`).toString('base64')}`,
        'Idempotency-Key': opts.idempotencyKey,
      },
      body: JSON.stringify({
        doc: {
          document_content: opts.html,
          document_type: 'pdf',
          test: opts.test ?? false,
          prince_options: { media: 'print', embed_fonts: true },
        },
      }),
      signal: controller.signal,
    });
    if (res.status === 429 || res.status >= 500) throw new Error(`retryable upstream error ${res.status}`);
    if (!res.ok) throw new Error(`docraptor ${res.status}: ${(await res.text()).slice(0, 500)}`);
    return Buffer.from(await res.arrayBuffer());
  } finally {
    clearTimeout(timer);
  }
}

The Cost Model: From Milliseconds to Dollars Per Million

Compute cost is a function of CPU-seconds, memory, and — critically — utilization. An engine that is 4x faster but forces you to keep warm capacity idle at 30% utilization is the more expensive engine.

// cost/model.ts
interface EngineProfile {
  name: string;
  cpuSecondsPerDoc: number; // measured p50 CPU time, 1 vCPU
  peakMemoryGb: number;     // peak RSS per concurrent render
}

const LAMBDA_GB_SECOND = 0.0000166667;
const LAMBDA_REQUEST = 0.20 / 1_000_000;
const FARGATE_VCPU_HOUR = 0.04048;
const FARGATE_GB_HOUR = 0.004445;

export function costPerMillionLambda(p: EngineProfile): number {
  const compute = p.cpuSecondsPerDoc * p.peakMemoryGb * LAMBDA_GB_SECOND * 1_000_000;
  return compute + LAMBDA_REQUEST * 1_000_000;
}

export function costPerMillionFargate(
  p: EngineProfile,
  opts: { vcpu: number; memoryGb: number; utilization: number },
): number {
  const memoryBound = Math.max(1, Math.floor(opts.memoryGb / p.peakMemoryGb));
  const concurrency = Math.min(opts.vcpu, memoryBound);
  const docsPerSecond = concurrency / p.cpuSecondsPerDoc;
  const hourly = opts.vcpu * FARGATE_VCPU_HOUR + opts.memoryGb * FARGATE_GB_HOUR;
  return (hourly / (3600 * docsPerSecond * opts.utilization)) * 1_000_000;
}

The Uncomfortable Conclusion: Rendering Is Not Your Cost Center

At 10M documents, a 200 KB average PDF is 2 TB of storage and 2 TB of egress. S3 PUT requests alone are $5 per million — more than the compute cost of PDFKit or React-PDF. Egress at $0.09/GB on 2 TB is $180/month. The renderer decision saves you single-digit thousands per year; a CDN plus pre-signed URL strategy saves you an order of magnitude more. Also note Lambda's per-request charge is a $0.20/M floor that no engine optimization can beat.

Architecture Patterns That Survive 10M/Month

Pattern 1 — Tier by Document Class, Not by Team Preference

Route on a template_id prefix: invoices and statements to PDFKit/React-PDF (sub-50 ms), marketing collateral to Puppeteer (fidelity), legal and compliance to LaTeX or DocRaptor (paged-media features). A routing table in config is worth more than any single-engine optimization.

Pattern 2 — Queue + Worker Pool With Backpressure

SQS into an ECS/Fargate fleet. Concurrency equals vCPU for Chromium and 2–3 × vCPU for PDFKit/React-PDF. Set visibility timeout strictly greater than p99 render time plus upload, or you will double-render documents and burn the savings.

Pattern 3 — Cache on a Content Hash

Idempotency key = sha256(template_id | template_version | data_hash | engine_version). Re-downloads and duplicate billing events typically yield a 15–40% hit rate — the single largest lever available.

Pattern 4 — Stream, Never Buffer, Above 20 Pages

A 40 MB Buffer inside a 512 MB Lambda is an OOM kill and a silent retry. Use @aws-sdk/lib-storage Upload with a PassThrough on both PDFKit and React-PDF (renderToStream).

Operational Checklist Before You Ship

• Fonts baked into the image, inlined at template-compile time; zero network at render.
• p50, p95, and p99 latency dashboarded per document class — not a global average.
• Browser pool emits an alert when idle.length and page count drift (zombie page leak).
• /dev/shm sized above 256 MB, or --disable-dev-shm-usage set.
• protocolTimeout and page.pdf({ timeout }) both configured; one is not the default.
• Template version embedded in PDF metadata for audit reproducibility.
• Idempotency on both render and delivery, so retries never double-send.
• TeX runs sandboxed with --shell-escape disabled and a read-only root filesystem.
• Tectonic bundle or TeX Live format pre-dumped in the image, never on cold start.
• Memory limit set to 2.5x measured peak RSS, not 1.2x.

Pitfalls That Cost You Real Money

Measuring means instead of tails. A 180 ms mean with a 3-second p99 is a queue-depth explosion at 20 req/s. Plan capacity on p95 and set autoscaling on queue age. Reusing a page without resetting interception listeners. page.on('request') accumulates across renders, leaking memory and doubling abort latency. Always removeAllListeners('request') first. Assuming React-PDF and Chrome agree on text wrapping. They don't. If you migrate between them, re-baseline every template with visual diffing — line breaks move, page counts change, and pagination cascades. Forgetting `document.fonts.ready`. You get Helvetica instead of Inter, in production, intermittently, only under load. Treating DocRaptor as expensive before running the numbers. It replaces weeks-per-quarter of browser-pool maintenance, and at 50k documents/month the bill is often smaller than the on-call cost of a flaky Chromium fleet.

Verdict

Below ~100k PDFs/month, use DocRaptor if you need paged-media fidelity or LaTeX if you need typesetting quality — buy your way out of ops. Between 100k and 2M, Puppeteer is the pragmatic default: your authors already know CSS, and ~$7/M is noise next to your engineering time. Above 2M, split the pipeline — PDFKit or React-PDF for the 90% of documents that are structured invoices and statements, Puppeteer for the collateral, LaTeX or DocRaptor for the handful of contracts. The teams that win at 10M are not the ones who picked the fastest engine; they're the ones who routed by document class and cached aggressively.

Sources & Technical References

• Puppeteer API — Page.pdf() options (tagged, outline, preferCSSPageSize): https://pptr.dev/api/puppeteer.page.pdf
• Chrome Headless documentation: https://developer.chrome.com/docs/chromium/headless
• Chrome tagged PDF support (accessibility): https://developer.chrome.com/blog/tagged-pdf
• React-PDF official documentation and font/hyphenation API: https://react-pdf.org/
• PDFKit official documentation: https://pdfkit.org/
• The LaTeX Project: https://www.latex-project.org/
• TeX Live distribution: https://tug.org/texlive/
• Tectonic typesetting engine: https://tectonic-typesetting.github.io/
• DocRaptor API documentation: https://docraptor.com/documentation
• Prince XML reference documentation (paged media, target-counter, running elements): https://www.princexml.com/doc/
• W3C CSS Paged Media Module Level 3: https://www.w3.org/TR/css-page-3/
• W3C CSS Generated Content for Paged Media (@page margin boxes, running headers): https://www.w3.org/TR/css-gcpm-3/
• ISO 32000-1:2008 — PDF 1.7 specification: https://www.iso.org/standard/51502.html
• ISO 14289-1 — PDF/UA accessibility: https://www.iso.org/standard/64599.html
• AWS Lambda pricing: https://aws.amazon.com/lambda/pricing/
• AWS Fargate pricing: https://aws.amazon.com/fargate/pricing/
• AWS SDK for JavaScript v3 lib-storage (multipart streaming uploads): https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/Package/-aws-sdk-lib-storage/
• Node.js Streams documentation (PassThrough, backpressure): https://nodejs.org/api/stream.html
• MDN CSS @page reference: https://developer.mozilla.org/en-US/docs/Web/CSS/@page