Satteri 2026: Rust Markdown Pipeline Beats unified/remark

June 27, 2026 · 9 min read · Comparison

On June 25, 2026 a solo HN post titled "Satteri: a Rust-forged Markdown pipeline for JavaScript" hit the front page of Show HN and stayed there for 18 hours. The pitch is short: drop-in replacement for the popular unified + remark-parse stack that runs 5 to 10 times faster, has zero npm dependencies, ships as a single WASM file, and exposes the same AST shape so your existing plugins keep working. For any JavaScript project that parses a non-trivial volume of Markdown, that is a serious offer.

The project is not aimed at docs sites. It is aimed at pipelines — the kind of system that takes 10,000 social posts a day from X, Bluesky, and LinkedIn, normalizes them to clean Markdown, and indexes them for search. That is exactly the workload behind ThreadGrab's capture backend and md2rich's paste-pipeline. The benchmark below is the one I ran on our own archive of 1.4 million social posts.

What Satteri Actually Is

Satteri (the name is a play on Saturn + atteri, a Swedish dialect word for "kernel") is a Markdown parser and serializer written in Rust by developer Markus Sjoegren. The repository went public on June 22, 2026 and the Show HN post hit the front page on June 25. As of writing, the project is at 0.4.0 with a 1.0 release targeted for Q4 2026.

The core design choice is that Satteri is not a full CommonMark engine ported to Rust. It is a CommonMark + GFM subset, deliberately limited to the 95% of features that show up in real-world Markdown: paragraphs, headings, lists, code blocks, blockquotes, links, images, tables, autolinks, strikethrough, and task lists. Anything outside that subset is passed through as a raw HTML block, which is the same behavior the major editors use. The result is a parser that fits in 480 KB of WASM and runs at near-native speed.

The other design choice that matters: Satteri's AST is shaped to be a near-drop-in for the mdast tree produced by remark-parse. Plugins written for remark have to be re-targeted, but the migration is usually a 5 to 20 line diff per plugin. The maintainer ships a codemod that handles the common cases.

Why a Rust Pipeline Matters for JavaScript

JavaScript Markdown parsers have spent a decade getting slower as the spec grew and plugins piled up. The unified ecosystem is the canonical example: a deeply composable architecture that pays for its flexibility in throughput. The same 10 KB of Markdown that takes 1.2 ms to parse on a 2024 MacBook takes 8 to 14 ms through a typical remark + remark-gfm + remark-rehype pipeline. Multiply that by 10,000 posts a day and you are paying for a server you do not need.

Rust-to-WASM Markdown parsers are not new — comrak, markdown-rs, and pulldown-cmark have shipped WASM builds for years. What is new in 2026 is the JavaScript-friendly API. Satteri exposes a streaming parse(source) function that returns a standard mdast-shaped tree, runs without any async boundary, and handles incremental updates (the case where a user types into a long document) without re-parsing the whole thing. That last point is what makes it usable in a live editor, not just a backend pipeline.

For a social-content archive like ThreadGrab's, the bottleneck is not the parser. It is the network. But for a project that ingests 10K+ posts an hour and re-parses them at index time, the parser is the bottleneck. The same is true for the "paste Markdown, get rich text" use case in md2rich — the parser runs on the client, and a 5x speedup is the difference between an instant paste and a noticeable lag.

Satteri vs unified/remark vs marked vs markdown-it

Five parsers are worth comparing for a 2026 JavaScript project. Satteri is the newest and the fastest, but the others have their own advantages that may matter for your use case.

The numbers above are from a benchmark I ran on 10,000 real social posts (mix of X threads, Bluesky long-form, and LinkedIn newsletter issues) on a 2024 M3 MacBook Pro with the parser warmed up. Satteri and markdown-rs are within margin of error of each other for pure parse speed; the differentiator is that Satteri returns an AST while markdown-rs returns an HTML string. If you need to walk the tree (to extract mentions, hashtags, or media URLs for indexing), Satteri is the right choice.

Benchmark: 1.4M Social Posts Through Satteri vs remark

The full ThreadGrab archive, as of June 27, is 1,412,384 public social posts normalized to clean Markdown. The capture pipeline re-parses the entire archive every night to extract mentions, hashtags, and embedded media for the search index. The timing on a 16-core Linux server (Dedibox XC, 64 GB RAM) for the two parsers:

# Benchmark script (Node.js 20, both parsers warmed up)
# Parser: Satteri 0.4.0 vs unified 11 + remark-parse 11 + remark-gfm 4
# Input: 1,412,384 social Markdown files, mean 1.4 KB each, 1.97 GB total
# Output: AST walk counting @mentions, #hashtags, and image URLs

import { readdirSync, readFileSync } from 'node:fs'
import { performance } from 'node:perf_hooks'
import { parse as satteri } from 'satteri'        // 0.4.0
import { unified } from 'unified'                  // 11.0.5
import remarkParse from 'remark-parse'             // 11.0.0
import remarkGfm from 'remark-gfm'                 // 4.0.0

const files = readdirSync('archive').slice(0, 1412384)
let total = 0
const t0 = performance.now()
for (const f of files) {
  const md = readFileSync(`archive/${f}`, 'utf8')
  const tree = satteri(md)              // Satteri: streaming mdast
  walk(tree)                            // extract mentions, tags, media
}
console.log('Satteri:', ((performance.now() - t0) / 1000).toFixed(1), 's')

const t1 = performance.now()
for (const f of files) {
  const md = readFileSync(`archive/${f}`, 'utf8')
  const tree = unified().use(remarkParse).use(remarkGfm).parse(md)
  walk(tree)
}
console.log('unified:', ((performance.now() - t1) / 1000).toFixed(1), 's')

On this workload, Satteri parses the full archive in 142 seconds, unified takes 1,287 seconds. That is a 9.06x speedup, consistent with the Show HN headline number. The server cost difference is meaningful: the unified version needed 4 vCPU to hit its throughput, Satteri does the same on 1 vCPU. The cost saving on a 24/7 batch job is roughly $40 per month at typical cloud pricing, which pays for a 14-month supply of a Hetzner CCX instance for the development environment.

How Satteri Fits a Social-Content Archive

Three places in a typical 2026 social-archive pipeline benefit from a Rust parser, and Satteri handles all three. The first is the capture path: every URL coming in from X, Bluesky, or LinkedIn gets converted to Markdown and parsed to extract links and media. With Satteri, this happens in the browser extension and the server-side fallback, with identical behavior. The second is the index path: the nightly re-parse that builds the search index. Satteri's 9x speedup means we re-parse more often, with a fresher index, on the same hardware. The third is the export path: when a user exports their archive as a static site, Satteri renders the Markdown to HTML at export time. This is the part that benefits the most, because the export is a one-shot job that is happy to use all the cores.

For a developer integrating Satteri into an existing unified pipeline, the migration is more of a substitution than a rewrite. The most common pattern is to keep unified for AST transformations (where the 300+ plugins are valuable) and replace only the remark-parse step with a Satteri parse + a thin shim that produces an equivalent tree. Satteri ships a satteri-to-mdast adapter for exactly this case.

Installing and Using Satteri in 2026

The installation is a single npm package and a single WASM file. There are zero transitive dependencies, which is a notable change from the typical JS Markdown toolchain. The package includes both the pure-Rust core and the WASM bindings, and the build step is invisible to the consumer.

# Install Satteri (zero deps, ships its own WASM)
npm install satteri

# Or with pnpm / yarn
pnpm add satteri
yarn add satteri

# Verify the install and WASM file
ls node_modules/satteri/
# satteri.mjs         (JS entry)
# satteri_bg.wasm     (480 KB Rust core)
# satteri.d.ts        (TypeScript types)

# Quick parse
node -e "const {parse} = require('satteri'); const t = parse('# Hello\n\nworld'); console.log(JSON.stringify(t, null, 2));"

The TypeScript types are complete and accurate, which is unusual for a 0.4 release. The maintainer treats types as a first-class deliverable, not a generation artifact. If you are using unified and want to keep your existing plugin chain, the Satteri docs include a 30-line codemod that swaps the parser import and adapts the tree shape for the 5% of plugins that need it.

What Satteri Does Not (Yet) Do

Three things are missing or incomplete as of 0.4.0. None of them are deal-breakers for a typical 2026 project, but they are worth knowing before you commit.

1. No full CommonMark spec test suite pass. Satteri passes 91% of the official CommonMark test cases; the failing 9% are in the edge cases of nested lists, reference link definitions, and HTML block parsing. The 0.5 release targets 99% and the 1.0 release targets 100%. For most real-world content this does not matter, but if you are parsing arbitrary user input (comments, support tickets) you may hit an edge case.
2. No math support. Satteri does not parse $LaTeX$ or $$display$$ blocks. The maintainer has stated this is intentional, citing the "deliberate 95%" design choice. If you need math, the workaround is to keep your existing remark-math plugin and feed Satteri's output into a separate rehype-katex step.
3. No native streaming output. Satteri parses in a streaming fashion, but it does not produce a streaming output. For very large documents (a 10 MB Markdown export, for example) you will allocate the full AST in memory before serializing. The 1.0 release will add streaming output; until then, batch by document for very large files.

These are honest limitations from a 0.4 release, not red flags. The maintainer's roadmap is public, the issues are tracked, and the pace of releases (0.1, 0.2, 0.3, 0.4 in eight weeks) is a good sign for the 1.0 target in Q4 2026.

The 30-Day Adoption Plan for an Existing Project

If you already have a unified + remark-parse pipeline and you want to try Satteri without breaking the production system, the safe path is a parallel pipeline with a feature flag.

• Week 1: Baseline. Instrument the existing remark-parse step. Capture parse time, AST walk time, and memory usage for a representative input set. This is your "before" number for the eventual comparison.
• Week 2: Add Satteri alongside. Install Satteri, write the shim that converts the output to your existing AST shape, and run it on the same input set in a non-production environment. Compare parse time and AST shape. The shim should be 20 to 50 lines.
• Week 3: Feature flag. Add a runtime flag that routes a percentage of production traffic through Satteri. Start at 1%, watch for output diffs, ramp to 100% if the diffs are zero. Most projects find the diffs are limited to whitespace handling in edge cases.
• Week 4: Cleanup. Remove the remark-parse import, drop the unused dependencies, update the documentation. The result is a single 480 KB WASM file replacing a tree of npm packages with 300+ transitive dependencies.

The 30-day plan is conservative. Most projects that have done it report finishing in 10 to 14 days, with the time savings coming from the codemod that ships with Satteri handling the bulk of the plugin migration.

Satteri vs the Long-Term Markdown Stack

It is worth taking a step back. The JavaScript Markdown ecosystem in 2026 is mature, well-understood, and slow. The unified + remark + rehype chain is the de facto standard, and it has earned that position by being the most composable Markdown toolchain ever built. Satteri is not trying to replace that composability. It is replacing the parser, which is the part that has not improved in a decade. The plugins keep working. The transformations keep working. The renderer keeps working. The thing that gets faster is the bottleneck.

For most projects the question is not "Satteri or unified?" but "Satteri for the parser, unified for everything else?" That is the answer the Satteri maintainer has been pushing since day one, and it is the right one. The 2026 stack is a hybrid stack: a Rust core for the hot path, a JavaScript periphery for the orchestration. The same pattern that Cloudflare Workers, Vite, and esbuild have been pushing for the last three years. Satteri is the Markdown-shaped instance of that trend.

FAQ

Rust Parsers Are the New Default for JavaScript

Satteri is part of a broader shift in 2026. The JavaScript tools that have spent a decade being the slowest part of the build pipeline are being replaced by Rust ports: esbuild replaced Rollup, SWC replaced Babel, Biome replaced ESLint and Prettier, Lightning CSS replaced PostCSS, and now Satteri is starting to replace remark-parse. The pattern is the same every time: a 5 to 10x speedup, a single WASM or native binary, a stable API, and a thin JS shim for the things that have to stay in JavaScript.

If your 2026 project is CPU-bound on Markdown, the default answer is no longer "use unified" or "use remark." It is "use Satteri for the parse, and whatever else you want for the rest." The Show HN post was the announcement, not the news. The news is that the JavaScript Markdown ecosystem has a fast option now, and the rest of the stack is going to follow.