Hygraph vs Payload

Hygraph and Payload both give a frontend a typed content API, and both are used behind Next.js sites. They differ on who runs the platform and where integration logic lives. Hygraph is a hosted, GraphQL-native content platform from Berlin, sold in plans, with content federation that pulls data from other APIs into its own GraphQL endpoint. Payload is an open source TypeScript application you install in a Next.js project, where the content model, access rules, hooks and integrations are code in your repository.

This page compares Hygraph’s current plans, checked on 29 September 2026, with Payload 3. Hygraph sells three: Hobby, which is free, Growth, from $199 a month, and Enterprise, priced by quote. For the mechanics of a move, see the Hygraph to Payload migration guide. This comparison is about choosing between the platforms.

The short decision

Choose Hygraph when a hosted platform suits the team and its remote sources cover the integrations. One GraphQL query returns CMS content alongside prices or stock from a commerce system, the vendor runs the API and the CDN, and schema changes can still be managed as code through the Management SDK. Check the plan first: custom roles, approval workflows and scheduled publishing sit at the Enterprise tier.

Choose Payload when the integrations, access rules and frontend belong in one TypeScript codebase, with a hosting and operations arrangement that suits the project. Federation becomes code you write and review, with the caching and error handling you choose, and locales, roles and scheduling carry no plan limits.

Where each platform puts the work

A Hygraph project lives in Hygraph’s infrastructure. Hobby and Growth projects run in one of three shared regions, in the EU, the US or Asia-Pacific, and Enterprise adds more shared regions and dedicated clusters. Developers model content in the schema builder and query it through the GraphQL Content API. The Management SDK applies schema changes as code in a single transaction, and environment diffing lists the changes needed to bring one environment in line with another. Hygraph’s documentation reserves environments for schema changes and testing, and says they are not meant for editorial workflows.

Payload runs wherever you deploy it. Collections, fields and access rules are TypeScript, generated REST and GraphQL APIs sit beside a Local API that server code in the Next.js app calls without an HTTP request, and the database is MongoDB, Postgres or SQLite. Payload’s current get-started page offers self-hosting, Vercel and Cloudflare templates, and hosting with Payload for Enterprise customers. The team commissioning the site still needs to agree who manages backups, monitoring and upgrades under the chosen arrangement.

A Hygraph schema change is made in the UI or scripted with the SDK, and the frontend ships on its own schedule. In Payload, a schema change is a commit that updates the admin, the API and the generated types together.

Content federation in Hygraph and Payload

Hygraph describes content federation as combining data from several systems behind one GraphQL endpoint without migrating it. It helps most when another system owns data that changes often, such as price, stock or availability, and editors need to reference it from CMS entries without copying it; Hygraph’s documentation describes editors picking products by SKU or from a product picker. The mechanism is the remote source: a REST or GraphQL API connected to the project, with pre-built configurations for commercetools and Commerce Layer. For REST sources, developers describe the response shape in SDL, GraphQL’s schema language; GraphQL sources are read automatically through introspection.

Remote data reaches the schema in two ways. A remote field on a model enriches an entry, such as a product page whose SKU fetches live price and stock. A top-level remote field on the Query model fetches data unrelated to any entry, so the frontend receives it in the same response.

Three details shape how this behaves in production:

• Caching. Queries that include remote fields are cached for 15 minutes by default. The cache lifetime, or TTL, can be lowered to 60 seconds, and a cache-control header from the remote source overrides Hygraph’s setting.
• Failure. When a remote call fails, the query still succeeds with null for that field and an error message, unless the field is marked required, in which case the whole query fails. Hygraph’s troubleshooting page also advises sensible pagination so bulk queries do not trip the remote API’s rate limits.
• Plan. The pricing page allows no remote sources on Hobby, one on Growth and up to 10 on Enterprise. Two external systems connected as two remote sources need the Enterprise plan.

Payload has no remote-source feature. The same composition is built with its standard extension points, and the choice between them depends on how fresh the data must be:

• Read-time enrichment. A virtual field is not stored in the database, and an afterRead hook fills it when the document is read. This is the closest equivalent to a Hygraph remote field.
• A composed endpoint. Custom GraphQL queries or REST endpoints return CMS content and external data in one response, the equivalent of a top-level remote field.
• A stored copy. A scheduled task in the jobs queue copies external data into a collection, so editors can filter and search it. This suits data that changes hourly or daily.
• Frontend composition. The Next.js app calls the commerce API directly and merges the result with Payload content, often with the framework’s own caching.

An untested, illustrative read-time field, with the commerce endpoint as a placeholder:

// Part of a products collection. COMMERCE_API is a placeholder.
{
  name: 'stock',
  type: 'json',
  virtual: true,
  admin: { readOnly: true },
  hooks: {
    afterRead: [
      async ({ siblingData }) => {
        const baseUrl = process.env.COMMERCE_API
        const sku = siblingData.sku
        if (!baseUrl || sku == null || String(sku).trim() === '') return null

        try {
          const url = `${baseUrl.replace(/\/$/, '')}/stock/${encodeURIComponent(String(sku))}`
          const res = await fetch(url, { signal: AbortSignal.timeout(5000) })
          return res.ok ? await res.json() : null
        } catch {
          return null
        }
      },
    ],
  },
}

This sketch has no cache and returns null for a missing configuration or SKU, an unsuccessful response, a timeout or a request error. Hygraph ships a configured cache and error behaviour; in Payload, the development team writes both. Where the frontend already fetches from the commerce system, federation in the CMS may not be needed at all.

Content modelling, components and assets

A Hygraph schema is built from models, which hold standalone entries, components, which embed a reusable set of fields inside an entry, and enumerations. A basic component field holds one component type and a modular one allows several, which suits page-builder layouts. Plans cap the counts: 20 models and 10 components on Hobby, 40 and 20 on Growth, and up to 500 and 150 on Enterprise. The Studio interface shows up to 50 component instances per entry, and instances beyond that stay queryable through the API without appearing in the editor.

Payload models the same content as collections and globals. Its blocks field plays the role of a modular component, and arrays and groups cover the basic case. The config sets no count limits.

Hygraph stores assets without a storage cap and limits upload size by plan: 50 MB on Hobby, 200 MB on Growth and up to 5 TB on Enterprise. Asset traffic is 100 GB, 500 GB or 25,000 GB and more, and on Growth traffic past the allowance is billed. Payload stores uploads through storage adapters for S3, Azure, Google Cloud Storage, R2, Vercel Blob or UploadThing, so size and traffic limits come from the storage provider and the hosting platform. Image transformations differ as well: Hygraph applies them through a transformation argument on the asset URL, and a Payload build generates image sizes on upload or uses an image service.

Editorial workflow, versions and scheduling

Every Hygraph plan has the DRAFT and PUBLISHED stages, live preview, and commenting with assignment. The rest of the governance set is tiered. Enterprise allows up to five content stages, so custom ones such as QA or legal review can sit between the two system stages. It also includes Custom Workflows, up to 10: a workflow assigns roles to each step, sets whether entries can be edited at that step, and publishes automatically when an entry reaches a step with a stage attached. Scheduled publishing and Releases, which publish a bundle of entries together, are Enterprise features too.

Versions in Hygraph are created when content is published to a stage, and draft saves are not versioned. Retention is 14 days on Growth and up to 365 days on Enterprise, and Hobby has none.

Payload’s drafts and versions are in core, with autosave, diffs and restore, and a default of 100 versions per document that can be raised or removed. Scheduled publish and unpublish are in core too; they run through the jobs queue, so the deployment needs a job runner. A collection-level update access rule can constrain publishing using _status. Payload core has no named approval stages. They come from Publishing Workflows, an enterprise feature, or a team builds them with access rules and hooks.

Hygraph’s live preview shows saved drafts and refreshes when the editor clicks Save & Preview. Payload’s Live Preview sends every change to the frontend iframe through postMessage, so the page updates as the editor types.

Localization and permissions

Both platforms localize at the field level. Hygraph’s localization is limited by plan: two locales on Hobby, three on Growth and up to 80 on Enterprise. Payload’s localization sets no limit on locales, with fallback to a default locale switched on unless you turn it off.

Hygraph gives every project a fixed set of system roles: Owner, Admin, Developer, Editor and Contributor, with the pricing page counting two standard roles on Hobby and four on Growth. Custom roles, up to 30, are Enterprise only, and they can scope content permissions by model, locale, stage and condition. Content permissions are set per environment. Payload’s access control is a set of functions per collection, document, field and operation, which can combine the user and the document’s data in one rule.

SSO and audit logs are enterprise features from both vendors, listed on Hygraph’s pricing page and Payload’s enterprise page.

APIs, limits and environments

Hygraph’s API limits apply to uncached requests in shared regions. Requests per second are capped at 5 on Hobby, 25 on Growth and up to 500 on Enterprise, and concurrent operations per environment at 10, 30 and 60 queries. Query size is capped too, from 10 KB on Hobby to 20 KB on Enterprise. Requests served from the CDN cache are not limited. Hygraph’s documentation includes throttling examples for static builds in Next.js, Gatsby and Nuxt, which fetch many pages at once.

Environments are plan-limited: one on Hobby, two on Growth and up to 10 on Enterprise. Each has its own endpoint, content and webhooks, and promoting one to master means renaming it.

Payload’s limits depend on the deployment and any provider contract; environment isolation is configured through deployments and databases.

Cost inputs

Hygraph’s Hobby plan is free, with 3 seats, 1,000 entries and 500,000 API calls. Growth starts at $199 a month with 10 seats, 10,000 entries, 1,000,000 API calls and 500 GB of asset traffic. Assets count against the entry limit. On Growth, usage past the limits is charged at the end of the billing period: $0.20 per 10,000 API operations and $0.20 per GB of asset traffic. On Hobby, usage is blocked until the next period. Enterprise is priced by quote, and it is where most of the features in the previous sections sit.

Payload’s core is MIT licensed with no fee. The cost lines are hosting, the database, file storage, backups, upgrades and the engineering time to build and maintain the site and its integrations. Payload’s enterprise features are priced after a demo request.

Price the same editors, locales, environments, traffic and integrations on both sides. On Hygraph the variables are the plan and usage. On Payload they are hosting and engineering hours.

Exit and lock-in

Hygraph’s content leaves through the Content API, up to 100 entries per request on projects created after 14 June 2022. Hygraph offers project cloning and schema import between Hygraph projects, and Enterprise backups restore into a new environment; all three keep the content inside Hygraph. Federated data stays in its source systems, so nothing federated is exported.

Payload’s content sits in MongoDB, Postgres or SQLite. Self-hosting gives you direct database access; on a managed arrangement, confirm export and backup access in the contract. Leaving Payload means moving the content model and the behaviour built around it: access rules, hooks, integrations and the frontend queries. That work is proportional to how much of the site’s logic lives in code.

When staying on Hygraph is the right call

A Hygraph project that fits its plan and uses remote sources as designed is a working setup. If the team has a GraphQL frontend, one remote source served well by remote fields and cached for minutes, few enough locales and seats for Growth, and no need for approval stages, the case for moving is weak. The same is true on Enterprise when the contract already covers custom roles, workflows and releases the team uses.

Moving starts to make sense when plan limits force an Enterprise upgrade for one or two features, when integrations need behaviour remote fields do not offer, such as writing back to another system, or when the frontend team wants the content model in the same repository and deployment as the site.

What a move to Payload rebuilds

Plan for the content export through the paginated Content API; models, components and enumerations mapped to collections, blocks and select fields; assets and their URLs, including any stored in plain text fields; localized fields carried field by field; remote sources and remote fields replaced by hooks, endpoints, jobs or frontend calls; workflows, roles and webhooks; and the frontend’s GraphQL queries, which change shape.

The migration guide walks through each of these, including the pagination limits and the federation layer. Price each item before committing.

Two decision scenarios

Both scenarios are illustrative. They are not client projects.

A retailer’s content site with two external systems. A retailer runs editorial and campaign pages in a headless CMS. Prices and stock live in commercetools, and product reviews come from a review service’s REST API. Six editors publish in two languages, and the frontend is Next.js. On Hygraph, the commercetools source is a pre-built remote source and reviews are a custom REST source, which means two remote sources and an Enterprise plan. Price and stock arrive in the same query as the page, cached for 15 minutes unless the TTL is lowered. On Payload, the page stores SKUs, a virtual field or a custom endpoint fetches price and stock at read time, and a scheduled job copies reviews into a collection each night so editors can feature them. The development team writes and maintains that code and decides the cache. The decision comes down to two numbers: the Enterprise quote, and the engineering time for the integrations plus hosting.

A multilingual B2B site with an approval step. A manufacturer publishes in six languages. Twenty-five people edit, a legal reviewer must approve product claims before publication, and launches go live on fixed dates. On Hygraph, six locales, more than 10 seats, custom roles, an approval workflow and scheduled publishing all sit at the Enterprise tier, which then covers everything on the list. On Payload, six locales, the seats and scheduled publishing carry no plan cost, and an access rule can limit publishing to the legal reviewer’s role. A named approval stage is custom work or Payload’s enterprise Publishing Workflows. The comparison is an Enterprise contract against a build and a hosting owner.

A short evaluation checklist

Run these with your own project before choosing:

• Integrations. List every external system the pages read from. Mark how fresh each needs to be and what should happen when it is down.
• Plan features. List the locales, seats, roles, workflow steps, scheduling and environments you need, and find the Hygraph plan that includes them.
• Traffic. Estimate uncached API requests, peak build traffic and asset traffic against Hygraph’s limits and overage prices.
• Workflow. Write down who drafts, reviews and publishes each content type, and whether named approval stages are required.
• Frontend. Note where the frontend lives and whether the team wants the content model in the same repository.
• Operations. Name who will host, back up, patch and monitor a Payload deployment under the proposed arrangement.
• Exit. Count entries per model and list the configuration that would be rebuilt if you left either platform.

A note on our position

WAYF is a Payload partner and contributes to its open source, so we have an interest in this comparison. We recommend Hygraph when its hosted platform, plans and remote sources fit the project, and a delivery partner can build on either.

If you choose Payload, WAYF’s Payload development service covers the build. For a move from Hygraph, plan the replatforming around the content, integrations and workflows that need to move.