Next.js Blog Options: MDX, Git Editors, or a Database
Compare MDX, Content Collections, Nextra, TinaCMS, Decap CMS, and BTST by content storage, author workflow, maintenance, and production responsibilities.
Choose a Next.js blog by deciding where posts should live and who will publish them. Files in Git suit teams that review writing alongside code. A Git editor gives authors a browser interface while retaining that repository workflow. A database-backed blog suits an application that needs its own editor, drafts, and publishing controls.
This comparison covers adding a blog to an existing Next.js app. It focuses on MDX, Content Collections, Nextra, TinaCMS, Decap CMS, and BTST. These tools solve different parts of publishing, and several can be combined. The recommendations are based on workflow fit, not a measured speed or performance ranking. Documentation and maintenance status were reviewed on September 29, 2026.
Compare the publishing workflows#
| Approach | Useful for |
|---|---|
| Local MDX | Code reviews |
| Content Collections | Typed content |
| Nextra | Blog layouts |
| Tina / Decap | Git editing |
| BTST Blog | App database |
Start with the workflow your authors can sustain. A small engineering blog may need only local MDX. A product team that already operates a database and identity system may prefer to keep publishing in that application. Neither choice removes the need to verify what anonymous readers can see.
Local MDX for developer-authored posts#
Next.js supports local MDX through @next/mdx and its related dependencies. MDX lets an article include React components, which is useful for interactive examples. The App Router setup requires both Next.js configuration and an mdx-components.tsx file; adding a page extension alone is incomplete. Follow the official Next.js MDX guide for the current setup.
Choose this when pull requests are an acceptable publishing interface. You can keep article changes and component changes in the same review. Decide how titles, dates, descriptions, and slugs are represented before building your index page. Frontmatter is not supported by @next/mdx by default; use explicit exports or configure the necessary parsing.
MDX rendering does not supply a complete editorial system. Your project still needs decisions about drafts, listing pages, tags, and publication. For a handful of developer-owned posts, those requirements may be small enough that a database and admin interface add little value.
Remote MDX needs a maintenance decision#
next-mdx-remote historically allowed MDX to be loaded outside Next.js route files, including from remote sources. Its upstream repository is now archived and explicitly marked unsupported. That changes its suitability for a new integration. Do not copy an older comparison's installation recommendation without checking who will maintain the dependency.
For an existing application, inventory the installed version, rendering mode, and content sources before planning changes. The project's documentation distinguishes its Pages Router and React Server Component APIs; examples for one are not interchangeable with the other.
MDX can involve executable JavaScript. Keep the source trusted and retain the compiler's security protections. A remote content location does not make the content safe. If authors only need formatted text, consider whether a Markdown renderer with an appropriate sanitization policy meets the requirement without MDX execution.
Content Collections for structured file content#
Content Collections validates content during its build pipeline and exposes typed data that application code can import. This is useful when posts share required fields and an invalid entry should fail validation before publication.
It supplies data processing rather than a finished blog. You still create the list and article views and decide how to handle drafts, ordering, and URLs. Markdown or MDX compilation requires the relevant transformation package; the core collection does not render those formats by itself.
Choose it when the problem is inconsistent file metadata or repeated content-loading code. For an integration that reads content at build time, publication must trigger the build and deployment that consume the change. Test a deliberately invalid post as well as a valid one so you know the schema is enforced.
Nextra for a themed blog#
Nextra provides a Blog Theme for a Next.js site. Its current getting-started guide covers the Nextra configuration, MDX components, theme stylesheet, and application layout. Older examples that place theme and themeConfig in the Nextra configuration do not describe that current setup.
Choose Nextra when its layout and content conventions already fit the site you want. In an existing product app, first check how the blog layout, navigation, styles, and routes coexist with your application shell. A quick test with one real article is more useful than assuming a theme will drop into every layout unchanged.
A blog theme does not, by itself, establish a browser-based author workflow. Decide separately whether authors will edit files directly or use an editor connected to those files.
Git editors for a broader author team#
Decap CMS gives editors a web interface that writes content to a Git repository. Its overview describes the repository workflow, configurable content types, previews, and media support. You still choose a backend and authentication configuration and connect content changes to your site's publishing process. Decap is not limited to Netlify hosting.
TinaCMS provides a Next.js integration with optional visual editing. Its Next.js overview separates App Router and Pages Router guides and links to content modeling and data fetching. Evaluate the integration against the components your authors need to edit, and review the production backend and authentication requirements for your chosen deployment.
These tools address author access and editing. They do not eliminate the site's content renderer or deployment process. Have an intended author test a draft, image, preview, publication, and correction before committing to the workflow. Review hosting and service requirements separately from open-source licensing; this comparison makes no claim that every production configuration is free.
BTST for a blog inside your app#
The BTST Blog plugin combines post and tag data, server operations, an editor, draft management, and public article views. Its client integration supplies routes, loaders, and metadata support. It fits teams that want to store blog content in their application database and operate the editor alongside existing product features. See the Blog reference and released v3.1.2 source.
Use the Next.js Blog setup guide for the current generator and framework integration. The older betterStack setup and lifecycle-hook authorization snippets previously shown here are not the v3 configuration used in that guide.
Plan for the application responsibilities:
- Persistence: configure a database adapter and migrations. A memory adapter is for local evaluation; it does not preserve posts across process restarts.
- Authorization: resolve identity on the server and apply the v3 authorization policy. Public readers should receive published content only. Restrict drafts and mutations to the intended editors. An edit button or editor route is not an access-control policy.
- Uploads: connect the editor's upload callback to actual authorized storage. If using BTST Media, register the stored assets through Media operations as well.
- Publication visibility: configure the site's public URLs, metadata, sitemap integration, and cache invalidation. Verify that an update appears on both the list and article page.
RSS is a separate application integration, not an automatically installed Blog endpoint. The BTST RSS guide shows one implementation. The drafts and caching guide covers the distinction between public content and authenticated editorial views.
If the site needs many structured content types rather than ordinary posts and tags, compare Blog and CMS before committing to a model.
Validate one complete publishing cycle#
Use the same small acceptance exercise for whichever approach you choose:
- Create a draft containing a heading, an image, and an internal link. Verify its preview and confirm that anonymous readers cannot access a private draft.
- Publish it at the intended URL. Check the rendered article, list entry, canonical URL, description, social image, and sitemap inclusion.
- Edit the title and body. Confirm that your build or cache-refresh process makes both changes visible to a fresh visitor.
- Unpublish it. Check the article, listing, and any feed you provide so cached copies do not remain public unintentionally.
- Have an intended author repeat the process using the interface they will actually use.
For developer-owned content, begin with local MDX and add a collection pipeline if its validation solves a real need. Evaluate a Git editor when authors need a browser interface. Choose a database-backed plugin when publishing is part of the application's own feature set, and budget for its storage and authorization work. For BTST, continue with the installation reference and test those boundaries before exposing the editor publicly.