Wagtail vs Hygraph.
Which headless CMS in 2026?

If you're evaluating headless CMS platforms in 2026 and you want something more developer-friendly than Contentful, Hygraph is usually the next name on the shortlist. It's GraphQL-native, has a polished editorial UI, and ships with a feature few competitors match — content federation that lets you query content from external sources alongside your CMS content in a single GraphQL request.

Wagtail, meanwhile, is what most teams reach for when they want a CMS that lives inside their own application — open-source, Python-first, hosted on infrastructure they control. The two products solve overlapping problems from completely different angles. This is the comparison we give clients when they ask which way to go.

01The fundamental difference

It's tempting to compare features first, but the choice between Wagtail and Hygraph is really a choice between two operating models — and that decision shapes everything downstream.

Hygraph is a cloud-hosted SaaS headless CMS. You define your content schema in a web UI, manage entries through that UI, and consume content via Hygraph's hosted GraphQL endpoint. Your content lives on Hygraph's AWS infrastructure. You pay a subscription that scales with usage.

Wagtail is an open-source Django CMS. You install it as a Python package, define content models in code, deploy it on infrastructure you control, and serve content either as rendered pages or via your own API. Your content lives in your own PostgreSQL database. You pay for hosting — there is no licence fee.

That distinction — managed SaaS versus self-hosted open source — is the lens through which every other feature comparison should be read.

02Content modelling

Both platforms have strong content modelling capabilities, but they approach the problem from opposite ends.

Hygraph models are defined visually. You drag field types onto a content type, set validation rules, connect references, and Hygraph generates a GraphQL schema for you. It's productive, immediate, and accessible to non-developers. The cost: your content schema lives in Hygraph's database, not in your version control. There's no pull-request review of schema changes, no easy way to diff staging vs production, and "promoting" model changes between environments is a manual operation supported by Hygraph's "environments" feature — but still not git-native.

Wagtail models are defined in Python. A news article, a case study, a product page — each is a Django model with Wagtail's field types. This means your content model lives in your codebase, versioned in git, reviewed in PRs, and deployed atomically with your application.

class ArticlePage(Page):
    deck = models.CharField(max_length=255)
    published_at = models.DateTimeField()

    body = StreamField([
        ('paragraph', RichTextBlock()),
        ('pullquote', BlockQuoteBlock()),
        ('image',     ImageChooserBlock()),
        ('embed',     EmbedBlock()),
    ])

    api_fields = [
        APIField('deck'),
        APIField('published_at'),
        APIField('body', serializer=StreamFieldSerializer()),
    ]

If your team is developer-led, the code-first approach is more rigorous. Schema migrations are typed, reviewable, and reversible. If your team includes non-developers who need to evolve the model themselves, Hygraph's UI is genuinely faster.

03GraphQL & content federation

This is Hygraph's standout feature, and the reason it earns serious consideration on architecturally ambitious projects.

Hygraph's Content Federation lets you stitch external sources — REST APIs, other GraphQL endpoints, even databases — into your CMS's GraphQL schema. From the frontend's perspective, it's a single GraphQL query. The CMS proxies and resolves the federated parts behind the scenes. For projects where content lives across multiple systems (a product catalogue in one service, marketing copy in another, user profiles in a third), this is genuinely powerful.

Wagtail's API is built on Django REST Framework, with optional GraphQL through the wagtail-graphql or wagtail-grapple packages. There's no built-in content federation — but because Wagtail is a Django application, you can do exactly the same thing in code: a resolver that reaches out to other services and composes the response. It's just explicit work rather than a UI toggle.

# A Wagtail API view that federates content from a product service
class ArticleViewSet(viewsets.ModelViewSet):
    async def retrieve(self, request, slug=None):
        article = await ArticlePage.objects.aget(slug=slug)

        # Fetch related products from a separate service in parallel
        async with httpx.AsyncClient() as client:
            products = await client.get(
                f"https://catalogue.internal/api/products?ids={article.product_ids}"
            )

        return Response({
            "article": ArticleSerializer(article).data,
            "products": products.json(),
        })

If federation is a first-class requirement and your team isn't going to want to build resolvers themselves, Hygraph saves you real engineering time. If you have Python developers and federation is one feature among many, building it yourself in Wagtail gives you complete control over caching, error handling, and authorisation.

04Pricing & total cost of ownership

Hygraph's free tier is more generous than Contentful's — useful for prototypes — but it caps content count, asset storage, and API calls in ways that production sites quickly outgrow. The Growth plan starts around $299/month, the Scale plan around $899/month, and Enterprise is a custom contract. The "Pro" tier in between is roughly $599/month. Like all SaaS, costs grow with usage.

Wagtail itself is free. You pay for hosting — a well-configured VPS or PaaS instance for most projects costs £50–250/month, plus modest CDN spend for media. For high-traffic sites the operational cost rises, but you control where the costs come from (compute, database, CDN) rather than being locked into a per-seat or per-API-call model.

The TCO question isn't "which is cheaper this month?" — it's "where do my costs sit in three years?" SaaS gives you predictable monthly spend and zero infrastructure overhead. Self-hosted gives you variable spend driven by your own decisions, and ownership of the platform.

05Editorial experience

Hygraph's editorial UI is genuinely good — arguably the best in the SaaS headless space. The content editor is fast, the asset library is well-designed, and the GraphQL playground is built in for developers. Localisation, scheduled publishing, and content references all work without surprises. The interface is more polished than Contentful and more developer-focused.

Wagtail's editorial interface is excellent in a different way. The page tree gives editors a clear mental model of the site. StreamField provides rich in-context page editing — closer to a traditional CMS experience than to Hygraph's structured-data approach. Wagtail also has features that Hygraph's lower tiers don't match: per-page moderation workflows, full revision history with side-by-side diff, scheduled publishing at the page level, and contextual help panels designed around the actual content model.

If your editors think in terms of "pages and content trees," Wagtail wins. If they think in terms of "structured entries that get queried," Hygraph wins. Most editorial teams in our experience think the first way — which is why Wagtail tends to be the better fit for publishing and content-heavy organisations.

A few specific features that matter more than they look on a feature list: Wagtail's live preview renders the actual page (not a mockup) using the unpublished draft, so editors see exactly what they'll publish. Hygraph's preview is preview-of-data — a separate URL feeding the same frontend, which requires extra plumbing to make work properly with Next.js or SvelteKit. Wagtail's content workflow supports per-page approval chains where Editor A submits, Reviewer B approves, and Publisher C schedules. Hygraph supports workflow but the lower tiers don't expose the full state machine. Wagtail's revision diff shows side-by-side comparisons of any two historical versions; Hygraph keeps revision history but the UI is less editorial-friendly.

06Performance & scale

Both platforms can serve high-traffic sites, but the performance envelope and the levers you have available are very different.

Hygraph's GraphQL CDN sits in front of every read query. Content delivery is fast globally because cached responses are served from edge nodes. The trade-off: cache invalidation is on Hygraph's terms, queries that include personalisation or auth bypass the CDN, and your origin throughput is capped by the plan you're on. We've seen production sites where API call limits became a constraint long before user demand did — particularly on listing pages that re-query on every navigation.

Wagtail's performance is whatever you build it to be. The defaults are good — Django's ORM is fast, PostgreSQL handles complex queries well, and Wagtail's image rendition pipeline is efficient. For high-traffic sites, you add Redis caching (typically as a Django cache backend plus query cache), a CDN in front of static rendered pages, and persistent database connections. Headless Wagtail with Next.js ISR (Incremental Static Regeneration) gives you near-static performance with editorial updates propagating within seconds.

from django.views.decorators.cache import cache_page
from django.views.decorators.vary import vary_on_headers

@cache_page(60 * 15)  # 15 min edge + redis cache
@vary_on_headers('Accept-Language')
def article_view(request, slug):
    article = get_object_or_404(ArticlePage, slug=slug, live=True)
    related = article.get_related().live()[:4]
    return render(request, 'article.html', {
        'article': article,
        'related': related,
    })

On real projects, headless Wagtail behind a CDN routinely delivers sub-200 ms time-to-first-byte from anywhere in the world. Hygraph at the same scale delivers comparable performance — but you pay for it monthly, and you don't control the cache TTL or the invalidation strategy.

07Multi-language & localisation

Both platforms support multi-language content, but the workflow for translators differs in ways that matter on real projects.

Hygraph has locales as a first-class concept. You define which locales exist, mark fields as localised, and the GraphQL API surfaces locale-specific responses. Translators see a single content entry with fields tabbed by locale. Fallback chains (show English if French isn't ready) work out of the box. For straightforward "translate the page into X languages" projects, this is genuinely productive.

Wagtail's localisation lives in wagtail-localize, an officially-maintained module. The model is different: each translation is a separate page object that's linked to its source. Translators work on the target language as a complete page, with Wagtail handling segment-level diff against the source. This sounds heavier — and it is, slightly — but it gives you per-locale workflow (a French page can be in moderation while the English page is published), per-locale URLs without redirects, and the ability to commission proper translation agency review rather than field-by-field updates.

For straightforward translation, Hygraph is faster to set up. For sites with serious editorial governance — universities, public sector, regulated industries where each locale has its own editorial chain — Wagtail's model is genuinely more capable.

08Webhooks & integrations

Modern content workflows rarely sit alone — there's a search index to rebuild on publish, a static site to redeploy on schema change, a Slack notification to send on workflow events, and increasingly an AI step somewhere in the chain.

Hygraph fires webhooks on every meaningful event (publish, unpublish, schema change, asset upload) with a configurable JSON payload. Integration is easy — most projects need an hour to wire up Netlify build hooks, Algolia reindex, or Slack notifications. Zapier and n8n connectors are first-party. The downside is that complex integrations (conditional logic, transformations, retries with backoff) live in those external tools rather than your codebase.

Wagtail uses Django signals for in-process events (page_published, page_unpublished, etc.) and you can layer webhooks on top. The integration code lives in your application, which means it's testable, versioned, and can call into your domain logic without round-tripping through an external service.

from wagtail.signals import page_published
from django.dispatch import receiver

@receiver(page_published)
def on_publish(sender, instance, **kwargs):
    # 1. Reindex search
    search.reindex(instance)
    # 2. Trigger ISR revalidation for the frontend
    revalidate.delay(instance.url)
    # 3. Generate AI SEO metadata if missing
    if not instance.search_description:
        ai_summarise.delay(instance.pk)
    # 4. Notify Slack for editorial review
    slack.post("#content", f"Published: {instance.title}")

For simple integrations, Hygraph is faster. For integrations that involve transformations, conditional logic, or calls into your domain layer (typical of any non-trivial product), Wagtail's signal-based approach is significantly more maintainable — and avoids a class of failure modes where Zapier rules silently rot.

09Migration paths

Whichever side of this comparison you're on, migration is a recurring conversation. We do roughly one Contentful/Hygraph-to-Wagtail migration per quarter, and occasionally the reverse — so here's what's actually involved.

Hygraph → Wagtail typically takes 4–8 weeks for a mid-sized site, depending on schema complexity. The work splits into: (1) translating the GraphQL schema into Django models with equivalent field types, (2) writing a one-shot import script that pages through Hygraph's API and creates corresponding Wagtail pages, (3) translating queries from GraphQL into Django ORM calls or the Wagtail API, and (4) frontend adjustments. Assets transfer via download-and-upload through Wagtail's image/document chooser pipeline. The trickiest part is usually rich-text content — Hygraph's rich text format needs to be normalised into Wagtail's StreamField shape, and any embedded references need to be remapped.

Wagtail → Hygraph is rarer but follows the inverse pattern. The main constraint: Hygraph's content model has shape limits (depth of nested types, length of select-list options) that occasionally need workarounds for rich Wagtail StreamFields. We've done it a handful of times for clients who outgrew Python in-house and wanted to consolidate on SaaS.

The wider point: migration is doable in both directions, but it's never trivial. The cost of migrating off a platform should factor into the choice — and is one of the strongest arguments for self-hosted open source. If a SaaS vendor pivots, raises prices, or gets acquired, your migration cost is the leverage they have over you.

10Vendor lock-in & data ownership

Hygraph provides export tools (its hygraph-cli and Migration Management API), so you can extract content if you decide to move off. But the schema is described in Hygraph's own format and the GraphQL endpoint you've built your frontend against is theirs. Migrating away is a real project — typically months of engineering time depending on the size of the schema.

Wagtail's content lives in your PostgreSQL database. You own it. The schema is in your codebase. Moving to a different CMS or to a different version of Wagtail is a controlled, in-house exercise. For organisations with data residency requirements (the UK public sector, EU GDPR-sensitive industries, universities), self-hosted is frequently the only viable option regardless of other considerations.

This is not an abstract concern. SaaS vendors get acquired, change pricing, deprecate features, or pivot. Hygraph itself rebranded from GraphCMS in 2022 and has since refocused around content federation. Your platform commitments outlive most product strategies.

11When to choose each

12Our honest recommendation

For most of the publishers, universities, non-profits, and scale-ups we work with, Wagtail is the better choice. The economics are more favourable at any meaningful scale, the editorial experience is stronger for content-heavy teams, the data ownership story is cleaner, and Python integration with the rest of the business is often essential.

Hygraph is genuinely good at what it does. If your project is API-first from day one, you need content federation in the platform rather than in your own code, and you have no in-house Python capability, it's a reasonable choice — and a more developer-friendly one than Contentful. But the narrative that "modern headless CMS = SaaS" is a simplification. A well-built Wagtail headless deployment delivers the same headless experience with markedly better economics and much stronger control.

The honest answer depends on your team, your content, and your trajectory. We're happy to talk through which one fits — and we'll tell you when Hygraph is the right call, even though we build in Wagtail.