Drupal vs Hygraph (2026): Owning a Content Repository vs Renting a GraphQL Layer

Hygraph and Drupal answer different questions. Hygraph asks: what's the fastest way to give a frontend team one GraphQL endpoint, even if the content behind it lives in five other systems? Drupal asks: what's the most durable way to model and own your content, with GraphQL as one interface among several?

Pick Hygraph and you're renting a schema-first GraphQL layer, billed by the entry and the API call, with a genuinely clever trick — Content Federation — for stitching in PIM, DAM, and commerce data. Pick Drupal and you're running an entity system you control outright, with unlimited content volume, translation and moderation built into core, and GraphQL bolted on via contrib rather than baked in.

This is for a team choosing between the two, or evaluating decoupled.io, which runs Drupal underneath and gives you both APIs without picking a camp. If your stack already speaks GraphQL and your content sources are scattered, read with that lens. If you're the one justifying hosting costs eighteen months from now, read the pricing section closely — it's where this comparison gets decided.

The short answer

• If your team is GraphQL-first and wants one endpoint over multiple backends, Hygraph's Content Federation has no real equivalent in Drupal.
• If you don't know your entry count for the next three years, Drupal's unmetered entities are safer than Hygraph's per-entry billing.
• Hygraph gets a new project querying data in an afternoon; Drupal takes longer to stand up and rewards you for the setup time later.
• Drupal owns editorial workflow, revisions, and localization in core; Hygraph's equivalents are real but are add-ons on top of a proprietary base.
• You cannot self-host Hygraph under any plan — if vendor lock-in worries you more than operational burden, that alone should end the conversation.
• Neither platform is the wrong choice; they're built for different failure modes — Hygraph fails gracefully at small scale, Drupal fails gracefully at large scale.

Side by side

Content modeling

Drupal's content model is entities and fields, and every entity — nodes, users, taxonomy terms, media, comments — gets the same machinery: revisions, fields, permissions, and JSON:API for free. Paragraphs give reusable component content inside a node. Taxonomy vocabularies give real relational structure, not just tags. This is twenty-plus years of edge cases already handled: multi-value fields, deep entity references, computed fields, bundle-specific view modes. It's not elegant in the admin UI, but it's exhaustive.

Hygraph's modeling is schema-first: you define models and components in a schema editor, and the platform generates a GraphQL schema and API automatically. Components give you reusable content blocks, similar in spirit to Paragraphs but scoped to the GraphQL type system. The distinctive move is Content Federation — remote sources register external REST or GraphQL APIs (a PIM, a DAM, a commerce backend) into one unified schema with TTL caching, so a frontend queries one endpoint for fields that actually live in three systems. Drupal has migration tooling to pull external data in, but nothing that federates live external APIs into a single GraphQL surface at query time. That's a real, distinct capability, not marketing.

Where Drupal pulls ahead again: entity references and revisions apply uniformly across the whole model, and there's no cap on how many content items you can create. Hygraph's Growth plan caps you at 10,000 entries — for a commerce catalog or a large content archive, that's a real ceiling, not a rounding error.

Developer experience and APIs

Hygraph is genuinely pleasant if you write GraphQL for a living. Schema-first modeling, a GraphQL Playground, one endpoint, generated types, a Management SDK, and code examples for Next.js, Nuxt, and Astro out of the box. REST exists but is auto-generated from the GraphQL schema and clearly secondary — if your team wants REST as a first-class citizen, this isn't the platform for it.

Drupal ships JSON:API in core since Drupal 8.7 (2019) — every entity gets a fully-featured REST-style endpoint with zero configuration, filtering, sparse fieldsets, includes. GraphQL support comes from the contributed graphql_compose module, which generates a schema from your entity types; it's solid but not core, so it's one more dependency to track through upgrades. See the headless Drupal guide for how JSON:API, GraphQL, and a Next.js frontend fit together. If your mental model is "GraphQL is the API," Hygraph will feel native and Drupal adapted. If you want both a REST-shaped and a GraphQL-shaped interface without picking one as primary, Drupal offers more breadth once graphql_compose is in place.

Neither has an edge on webhooks — both offer them — but Hygraph's environments (for staging schema changes and cloning projects) are a nicer built-in workflow than Drupal's equivalent, which typically means separate environments managed at the hosting layer.

Editorial experience

Drupal's editorial core is content moderation and workflows: custom states, role-based transitions, and — critically — every entity carries full revision history natively, with translations getting their own revisions and their own moderation state. That's not a plugin; it's how the system fundamentally works. Permissions are fine-grained and role-based, also in core.

Hygraph offers versioning (14-day retention on Growth, 365-day on Enterprise), scheduled publishing, workflows, custom roles, and conditional permissions — a credible feature set, but versioning depth is tiered by plan rather than uniform, and it's layered onto a SaaS product rather than built into an underlying content system the way Drupal's is. Hygraph's visual editing (Click to Edit) is new and, by Hygraph's own emphasis, basic today. Drupal Canvas, the newer visual builder in Drupal CMS 2.x, is also young and less mature than dedicated visual editors elsewhere — this section is a wash, not a Drupal win by default.

Localization is where Drupal is structurally stronger: translations are first-class entities with their own revisions and moderation states, and language negotiation is built in. Hygraph does per-locale publishing and locale-specific roles, covering most teams' needs, but per-locale content still counts against the entry cap.

Pricing and total cost of ownership

Hygraph's public pricing: Hobby is $0 forever — 3 seats, 1,000 entries, 500K API calls/month, 2 locales, 20 models, 100 GB traffic. Growth is $199/month — 10 seats, 10,000 entries, 1M API calls, 1 remote source, 14-day versions, email support. Enterprise is custom — 1M+ entries, 50M+ API calls, up to 10 remote sources, SSO, 365-day versions, 99.95% SLA. Overages run $0.20 per 10,000 API operations and $0.20 per GB of asset traffic. (As of April 2026 per Hygraph's own pricing page; re-verify at hygraph.com/pricing before quoting.)

The number to watch is entries, not seats. 10,000 sounds like a lot until you count locale variants, draft versions, and every SKU in a catalog. Metered volume is Hygraph's central tradeoff: predictable low cost until you cross a threshold, then a step up to Enterprise pricing — also where Content Federation beyond one remote source lives.

Drupal has no vendor-imposed entry, seat, or API-call cap. Your cost is infrastructure and labor: for a mid-size site, roughly $50–$500/month in cloud infrastructure plus developer time for updates — a range, because it depends on traffic, whether you self-manage or pay an agency, and how aggressively you patch. There's no bill that jumps when you cross an entry count; only the ongoing labor of running PHP, Composer, and a database, which doesn't scale with content volume the way Hygraph's metering does.

Worked example: 10 editors, 3 locales, 50,000 entries, 2 million API calls/month.

• Hygraph: 50,000 entries and 2M API calls both blow past Growth's 10,000-entry / 1M-call limits, so this team needs Enterprise custom pricing. Hygraph doesn't publish Enterprise numbers, so treat the cost here qualitatively — expect a meaningful step up from $199/month, not a linear one.
• Drupal: 50,000 entries costs nothing extra — there's no entry pricing. Infrastructure for this traffic level likely lands in the $200–$500/month range, plus a few hours a month of maintenance. Three locales are free in core. Total: infrastructure plus labor, not infrastructure plus a metering bill.

At this scale, Drupal's unmetered model is the more honest comparison point — Hygraph's pricing suits lighter content volumes, and this workload pushes you into custom-quote territory fast.

Operations, hosting, and security

Hygraph removes the hosting decision entirely — there's no server to patch, no PHP version to migrate, no database to back up yourself. That's a genuine operational win, especially for small teams without dedicated infrastructure staff.

Drupal is the opposite: you, or your host, own PHP, Composer, the database, caching, and applying updates. Drupal has a dedicated Security Team that publishes advisories, which is a strength — real, transparent notice — but acting on it is your job if you self-host. Hosting ranges from doing it yourself, to enterprise Drupal PaaS like Acquia and Pantheon (often $1,000s/month at enterprise tiers), to Platform.sh, to managed options like decoupled.io that apply core and security updates automatically. The operational burden is real and shouldn't be softened — it's the most legitimate reason a small team picks Hygraph over Drupal.

Lock-in and exit

Hygraph is fully proprietary. There's no self-hosted version, and leaving means exporting content and schema through their API — workable and well-documented, but a migration project, not an export button.

Drupal, self-hosted or on decoupled.io, is standard Drupal underneath. Export the database and configuration and run it anywhere that runs PHP. That portability is structural, not a feature someone added — it's what open source means. See the two-stack problem for why keeping backend and frontend separable matters as a project grows.

Choose Hygraph if…

• Your team is GraphQL-first end to end and wants a schema-first, playground-driven workflow with no adaptation layer.
• You need to unify content from a PIM, DAM, or commerce backend into one queryable API and don't want to build that plumbing yourself.
• You want zero hosting responsibility and can live inside a metered entry/API-call budget.
• You're starting small and want a real, usable free tier to prototype against.

Choose Drupal if…

• You don't want a vendor counting your content items or API calls.
• Editorial workflow, granular permissions, and translation-with-revisions need to be foundational, not bolted on.
• You expect to outgrow a starting content volume and don't want a pricing cliff when you do.
• Owning your data layer, and being able to walk away from any single vendor, matters more than shaving weeks off initial setup.

The best of both worlds

decoupled.io runs a real Drupal instance per customer: Drupal's entity system, unmetered content, and core translation and moderation, plus GraphQL and JSON:API on every tier with an auto-generated typed TypeScript client — no graphql_compose setup required. Core and security updates apply automatically, addressing Hygraph's strongest argument against self-hosted Drupal. Pricing is flat: Free, Starter at $20/month, Pro at $60/month — no per-entry, per-seat, or per-API-call metering.

What decoupled.io does not match: Content Federation. If you need to pull a PIM, DAM, and commerce backend into one GraphQL schema with TTL caching, Hygraph's remote-sources model has no equivalent here — Drupal's migration tooling can import external data, but it doesn't federate live APIs into one endpoint at query time. If federation is why you're evaluating Hygraph, decoupled.io isn't a substitute.

See pricing, or read the fuller Decoupled.io vs Hygraph comparison for a feature-by-feature breakdown. If you're weighing decoupled Drupal as a concept more broadly, what decoupled Drupal means and Drupal vs Contentful — the closest comparison in this series to a proprietary structured-content SaaS — are useful next reads.

FAQ

Is there a migration path from Hygraph to Drupal or decoupled.io? There's no published, dedicated "migrate from Hygraph" guide today. In practice, Hygraph's GraphQL Management API and Content API can export both schema and entries, and Hygraph's models map reasonably well onto Drupal content types and fields, but expect a real migration project — writing an export script against Hygraph's API and an import against Drupal's — rather than a one-click tool.

Why does Hygraph cost more as I add content, when Drupal doesn't? Hygraph bills by entries and API calls because it's a managed SaaS charging for the resources it hosts and serves on your behalf — Growth caps out at 10,000 entries and 1 million API calls before you're pushed to custom Enterprise pricing. Drupal has no entry or call metering because you (or your host) own the infrastructure directly; your costs are infrastructure size and maintenance labor, which don't scale per content item the way a vendor's metered bill does.

Does Drupal have anything like Hygraph's Content Federation? Not at the platform level. Drupal can import and migrate external data into its own entity system, and can query external APIs from custom or contrib code, but there's no equivalent to Hygraph's remote-sources feature that federates live external REST/GraphQL APIs into one unified GraphQL schema with built-in caching. This is a legitimate Hygraph win, not a close call.

Is GraphQL a first-class feature in Drupal the way it is in Hygraph? No, and it's honest to say so plainly: GraphQL in Drupal comes from the contributed graphql_compose module, not core, while JSON:API is core. Hygraph is the reverse — GraphQL is the native, primary interface and REST is auto-generated and secondary. Teams whose whole stack is GraphQL will find Hygraph's approach more idiomatic; teams that want REST as a true first-class option alongside GraphQL will find Drupal's JSON:API-plus-contrib-GraphQL combination more balanced.

Part of the Drupal vs the headless CMS field series.