Astro 7.3 Shipped in September. Its Rust Markdown Engine Still Doesn't Touch My 667 Markdoc Posts.
Astro 7.3 shipped September 3, 2026, and I went looking for the release note about Sätteri, the Rust-based Markdown processor everyone keeps citing as the reason Astro builds got faster this year. It's not in there. Astro 7.3 is a small release: a --ignore-lock flag for astro preview, a runtime logger passed into custom image services and cache providers, and a finalize() helper for Cloudflare worker entrypoints. Sätteri became Astro's default Markdown and MDX pipeline three point releases earlier, in Astro 7.0, back on June 22. That's worth correcting before anything else, because it changes what question is actually worth asking about this site's 667 Markdoc posts.
What Astro 7.3 actually shipped
I run this blog on Astro, so I checked the 7.3 changelog against my own astro.config.mjs the way I do for every point release. Three things landed: multiple preview servers can now run at once without fighting over the dev-server lockfile, custom image services and cache providers get access to Astro's configured logger instead of shouting through console.warn(), and @astrojs/cloudflare ships a finalize() helper for people running a custom src/fetch.ts worker entrypoint. None of the three touches Markdown processing, content collections, or anything this site's build pipeline depends on. If you were expecting a Sätteri update in this release, you're thinking of an earlier one.
Where Sätteri actually came from
Sätteri is real, and the numbers behind it are real. Astro core team member Erika built it as a from-scratch Rust replacement for Astro's old unified (remark and rehype) Markdown pipeline, using pulldown-cmark for CommonMark parsing and Oxc for MDX expressions. It first shipped as an opt-in processor in Astro 6.4, on May 28, 2026, behind a new markdown.processor config option. Astro 7.0, released June 22, made it the default. Astro's own benchmarks, run on an M4 Pro MacBook Pro, show the docs site (about 6,300 pages) going from 114.5 seconds to 73.5 seconds, and astro.build's own marketing site (about 300 pages) dropping from 62.7 seconds to 24.2 seconds. Those are the real gains, and they're specific to sites where Markdown parsing dominates the build.
Astro's markdown pipeline and Markdoc are not the same compiler
Here's the part that matters for this site. This blog's posts collection is defined in src/content.config.ts with glob({ pattern: '**/*.mdoc', base: './src/content/posts' }), and every post is rendered through the @astrojs/markdoc integration configured in markdoc.config.mjs. Markdoc is not Markdown with a plugin bolted on. It's a separate document format built around its own percent-brace tag syntax for things like custom nodes and component rendering, with its own parser and its own compiler, maintained as @markdoc/markdoc.
Sätteri and unified are both alternatives you plug into Astro's markdown.processor option, and that option only governs how Astro parses .md and .mdx files. The Markdoc integration doesn't read that setting at all. It used to depend on @astrojs/markdown-remark for some shared formatting helpers, but that dependency was dropped once Astro's Markdown support became processor-agnostic, and what's left uses Astro's internal utilities, not the remark/rehype tree-walking that Sätteri was built to replace. A .mdoc file on this site never enters the code path Sätteri rewrote. It's not a slow version of the same pipeline. It's a different pipeline that happens to live in the same repo.
What this means for 667 Markdoc posts
I counted: this site currently has 667 .mdoc files under src/content/posts, all compiled through Markdoc, none through Astro's native Markdown pipeline. Upgrading to Astro 7.3 doesn't make my build faster on the Markdown-processing axis, because Sätteri was never in that path to begin with, not in 7.0 and not in 7.3. Whatever build-time gain I'd get from being on Astro 7 comes from the parts of the release that apply regardless of content format: the Rust .astro compiler and the queued rendering engine, both genuinely framework-level, both something Markdoc pages pass through same as anything else.
I need to flag something here, because I've written about Sätteri on this blog twice before, in May and June, and both posts framed the decision around "how many remark/rehype plugins does your config have." That framing assumed a .md/.mdx setup with a markdown.processor choice to make. Checking astro.config.mjs today, there's no markdown block in this config at all, no remarkPlugins, no rehypePlugins list to count. There couldn't be a plugin-migration decision to make, because Markdoc was never on that pipeline. I got the premise wrong on a site I run every day, and the correction is worth stating plainly rather than quietly not mentioning it.
What it means if you're on plain Astro Markdown or MDX
If your content collection is .md or .mdx files going through Astro's default loader, the calculus is completely different and the earlier posts' advice actually applies to you. You're on Sätteri automatically as of Astro 7.0, and you have been since June, whether or not you've noticed. The one thing worth checking: if you lean on remark or rehype plugins for reading-time estimates, custom directives, or footnote handling, confirm Sätteri covers the equivalent natively (it now handles GFM, smart punctuation, heading IDs, directives, math, and frontmatter out of the box) or that you've deliberately opted back into the unified() processor via @astrojs/markdown-remark. For a plugin-light .md site with hundreds of pages, this is close to a free win you've probably already received without doing anything.
What I'd actually do
For this specific site: upgrade to Astro 7.3 for the preview-server and logger fixes, which cost nothing and fix small annoyances, but don't expect it to move build times, and stop looking to Astro's Markdown release notes for anything that affects the actual content pipeline here. If I want a faster Markdoc build, the lever is the Rust .astro compiler and queued rendering, not Sätteri, and neither of those needs a special config flag anymore since Astro 7.0 made them default too.
Where I could be wrong: Markdoc's integration is maintained inside the same withastro/astro monorepo as Sätteri, and there's no guarantee that separation stays permanent. If the Astro team ever wires Markdoc's tokenizer into Sätteri's Rust core the way they did for the .astro compiler, this whole article becomes outdated the day it happens. Worth checking again next time a Markdoc-specific line shows up in a changelog, not just a Markdown one.
Author
Lukas
@lukcombinator