Is Next.js + Payload good for very large websites?

For extremely high-traffic sites with massive content volumes, a fully decoupled headless CMS with a global CDN might offer better performance and scalability. This approach works best for small to medium-sized applications with custom content needs.

What kind of database does Payload use?

Payload supports both MongoDB and PostgreSQL. You choose your database when configuring Payload in your Next.js project. You'll need to host this database separately.

Does this mean my CMS admin is public?

The Payload Admin UI is served from your Next.js application, typically at a path like `/admin`. It has built-in authentication and access control, so only authorized users can log in and manage content. It is not publicly accessible without credentials.

Next.js + Payload: Unifying Site and CMS in One App

A few months ago, a founder came to me with a common problem. His marketing team was using Webflow for their main site. Their customer portal, built by another agency, was a separate Next.js application. Every time a new product feature launched, content had to be updated in two places. Sometimes three, if you count the separate blog. He asked if there was a way to manage everything from one central spot, without rebuilding the whole customer portal.

This multi-platform content problem is very common. Most companies start with separate tools. A marketing site here, an e-commerce platform there, a blog somewhere else. Each with its own content entry and publishing workflow. The operational overhead grows quickly. Eventually, the need for a unified system becomes clear.

Separate vs. Unified: The Trade-offs

Typically, when I build a content-heavy application for a client, I recommend a decoupled approach. The front-end application (Next.js, React) consumes data from a separate headless CMS (Strapi, Contentful, Sanity). This offers flexibility. The front-end team can work independently. The CMS team manages content without touching the code.

This setup works well for many clients. Content editors have a dedicated interface. Developers can choose the best front-end framework. But there are overheads. Two separate deployments. Two sets of dependencies. Potentially two databases. And two distinct codebases to maintain. For smaller teams or solo founders, this complexity adds up.

Consider a founder launching a SaaS product. They need a marketing site, a blog, documentation, and a customer dashboard. If each piece lives in its own silo, content updates become a chore. A simple hero text change might require edits in Webflow, a custom React app, and a Markdown file. This is where a unified approach can shine.

Payload: A Node.js CMS

Payload is a Node.js-based CMS. It’s built on Express, using MongoDB or PostgreSQL for data. Crucially, it's a code-first CMS. You define your collections (e.g., Pages, Products, Blog Posts) directly in TypeScript or JavaScript files. This developer-centric approach is a significant differentiator. It means the content structure lives in your codebase, version-controlled like the rest of your application.

Payload provides a robust Admin UI out of the box. Editors get a clean interface to manage content, users, media, and settings. It handles authentication, access control, and media management. All built on top of Express, so it plays nicely with other Node.js components.

I've used Payload for several projects where the client needed a custom content structure that commercial SaaS CMS platforms couldn't easily accommodate. Its flexibility means I can build precisely the content model the business requires, without workarounds or compromises.

The Unified Approach: Next.js + Payload

Here’s where the idea of 'one app' comes in. Next.js is a full-stack React framework. It can render front-end components, but it also has API routes. These API routes are essentially Node.js serverless functions. Payload, being a Node.js application, can run *inside* a Next.js project.

This means your Next.js application serves both your public-facing site and your CMS Admin UI. It's a single codebase. One deployment. One set of dependencies. The Next.js API routes can host the Payload backend, and your Next.js pages can consume data directly from Payload's internal APIs or even its database.

Imagine a blog. Your Next.js app renders the blog posts. Instead of fetching from a remote API, it can query Payload directly within the same application. This reduces network latency. It simplifies deployment. Your content and presentation layers are tightly integrated, but still distinct enough for good architecture. You get the best of both worlds: a content editor experience and a powerful front-end framework, all in one package.

For clients with a moderate amount of content and a need for deep customization, this setup offers significant advantages. It's less complex than maintaining a separate headless CMS and a separate front-end. It's more flexible than an all-in-one platform like WordPress or Webflow for highly custom applications.

How It Works in Practice

Setting this up involves a few key steps. First, initialize a Next.js project. Then, install Payload as a dependency. You'll create a `payload.config.ts` file to define your collections and configurations. This file lives within your Next.js project structure.

Next, you'll set up a Catch-all API route in Next.js (e.g., `pages/api/[[...slug]].ts` or `app/api/[...slug]/route.ts` if using App Router). This API route will initialize and handle all requests to Payload. It acts as the entry point for both the Admin UI and your custom APIs.

Your Next.js pages will then fetch data from Payload. For static content, you can use `getStaticProps` or `generateStaticParams` to build pages at compile time. For dynamic content, you can fetch data directly within server components or from client-side `useEffect` hooks, hitting your own Next.js API routes that then query Payload.

Deployment becomes simpler. You deploy one Next.js application. Vercel, for instance, handles both the static assets and the serverless functions for your API routes. Your Payload Admin UI is then accessible at a path like `/admin` within your Next.js application. Your database (MongoDB or PostgreSQL) still needs to be hosted separately, for example, on MongoDB Atlas or a managed PostgreSQL service. This usually costs between $15 and $100 per month depending on traffic.

When This Approach Makes Sense

This 'one app' strategy isn't for every project. If your content volume is massive, and you have a large, distributed content team, a dedicated headless CMS with a CDN might still be the better choice for performance and scalability. If your site is extremely simple, with minimal dynamic content, a static site generator might be enough.

But for many small to medium-sized businesses, solo founders, and SaaS startups, it hits a sweet spot. When you need deep content customization, a sophisticated front-end experience, and want to minimize infrastructure complexity and maintenance costs, Next.js with embedded Payload is a compelling option. It's often suitable for projects with development budgets between $30,000 and $100,000.

I've found it particularly useful for applications that blend marketing content with custom user data. For example, a learning platform where course content is managed in Payload, and user progress is managed in the same database or a linked one. Or an e-commerce site where product details are in Payload, and order processing is handled by custom Next.js API routes that interact with a payment gateway like Stripe.

This approach removes some of the friction that comes with separate systems. It streamlines the development process. It also gives the client a single point of truth for their application. This means less debugging across different platforms and a clearer architectural overview.

Next Steps

If you're grappling with disjointed content systems or planning a new application with custom content needs, consider this unified Next.js and Payload architecture. Spend an hour this week sketching out your content models and how they might fit into a single codebase. Think about the specific advantages for your project. You can also book a 30-minute feasibility call with me to discuss if this approach aligns with your business goals.