Choosing a headless CMS in 2026 feels like picking a side in a philosophical debate. On one end, you've got Payload CMS — open-source, self-hosted, code-first, and increasingly the darling of developers who want total control. On the other, Hygraph (formerly GraphCMS) — a managed GraphQL-native SaaS platform that handles infrastructure so you don't have to. I've shipped production projects with both over the past two years, and the honest answer is: neither is universally better. But one will almost certainly be better for your specific situation. Let's break down exactly why.

Table of Contents

Payload CMS vs Hygraph 2026: Self-Hosted vs GraphQL SaaS Compared

Architecture and Philosophy

These two CMSs come from fundamentally different worldviews, and understanding that is more important than any feature comparison table.

Payload CMS: Code-First, Self-Hosted

Payload is a TypeScript-first, open-source headless CMS that runs on your own infrastructure. Since the Payload 3.0 release (which landed in late 2024 and has been refined throughout 2025), it's built directly on top of Next.js. That's not a typo — Payload literally is a Next.js app. Your CMS admin panel, your API routes, and your frontend can all live in the same project.

The config is code. You define collections, fields, hooks, and access control in TypeScript files. There's no UI for schema building — you write it, commit it, version it. This is either wonderful or terrible depending on your team.

Payload supports both MongoDB and PostgreSQL (via Drizzle ORM) as database adapters. As of early 2026, the Postgres adapter has matured significantly and is what I'd recommend for most new projects.

Hygraph: GraphQL-Native SaaS

Hygraph takes the opposite approach. It's a fully managed platform with a visual schema builder, a hosted GraphQL API, and zero infrastructure to manage. You model your content in their UI, configure webhooks, set up environments, and you're off.

Under the hood, Hygraph runs on a globally distributed edge infrastructure. Their content API is GraphQL-only (no REST endpoint), which is an intentional design decision. They've leaned hard into the GraphQL ecosystem — including support for content federation, remote sources, and union types.

Hygraph is not open-source. You're renting the platform.

Developer Experience

Local Development

With Payload, local dev is just pnpm dev. You get hot reload on your config changes, the admin UI runs on localhost, and you can debug everything in one process. Since it's Next.js, your entire stack — frontend, CMS, API — runs in a single next dev command. This is genuinely nice. No network latency to a remote API during development, no mocking layers, no separate CMS instances to manage.

Hygraph requires you to work against their cloud API during development. They do offer development environments and branching (on higher-tier plans), but you're always making network requests. For teams in regions far from their edge nodes, this can add noticeable latency during dev. On the plus side, there's zero setup — sign up, create a project, start querying.

TypeScript Support

Payload generates types automatically from your config. Since your schema is TypeScript, the types are always in sync. This is one of those things that sounds minor until you've dealt with a CMS where the types drift from reality.

Hygraph requires you to generate types from their GraphQL schema, typically via GraphQL Code Generator. It works, but it's an extra step in your pipeline. And if someone changes the schema in the Hygraph UI without updating the generated types, you'll find out at runtime.

Admin UI

Payload's admin panel is React-based and fully customizable. You can swap out field components, add custom views, inject your own routes. It looks clean and modern as of Payload 3.x, though it's not going to win any design awards. It's functional.

Hygraph's admin UI is polished and purpose-built for content editors. The content editing experience is arguably smoother for non-technical users. The sidebar navigation, asset management, and content stage workflows feel more mature from a pure UX perspective.

Feature Payload CMS Hygraph
Local dev Full local stack Cloud API only
TypeScript Native, auto-generated Via GraphQL codegen
Admin customization Full React component override Limited (custom sidebar apps)
Content editor UX Good, developer-oriented Polished, editor-focused
Setup time 5-15 min (needs Node + DB) 2 min (sign up and go)

Content Modeling

Payload's Approach

Content modeling in Payload happens in code. Here's a simplified example:

import { CollectionConfig } from 'payload'

export const Articles: CollectionConfig = {
  slug: 'articles',
  admin: {
    useAsTitle: 'title',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'publishedAt',
      type: 'date',
    },
  ],
}

This gets version-controlled, reviewed in PRs, and deployed alongside your application code. Need to add a field? Change the config, run a migration if you're on Postgres, deploy. The mental model is very close to how you'd define a database schema with an ORM.

Payload supports blocks, arrays, groups, tabs, conditional logic, and custom field types. The blocks field type is particularly powerful for building flexible page builders.

Hygraph's Approach

Hygraph gives you a visual schema editor. You drag and drop field types, configure validations, set up references between models. It's intuitive and fast for initial setup. Non-developers can understand the schema (though whether they should be changing it is a different conversation).

Hygraph supports components (reusable field groups), union types for polymorphic references, and a concept called "Remote Sources" that lets you federate external APIs directly into your content graph. That last feature is genuinely unique and useful for certain architectures.

The downside? Schema changes in Hygraph happen in their UI. While they offer environment branching and schema migrations on enterprise plans, you don't get the same code-review workflow that Payload provides natively.

Payload CMS vs Hygraph 2026: Self-Hosted vs GraphQL SaaS Compared - architecture

API Design and Querying

Payload: REST + GraphQL

Payload gives you both a REST API and a GraphQL API out of the box. The REST API is auto-generated from your collections and follows predictable conventions. The GraphQL API is also auto-generated.

But here's the thing most people miss: Payload also exposes a Local API that lets you query your database directly from server-side code without any HTTP overhead:

// Server component or API route
const articles = await payload.find({
  collection: 'articles',
  where: {
    publishedAt: { less_than: new Date().toISOString() },
  },
  depth: 2,
  limit: 10,
})

This Local API is absurdly fast because it skips the network layer entirely. When you're building with Next.js and Payload in the same project, this is the primary way you'll fetch content. It's a huge advantage.

Hygraph: GraphQL-Only

Hygraph is GraphQL all the way down. No REST API. Your queries look like this:

query GetArticles {
  articles(where: { publishedAt_lt: "2026-01-01" }, first: 10) {
    title
    content {
      html
    }
    author {
      name
    }
  }
}

The GraphQL API is well-designed with solid filtering, pagination, and ordering. They support content stages (DRAFT, PUBLISHED), localization at the field level, and a high-performance read endpoint that serves cached content from the edge.

If your team already works heavily with GraphQL — say you're using Apollo Client or urql — Hygraph feels natural. If your team doesn't know GraphQL, the learning curve is real.

Performance and Scalability

Payload's performance depends entirely on your infrastructure. Running on a decent VPS with PostgreSQL and proper indexing, I've seen P95 response times under 30ms for the Local API and around 50-80ms for the REST/GraphQL endpoints. But you're responsible for scaling. Need to handle a traffic spike? That's on you — add more containers, scale your database, set up caching.

Hygraph handles scaling for you. Their edge-cached read API (what they call the "Content API") serves responses from globally distributed CDN nodes. Typical response times are 20-50ms worldwide. For read-heavy content sites, this is hard to beat without significant infrastructure work on the self-hosted side.

For our headless CMS development projects, we've found that Payload with proper caching (ISR or on-demand revalidation in Next.js) performs comparably to Hygraph's edge API for most real-world traffic patterns.

Pricing Breakdown for 2026

This is where things get interesting. Let me lay out real numbers.

Plan Payload CMS Hygraph
Free/Open Source $0 (self-host, all features) Free tier: 2 seats, 1M API calls/mo, 500 content entries
Small Team ~$20-50/mo hosting costs Starter: $0 (limited), Growth: custom pricing
Mid-Scale ~$100-300/mo (VPS + DB + storage) Professional: starts ~$399/mo
Enterprise $500-2000/mo infra (varies wildly) Enterprise: custom pricing (~$1500+/mo)
Payload Cloud From $30/mo per project N/A

Payload CMS itself is MIT-licensed and completely free. You're paying for infrastructure. A Hetzner VPS ($20/mo), a managed Postgres instance ($15-30/mo), and S3-compatible storage ($5-10/mo) gets you a production-ready setup for under $60/month. Payload also offers Payload Cloud — their managed hosting service — starting at $30/month per project, which simplifies deployment significantly.

Hygraph's free tier is usable for small projects and prototypes. But once you need more than 2 team seats, custom roles, multiple environments, or higher API limits, you jump to their paid plans. The Professional tier runs roughly $399/month in 2026, which is a meaningful recurring cost. Enterprise pricing is negotiated but typically starts around $1,500/month.

Here's the nuance: if you factor in developer time for managing infrastructure, Hygraph's pricing might actually be cheaper for small teams without DevOps expertise. Conversely, for agencies managing many projects, Payload's free core means your per-project marginal cost is just hosting.

Self-Hosting vs SaaS: The Real Tradeoffs

This is the core tension, and I want to be honest about both sides.

Why Self-Hosting (Payload) Wins

  • Data ownership. Your data lives in your database. Full stop. No vendor can change their terms, sunset a feature, or hold your content hostage.
  • No API rate limits. You're limited by your infrastructure, not an arbitrary plan tier.
  • Cost at scale. Once you pass a certain traffic threshold, self-hosted is dramatically cheaper.
  • Customization depth. Hooks, custom endpoints, custom field types, admin UI overrides — there's nothing you can't change.
  • Colocation with your app. Running Payload and Next.js in the same process eliminates network latency for content queries.

Why SaaS (Hygraph) Wins

  • Zero ops burden. No servers to patch, no databases to backup, no scaling to worry about.
  • Global edge performance out of the box. Hygraph's CDN-backed API is fast everywhere without you configuring anything.
  • Content federation. Hygraph's Remote Sources feature lets you pull data from external APIs into your content graph. This is genuinely powerful for composable architectures.
  • Non-developer friendly. Onboarding content editors is simpler when the schema builder is visual.
  • Uptime guarantees. Hygraph offers SLAs on their enterprise plans. Self-hosted uptime is your problem.

For teams where infrastructure management is a strength (or where they partner with a Next.js development agency that handles it), Payload is the stronger choice. For teams that want to focus purely on content and frontend development, Hygraph removes real friction.

Authentication and Access Control

Payload

Payload has built-in authentication. Users, sessions, email verification, password reset — it's all there. You can define field-level and collection-level access control with functions:

access: {
  read: ({ req: { user } }) => {
    if (user?.role === 'admin') return true
    return {
      publishedAt: { less_than: new Date().toISOString() },
    }
  },
  update: ({ req: { user } }) => user?.role === 'admin',
}

This is real, code-level access control. You can write any logic you want. Need to check against an external service? Go ahead. Need to restrict access based on the current document's fields? Done.

Hygraph

Hygraph uses a system of permanent auth tokens with configurable permissions. You create tokens with specific content stage access (e.g., read PUBLISHED only, read DRAFT, write). For finer-grained control, they support custom permissions tied to roles.

It works, but it's less flexible than Payload's approach. You're configuring permissions through their UI rather than expressing them in code. Complex scenarios — like "editors can only update articles in their assigned category" — require creative workarounds in Hygraph but are trivial in Payload.

Plugin Ecosystem and Extensibility

Payload's plugin ecosystem has grown substantially since 3.0. Notable plugins include:

  • @payloadcms/plugin-seo — SEO metadata fields and previews
  • @payloadcms/plugin-form-builder — Dynamic form creation
  • @payloadcms/plugin-search — Full-text search integration
  • @payloadcms/plugin-redirects — Redirect management
  • Community plugins for Stripe integration, AI content generation, and more

Writing custom plugins is straightforward since they're just functions that modify the Payload config.

Hygraph's extensibility comes through:

  • Apps and sidebar extensions — Custom UI elements in the editor
  • Webhooks — Trigger external workflows on content changes
  • Remote Sources — Federate external GraphQL and REST APIs
  • Management API — Programmatically manage schema and content

Hygraph's app marketplace has grown but is still smaller than Payload's plugin ecosystem. The Remote Sources feature, though, is something Payload doesn't have an equivalent for. Being able to stitch a Shopify product catalog directly into your content graph without middleware is genuinely useful.

When to Pick Which

After working with both on multiple production projects, here's my honest recommendation framework:

Choose Payload CMS if:

  • You're a development team (or working with one) comfortable with TypeScript and infrastructure
  • You need deep customization of the CMS behavior
  • Data ownership and vendor independence matter to you
  • You're building a Next.js app and want the Local API performance advantage
  • You're an agency managing many projects and want to minimize per-project licensing costs
  • You need complex, code-driven access control

Choose Hygraph if:

  • You want zero infrastructure management
  • Your team is already invested in GraphQL
  • You need content federation from multiple sources
  • Your content editors need a polished, visual editing experience out of the box
  • You need guaranteed global edge performance without configuring CDNs
  • Your project timeline is tight and you can't afford setup time

For many of the projects we build at Social Animal — particularly Astro and Next.js projects — Payload has become our default recommendation. The colocation story, TypeScript-native approach, and zero licensing costs align well with how we work. But we've also shipped Hygraph-powered projects for clients whose teams needed the simplicity of a managed platform.

There's no shame in either choice. The shame is in picking one without understanding the tradeoffs. If you're not sure which direction is right for your project, we're happy to talk through it.

FAQ

Is Payload CMS really free? Yes. Payload CMS is MIT-licensed and the core is completely free, including all features — there's no "premium tier" that locks functionality behind a paywall. You pay for your own hosting infrastructure (servers, database, storage). Payload also offers Payload Cloud, their managed hosting service, which starts at $30/month per project if you don't want to manage your own infrastructure.

Can Hygraph work without GraphQL knowledge? The content editing side doesn't require any GraphQL knowledge — editors just use the visual interface. However, developers querying content from Hygraph must use GraphQL. There's no REST API alternative. If your frontend team isn't comfortable with GraphQL, there's a learning curve that you need to factor into your timeline.

How does Payload CMS handle media and file uploads? Payload has a built-in upload system that supports local file storage, S3-compatible storage (AWS S3, Cloudflare R2, MinIO), and other adapters. It includes automatic image resizing, focal point selection, and generates responsive image sizes based on your config. For most projects, connecting it to an S3 bucket or Cloudflare R2 is the recommended approach.

Does Hygraph support localization? Yes. Hygraph has field-level localization built in, meaning you can mark individual fields as localizable rather than duplicating entire content entries. This is a strong feature — you configure your locales in project settings and then content editors can switch between languages in the editor. Payload also supports localization with a similar field-level approach.

Can I migrate from Hygraph to Payload (or vice versa)? Migration is possible but not trivial in either direction. Both systems have APIs that let you export and import content. The main challenge is content modeling differences — especially rich text, which is stored differently in each system. Plan for a migration script and thorough testing. For large content libraries, budget at least 2-4 weeks for a clean migration.

Which CMS is better for e-commerce? Neither is an e-commerce platform, but both integrate well with headless commerce solutions. Hygraph has an edge here with its Remote Sources feature, which can federate product data from Shopify or commercetools directly into your content graph. Payload works great with e-commerce backends too, but you'll typically build the integration yourself using hooks and custom endpoints. For serious e-commerce projects, consider either CMS alongside a dedicated commerce backend.

How does Payload 3.x compare to Payload 2.x? Payload 3.x was a major rewrite. The biggest change is that Payload now runs as a Next.js plugin rather than an Express app. This means your CMS and frontend share the same process, enabling the Local API for zero-latency queries. It also added PostgreSQL support (via Drizzle ORM), live preview, and a redesigned admin UI. If you used Payload 2.x and found it limiting, 3.x is worth another look — it's a fundamentally different experience.

What's the best hosting setup for Payload CMS in 2026? For most projects, we recommend: a VPS or container service (Railway, Render, Fly.io, or a Hetzner VPS with Docker), managed PostgreSQL (Neon, Supabase, or your VPS provider's offering), and Cloudflare R2 for media storage. Total cost typically runs $40-80/month for small-to-medium projects. For larger deployments, Vercel with Payload Cloud or a Kubernetes setup works well. Check our pricing page for how we handle infrastructure setup for client projects.