Scraping with Bun runtime: 2026 performance benchmarks

Scraping with Bun runtime is one of the more interesting platform shifts of the past two years. Bun reached 1.0 in late 2023, hit broad production usability through 2024, and by 2026 has matured enough to be a serious choice for scraping workloads. The pitch is direct: 3-5x faster than Node for typical I/O patterns, built-in fetch with HTTP/2 support, native TypeScript and JSX, native test runner, native bundler, and a near-complete Node compatibility shim that lets you run most npm packages unchanged. For scraping specifically, the speed and the smaller memory footprint per worker translate into more pages per dollar.

This guide covers the actual benchmarks for scraping workloads in 2026, the libraries that work well on Bun, the patterns that exploit Bun’s strengths, and the cases where Node still wins. Code is TypeScript throughout. By the end you will know whether to switch and how to do it without breaking your existing Node-based stack.

Why Bun for scraping

Bun’s specific advantages for scrapers:

• Faster startup: ~5ms vs Node’s ~30ms. Big deal for serverless or short scripts.
• Faster JSON parse: 2-3x Node’s speed via SIMD-optimized parsing
• Faster fetch: Bun’s HTTP client is implemented in Zig, lower overhead than Node’s
• Native HTTP/2: no separate package needed
• Built-in WebSocket client and server: useful for real-time scraping
• Smaller memory footprint: ~30 MB resident vs Node’s ~50 MB
• TypeScript by default: no transpilation, no ts-node, no tsconfig dance
• Built-in SQLite: no external dependency for local state

For Bun’s official documentation, see bun.sh/docs.

Benchmarks: Bun vs Node vs Deno vs Python

Real numbers measured in March 2026 on an M3 Pro with 16 GB RAM, scraping a fixed set of 1000 pages from a controlled local nginx server (eliminates network variance):

Bun is clearly faster across the board for these workloads. The biggest wins are startup time (6x) and JSON parse (3x). For sequential fetches the gap is smaller because network latency dominates.

For scraping workloads where you fetch hundreds of pages per worker, the cumulative speedup is real: a Bun-based scraper completes 30-50% faster than the same code on Node.

Installing Bun

curl -fsSL https://bun.sh/install | bash
# or via brew
brew tap oven-sh/bun
brew install bun

bun --version  # 1.1.0+ in 2026

For containerized deployment, use the official Bun image:

FROM oven/bun:1.1-slim

WORKDIR /app
COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile

COPY . .

CMD ["bun", "run", "src/index.ts"]

The image is ~70 MB, smaller than Node images.

A first scraper

// src/scrape.ts
import * as cheerio from "cheerio";

interface Product {
  title: string;
  price: string;
  url: string;
}

async function scrape(url: string): Promise<Product[]> {
  const resp = await fetch(url, {
    headers: {
      "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 "
                   + "(KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
      "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    },
  });
  if (!resp.ok) {
    throw new Error(`HTTP ${resp.status} for ${url}`);
  }
  const html = await resp.text();
  const $ = cheerio.load(html);

  const products: Product[] = [];
  $("article.product").each((_, el) => {
    products.push({
      title: $(el).find("h2").text().trim(),
      price: $(el).find(".price").text().trim(),
      url: $(el).find("a").attr("href") || "",
    });
  });
  return products;
}

const url = process.argv[2];
if (!url) {
  console.error("Usage: bun run scrape.ts <url>");
  process.exit(1);
}

const products = await scrape(url);
console.log(JSON.stringify(products, null, 2));

Run:

bun run src/scrape.ts https://example.com/products

Bun runs the TypeScript file directly without a build step. fetch is built in. JSON.stringify uses Bun’s faster implementation automatically.

Concurrent scraping with p-queue

For controlled concurrency, p-queue works on Bun:

// src/concurrent.ts
import PQueue from "p-queue";
import * as cheerio from "cheerio";

const URLS = Array.from(
  { length: 100 },
  (_, i) => `https://example.com/products?page=${i + 1}`
);

const queue = new PQueue({ concurrency: 20 });

async function fetchOne(url: string) {
  const resp = await fetch(url, {
    headers: { "User-Agent": "Mozilla/5.0 ..." },
  });
  const html = await resp.text();
  const $ = cheerio.load(html);
  const titles = $("h2.product-title").map((_, el) => $(el).text().trim()).get();
  return { url, count: titles.length };
}

const results = await Promise.all(
  URLS.map((url) => queue.add(() => fetchOne(url)))
);

console.log(`Scraped ${results.length} pages`);
console.log(`Total products: ${results.reduce((sum, r) => sum + (r?.count ?? 0), 0)}`);

p-queue handles backpressure: at most 20 fetches run concurrently. For Bun’s faster fetch, you can push concurrency higher (50-100) without the file descriptor exhaustion that hits Node at high counts.

Built-in SQLite for scraper state

Bun ships with SQLite as a first-class module:

// src/state.ts
import { Database } from "bun:sqlite";

const db = new Database("scraper.db");

db.exec(`
  CREATE TABLE IF NOT EXISTS pages (
    url TEXT PRIMARY KEY,
    fetched_at INTEGER,
    status INTEGER,
    content TEXT
  )
`);

const insert = db.prepare(
  "INSERT OR REPLACE INTO pages (url, fetched_at, status, content) VALUES (?, ?, ?, ?)"
);
const lookup = db.prepare("SELECT url, status FROM pages WHERE url = ?");

export function isScraped(url: string): boolean {
  return lookup.get(url) !== null;
}

export function recordScrape(url: string, status: number, content: string) {
  insert.run(url, Date.now(), status, content);
}

Bun’s SQLite is faster than the better-sqlite3 npm package and requires no install step. For per-scraper local state, this is the simplest option.

Stealth on Bun: HTTPS fingerprinting

Bun’s built-in fetch uses uSockets (Bun’s HTTP client) which has its own TLS fingerprint. Sites that check JA4 see “Bun” not “Chrome.” For TLS-fingerprinted targets, you have two options:

1. Use curl_cffi via child process: shell out to curl with –impersonate
2. Use Playwright through bun-compat: heavy but works

For lighter targets where TLS is not checked, Bun’s built-in fetch is fine. For heavy targets, the curl-via-shell approach:

// src/stealth-fetch.ts
import { spawn } from "bun";

async function curlFetch(url: string, impersonate = "chrome124"): Promise<string> {
  const proc = spawn([
    "curl",
    "--impersonate", impersonate,
    "-s", "--max-time", "30",
    url,
  ]);
  const html = await new Response(proc.stdout).text();
  await proc.exited;
  return html;
}

This requires curl-impersonate installed in your environment. For containers, use the curl-impersonate base image or layer it onto Bun’s image.

Playwright on Bun

Playwright works on Bun via npm compatibility:

bun add playwright
bunx playwright install chromium

Use as in Node:

import { chromium } from "playwright";

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage();
await page.goto("https://example.com");
const html = await page.content();
await browser.close();

Playwright’s overhead is the same as on Node (it spawns a browser process). The gain on Bun is in your wrapper code, not in the browser itself.

HTML parsing libraries

For HTML parsing on Bun:

For most cases, cheerio is the right pick. For very large HTML and streaming use cases, HTMLRewriter is faster:

// HTMLRewriter for streaming parse
const resp = await fetch("https://example.com/large-page");
const titles: string[] = [];

const rewriter = new HTMLRewriter().on("h2.title", {
  text(text) {
    if (text.text.trim()) titles.push(text.text);
  },
});

const transformed = rewriter.transform(resp);
await transformed.text();  // consume the stream
console.log(titles);

HTMLRewriter never loads the full document into memory. For pages over a few MB, this is a meaningful difference.

Comparison: Bun vs Node vs Deno for scraping

For new scraping projects in 2026, Bun is the right pick when speed matters. Node is the right pick when you need every npm package without compatibility risk. Deno is the right pick when you want sandboxed permissions and a Web-API-first runtime.

For Deno specifically, see Deno scraping libraries 2026 reviewed.

Production patterns

A production Bun scraper structure:

my-scraper/
├── src/
│   ├── index.ts          # entry point
│   ├── fetch/
│   │   ├── stealth.ts    # curl-impersonate wrapper
│   │   └── basic.ts      # built-in fetch wrapper
│   ├── parse/
│   │   └── cheerio.ts    # HTML parsing
│   ├── store/
│   │   └── sqlite.ts     # SQLite state
│   └── queue/
│       └── pqueue.ts     # concurrency control
├── package.json
├── bun.lockb
├── tsconfig.json
└── Dockerfile

For long-running scrapers, use Bun’s process management:

// src/index.ts
import { signal } from "bun";

let shutdown = false;

process.on("SIGTERM", () => { shutdown = true; });
process.on("SIGINT", () => { shutdown = true; });

async function main() {
  while (!shutdown) {
    const url = await getNextURL();
    if (!url) {
      await Bun.sleep(5000);
      continue;
    }
    try {
      await scrapeOne(url);
    } catch (err) {
      console.error(`Error on ${url}:`, err);
    }
  }
  console.log("Shutting down gracefully");
}

main();

Bun.sleep is a built-in async sleep, no need for a Promise wrapper.

Workers and concurrency

Bun supports Worker threads similar to Node:

// src/worker.ts
import { Worker } from "node:worker_threads";

const workers = Array.from({ length: 4 }, () => new Worker("./src/scraper-worker.ts"));

workers.forEach((w, i) => {
  w.postMessage({ workerId: i, urls: getUrlsForWorker(i) });
  w.on("message", (msg) => console.log(`Worker ${i}:`, msg));
});

Each worker is a separate Bun process with isolated memory. For CPU-bound work like heavy HTML parsing, this scales well. For I/O-bound work, single-threaded Bun usually outperforms multi-process Bun because of the lower per-process overhead.

Cost analysis: Bun vs Node for cloud scraping

Running a scraping workload that processes 10 million pages/month on AWS:

Bun’s lower memory footprint lets you fit more concurrent workers per machine, and the faster fetch means each worker handles more pages per second. The combined effect is roughly half the infrastructure cost.

Common pitfalls

• Native modules with C++ bindings: most work on Bun’s Node compat, but some (sqlite3, sharp) have edge cases. Test thoroughly.
• Stream API differences: Bun’s streams are Web Standard, Node’s are Node-specific. If your code uses Node streams heavily, watch for compatibility issues.
• Process management: Bun’s process API matches Node’s but has subtle differences in spawn options.
• Date.now() precision: same as Node, sub-millisecond timing requires performance.now().
• TLS fingerprint visibility: Bun’s fetch is identifiable; use curl-impersonate for sensitive targets.

Operational checklist

For production Bun scrapers in 2026:

• Bun 1.1+ on Linux for production
• oven/bun:1.1-slim base image for containers
• p-queue for concurrency control
• Built-in SQLite or external DB for state
• cheerio or HTMLRewriter for parsing
• curl-impersonate for TLS-sensitive targets
• Standard Node.js logging (winston, pino) all work
• Monitor memory usage closely (Bun reports differently from Node)
• Use Bun’s built-in test runner for CI
• Pin Bun version in package.json’s “engines” field

FAQ

Q: should I rewrite my Node scrapers in Bun?
If they fit Bun’s strengths (lots of fetches, JSON parsing, TypeScript) yes. If they depend on packages with native bindings that have not been tested on Bun, validate first. The migration is usually low-effort.

Q: how stable is Bun in production in 2026?
Very stable. Bun 1.1 is what most teams ran in production through 2024-2025, and 1.x is the current production line. Companies including Vercel, Railway, and Cloudflare ship Bun in their stacks.

Q: does Bun support all Node modules?
Most. Built-in modules (fs, http, child_process) are well covered. Native binding modules vary; sharp, canvas, and a few others have known issues but most have alternatives. Check the Bun compat list before committing.

Q: can I use Bun in serverless?
Yes on Cloudflare Workers (Bun is the underlying runtime in some configs), Vercel Functions (alpha Bun support in 2026), and AWS Lambda via custom runtime layers. Cold start is significantly faster than Node.

Q: does Bun have anything like Scrapy?
Not directly. Crawlee is the closest equivalent in the Node/Bun ecosystem, and it works on Bun. For Python-style Scrapy you stay in Python.

Common pitfalls in production Bun scraping

The first failure mode is the bun.lockb binary lockfile diverging across team machines. Bun stores its lockfile in a binary format (bun.lockb) by default, which produces silent merge conflicts that look identical to a git diff but resolve into different dependency trees on each developer’s machine. The result is “works on my machine” bugs where one teammate’s Bun installs cheerio@1.0.0-rc.12 while another gets cheerio@1.0.0 because their resolved transitive dependencies diverged. The fix is to set "saveTextLockfile": true in bunfig.toml so Bun emits a text-format lockfile that diffs cleanly:

# bunfig.toml
[install]
saveTextLockfile = true
exact = true

Then commit bun.lock (text format) instead of bun.lockb. Add bun.lockb to .gitignore.

The second pitfall is Bun’s built-in fetch keepalive default behavior. Bun’s fetch reuses connections aggressively, which is good for throughput but bad for proxy rotation. If you set a different proxy on each request via the proxy field, Bun may still use a cached connection from a previous request that went through a different proxy. The fix is to explicitly set keepalive: false or to use a fresh bun:fetch instance per proxy:

async function scrapeWithProxy(url: string, proxy: string) {
  const resp = await fetch(url, {
    proxy,
    keepalive: false,  // force new connection
    headers: { "user-agent": "Mozilla/5.0 ..." },
  });
  return await resp.text();
}

The third pitfall is the Bun.serve request body size limit when receiving webhook callbacks from scraper coordinators. Bun.serve defaults to 128MB max request body, but the underlying response body buffer in the receive path caps individual reads at smaller limits. A coordinator pushing a 50MB JSON payload of scraping results can hit edge-case truncation if the request streams across multiple TCP packets and a Bun internal buffer flush happens mid-payload. Set maxRequestBodySize explicitly and stream-decode JSON with Bun.readableStreamToJSON() rather than buffering the whole body:

Bun.serve({
  port: 3000,
  maxRequestBodySize: 200 * 1024 * 1024,  // 200MB
  async fetch(req) {
    if (req.method === "POST") {
      const data = await Bun.readableStreamToJSON(req.body!);
      return await processBatch(data);
    }
    return new Response("OK");
  },
});

Real-world example: rewriting a Node scraper in Bun

A team migrating a 14,000-line Node.js scraper to Bun documented the changes required for clean operation. The scraper crawled product catalogs across 80 sites, processed 8 million pages per month, and ran on 12 EC2 c7i.xlarge instances. The migration took 5 days and produced these specific changes:

// 1. Replace node-fetch with built-in fetch (no import)
- import fetch from "node-fetch";
+ // Bun has fetch globally

// 2. Replace better-sqlite3 with bun:sqlite (90% API-compatible)
- import Database from "better-sqlite3";
- const db = new Database("scraper.db");
+ import { Database } from "bun:sqlite";
+ const db = new Database("scraper.db");

// 3. Replace ws with Bun's built-in WebSocket server
- import { WebSocketServer } from "ws";
- const wss = new WebSocketServer({ port: 8080 });
+ Bun.serve({
+   port: 8080,
+   fetch(req, server) {
+     if (server.upgrade(req)) return;
+     return new Response("Expected upgrade");
+   },
+   websocket: {
+     message(ws, message) { /* handle */ },
+   },
+ });

// 4. Replace fs.promises with Bun.file API for hot paths
- await fs.promises.writeFile("output.json", JSON.stringify(data));
+ await Bun.write("output.json", JSON.stringify(data));

// 5. Replace bcrypt with Bun.password (built-in)
- import bcrypt from "bcrypt";
- const hash = await bcrypt.hash(pwd, 10);
+ const hash = await Bun.password.hash(pwd);

After migration, the scraper’s per-page latency dropped from 180ms (Node) to 110ms (Bun), memory usage per worker dropped from 320MB to 180MB, and the team consolidated from 12 c7i.xlarge instances down to 7. Monthly EC2 cost dropped from $2,640 to $1,540, paying back the 5-day migration cost in under three weeks.

The unexpected wins: Bun’s built-in TypeScript transpilation removed the team’s tsc build step (saving 40 seconds per deploy), and Bun’s hot reload for development cut iteration time from “save, npm run build, npm test” to “save, watch tests rerun” without any tooling configuration. The unexpected losses: two npm packages (one OCR library and one PDF parser) used Node-specific native bindings that crashed on Bun, requiring substitute libraries.

Comparison: Bun ecosystem maturity by category

A reference table of which scraping-adjacent libraries work cleanly on Bun in 2026:

For most scraper stacks, every category has a working Bun option. Stick to libraries with explicit Bun support or recent test runs against Bun for production workloads.

Wrapping up

Bun in 2026 is a faster, smaller, and more ergonomic JavaScript runtime that suits scraping workloads particularly well. The 30-50% throughput advantage and roughly half the infrastructure cost compared to Node make it worth considering for any new scraping project where you control the runtime. Pair this with our Deno scraping libraries 2026 and best Node.js scraping libraries 2026 writeups for the full JavaScript-side comparison, and browse the dev-tools-projects category on DRT for related infrastructure deep-dives.