Eu construí projetos em produção com todos esses três CMSes nos últimos quatro anos. Alguns foram greenfield builds, outros foram migrações do WordPress ou sistemas legados que estavam desmoronando. Toda vez que um cliente me pergunta "qual headless CMS devemos usar?", resisto a dar uma resposta única que serve para tudo — mas depois de disponibilizar dezenas de projetos em 2025 e chegando em 2026, tenho opiniões fortes respaldadas por cicatrizes do mundo real.

Este artigo analisa Contentful, Sanity e Payload CMS nas dimensões que realmente importam quando você está construindo algo real: preços em escala, experiência do desenvolvedor na trincheira, flexibilidade de modelagem de conteúdo, design de API e o fluxo de trabalho editorial do dia a dia que seu time de conteúdo vai amar ou odiar.

Índice

Contentful vs Sanity vs Payload: Comparação de Headless CMS 2026

Visão Geral de 30 Segundos

Contentful é o detentor do mercado. Existe desde 2013 e alimenta sites empresariais em escala. É polido, confiável e caro.

Sanity é a queridinha dos desenvolvedores com sua abordagem de conteúdo em tempo real e estruturado e studio customizável. É poderoso, mas tem uma curva de aprendizado e um modelo de preços que pode surpreendê-lo.

Payload é a startup que silenciosamente se tornou um concorrente sério. É open-source, self-hosted por padrão (com uma opção em nuvem agora), escrito em TypeScript e cobra zero de taxas de licença. Em 2025, Payload 3.0 foi lançado com uma reescrita completa sobre Next.js, e isso mudou completamente a equação.

Funcionalidade Contentful Sanity Payload
Tipo SaaS SaaS (self-host studio) Open Source / Self-hosted
Linguagem N/A (apenas API) JavaScript/React TypeScript/Next.js
Taxa de Licença Sim Sim (baseado em uso) Nenhuma (MIT)
GraphQL Sim Sim (GROQ preferido) Sim (auto-gerado)
API REST Sim Sim Sim (auto-gerado)
Colaboração em Tempo Real Limitada Excelente Boa (2.0+)
Self-hosting Não Apenas studio Stack completo
Base de Dados Proprietária Proprietária MongoDB ou Postgres

Detalhamento de Preços: O Que Você Realmente Pagará

É aqui que as coisas ficam reais. Preços é a razão número um pela qual vi times trocarem de CMS no meio do projeto, e é a coisa número um que as pessoas subestimam durante a avaliação.

Preços do Contentful (2026)

O free tier do Contentful oferece 1 space, 5 usuários e 25K chamadas de API. Isso é bom para um blog.

O plano Basic começa em $300/mês e oferece mais ambientes e roles. O plano Premium — que é o que a maioria dos times sérios precisa — é precificado sob demanda, mas normalmente começa em torno de $2.000-$3.000/mês para organizações de médio porte. Vi contratos empresariais acima de $80K/ano.

O detalhe: sobrecarga de chamadas de API. Contentful cobra por chamadas de Content Delivery API, chamadas de Content Management API e largura de banda de assets separadamente. Em um site com alto tráfego fazendo 10M+ visualizações de página/mês, você pode facilmente exceder as cotas incluídas. Um cliente com o qual trabalhei viu sua conta mensal pular de $2.500 para $4.800 após um lançamento de produto viral por causa de sobrecarga de CDN e API que não anteciparam.

Preços da Sanity (2026)

Sanity usa um modelo baseado em uso que chamam de "pay as you grow". O plano Free inclui 3 usuários não-admin, 500K solicitações de API, 20GB de largura de banda e 10GB de armazenamento. Generoso para começar.

O plano Growth é $15/usuário/mês mais sobrecarga de uso. O plano Enterprise é precificado sob demanda.

O detalhe sobre preços da Sanity que pega pessoas: consultas GROQ e solicitações de CDN de API são medidas, e os custos escalam com sua complexidade de conteúdo. Uma única consulta GROQ que busca conteúdo profundamente aninhado e referenciado pode consumir mais da sua cota do que você esperaria. Sanity melhorou a transparência aqui, mas ainda recomendo que os times configurem alertas de orçamento cedo.

Custo típico de projeto de médio porte: $200-$800/mês dependendo do tamanho do time e tráfego.

Preços do Payload (2026)

Payload é licenciado com MIT. O CMS em si custa $0. Para sempre. Não há taxa por lugar, sem medição de chamadas de API, sem cobranças de largura de banda do Payload.

Seus custos são infraestrutura: hospedar uma app Node.js e uma base de dados. Em um serviço como Railway, Render ou uma configuração básica de AWS/DigitalOcean, você está olhando para $20-$100/mês para a maioria dos projetos. Até mesmo uma implantação de larga escala com Postgres gerenciado na AWS RDS, uma configuração EC2 ou ECS apropriadamente dimensionada e CloudFront na frente raramente excede $300-$500/mês — e isso é para tráfego sério.

Payload Cloud (sua oferta hospedada) começa em $50/mês com planos escalando baseado em armazenamento e largura de banda, mas é totalmente opcional.

Cenário Contentful Sanity Payload (self-hosted)
Desenvolvedor solo, site pequeno $0 (free tier) $0 (free tier) $20-40/mês (hosting)
Time de 5 pessoas, tráfego médio $300-500/mês $200-400/mês $50-100/mês (hosting)
Time de 10 pessoas, tráfego alto $2.000-4.000/mês $500-1.500/mês $150-400/mês (hosting)
Empresa, 50+ editores $5.000-10.000+/mês $2.000-5.000/mês $300-800/mês (hosting)

A história de preços é inequívoca. Payload vence em custo em cada nível.

Experiência do Desenvolvedor

Preços trazem as pessoas para a porta. Experiência do desenvolvedor as mantém lá — ou as afasta.

DX do Contentful

A experiência do desenvolvedor do Contentful é... adequada. Seu suporte a SDK é amplo (JavaScript, Python, Ruby, Java, Swift, etc.), documentação é madura e as APIs REST e GraphQL são bem documentadas.

Mas aqui está o que me frustra: tudo é configurado através da UI web. Tipos de conteúdo, campos, validações — é tudo clique-clique-clique no navegador. Sim, você pode usar o CLI do Contentful e scripts de migração para versionar sua schema, mas sente como algo encaixado. Não é code-first; é UI-first com uma escape hatch de código.

A ferramenta de migração melhorou com seu pacote contentful-migration, mas comparado a definir sua schema em TypeScript e obter type safety instantâneo? Sente como uma geração atrás.

DX da Sanity

A experiência do desenvolvedor da Sanity é genuinamente excelente em muitos aspectos. A schema é definida em arquivos JavaScript/TypeScript. O studio é uma app React que você pode customizar extensivamente — componentes de input customizados, views customizadas, plugins de workflow.

GROQ, sua linguagem de query, é poderosa uma vez que você a aprende. Mas "uma vez que você a aprende" está fazendo muito trabalho pesado naquela frase. GROQ não é SQL. Não é GraphQL. É sua própria coisa, e cada novo desenvolvedor no seu time precisa aprendê-la. Vi devs juniores lutando com projeções GROQ por semanas.

// Query GROQ - poderosa mas sintaxe única
*[_type == "post" && publishedAt < now()] | order(publishedAt desc) [0...10] {
  title,
  slug,
  "author": author->{ name, image },
  "categories": categories[]->{ title, slug },
  body[] {
    ...,
    _type == "image" => {
      "url": asset->url
    }
  }
}

Os recursos em tempo real da Sanity são incríveis porém. Múltiplos editores trabalhando no mesmo documento com indicadores de presença e nenhum conflito de save — simplesmente funciona. A arquitetura de content lake permite isso de formas que os competidores não conseguem igualar.

DX do Payload

Payload 3.0 mudou tudo. Construído sobre Next.js, escrito inteiramente em TypeScript, com seu arquivo de config como a única fonte de verdade. Você define collections, campos, hooks, controle de acesso e endpoints customizados tudo em código.

Aqui está o que uma típica collection do Payload parece:

import { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'publishedAt'],
  },
  access: {
    read: () => true,
    create: ({ req: { user } }) => Boolean(user),
    update: ({ req: { user } }) => Boolean(user),
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'status',
      type: 'select',
      options: ['draft', 'published'],
      defaultValue: 'draft',
    },
    {
      name: 'publishedAt',
      type: 'date',
      admin: {
        position: 'sidebar',
      },
    },
  ],
  hooks: {
    beforeChange: [
      ({ data, operation }) => {
        if (operation === 'create') {
          data.publishedAt = new Date()
        }
        return data
      },
    ],
  },
}

Tudo é tipado. Seu IDE autocompleta nomes de campos. Hooks dão controle de ciclo de vida. Controle de acesso é definido como funções bem próximas aos seus campos, não em uma UI de permissões separada. E porque é apenas uma app Next.js, você pode adicionar páginas customizadas, rotas de API ou server actions ao lado do seu código CMS.

Para times fazendo desenvolvimento Next.js, Payload 3.0 é uma escolha óbvia de uma perspectiva de DX. Seu CMS e seu frontend vivem no mesmo projeto. Mesma implantação. Mesmo repo.

Contentful vs Sanity vs Payload: Comparação de Headless CMS 2026 - arquitetura

Modelagem de Conteúdo

Modelagem de conteúdo é onde você se configura para sucesso ou cria um pesadelo que viverá por anos.

Abordagem do Contentful

Contentful usa um modelo tradicional de content type → entry. Você define tipos de conteúdo com campos e editores criam entries. Referências entre tipos de conteúdo são explícitas. Funciona bem para estruturas de conteúdo diretas.

As limitações aparecem com rich text. O campo rich text do Contentful armazena conteúdo como uma árvore JSON estruturada, o que é ótimo para flexibilidade de rendering, mas modelar layouts de página complexos com componentes aninhados requer uso criativo de embedded entries e referências. Pode ficar complicado.

Contentful suporta 50 tipos de conteúdo no plano Basic e 100+ no Premium. Para sites grandes com muitos tipos de conteúdo, isso pode se tornar uma limitação.

Abordagem da Sanity

A modelagem de conteúdo da Sanity é argumentavelmente a mais flexível das três. Seu conteúdo em blocos (Portable Text) é uma especificação aberta para rich text que armazena conteúdo como dados estruturados. Você pode definir tipos de blocos customizados, objetos inline e anotações.

O sistema de schema suporta tipos de objetos profundamente aninhados, campos condicionais e validação customizada. Construí alguns modelos de conteúdo genuinamente complexos na Sanity que seriam dolorosos no Contentful.

// Schema Sanity com customização Portable Text
export default {
  name: 'post',
  type: 'document',
  fields: [
    {
      name: 'body',
      type: 'array',
      of: [
        { type: 'block',
          marks: {
            annotations: [
              { name: 'internalLink', type: 'object',
                fields: [{ name: 'reference', type: 'reference', to: [{ type: 'post' }] }]
              }
            ]
          }
        },
        { type: 'image', options: { hotspot: true } },
        { type: 'codeBlock' },
        { type: 'callout' },
      ]
    }
  ]
}

Abordagem do Payload

A modelagem de conteúdo do Payload fica em algum lugar entre a simplicidade estruturada do Contentful e a flexibilidade freeform da Sanity — mas com a vantagem de ser inteiramente em TypeScript.

O campo blocks do Payload é particularmente poderoso para page building. Você define tipos de blocos, cada um com seus próprios campos, e editores podem compor páginas a partir desses blocos. Combinado com o tipo de campo layout e lógica condicional, você pode modelar quase qualquer coisa.

O editor rich text Lexical do Payload 3.0 é destaque. Substituiu Slate (que era bom mas envelhecendo) com um editor moderno que suporta nós customizados, blocos inline e rendering side-server pronto para usar. Você pode embutir componentes React diretamente em conteúdo rich text.

O sistema de versionamento merece menção também. Payload oferece workflows de draft/publish e histórico completo de versão de documento com diffing. Isso é built-in, não um add-on pago.

APIs: REST, GraphQL e Tudo no Meio

APIs do Contentful

Contentful oferece APIs separadas para delivery (cachado em CDN, somente leitura), preview (não-cacheado, conteúdo em draft), management (CRUD) e imagens. A separação é sensível mas significa que você está malabarando múltiplos tokens de API e base URLs.

Sua API GraphQL é sólida mas tem limitações de profundidade e rate limits que podem ser frustrantes ao modelar conteúdo profundamente referenciado. Queries complexas podem requer múltiplas viagens de ida e volta.

APIs da Sanity

A linguagem de query primária da Sanity é GROQ, servida por HTTP. Eles oferecem uma API GraphQL, mas é implantada separadamente e sente como um cidadão de segunda classe. GROQ é mais poderosa para a maioria dos casos de uso Sanity de qualquer forma.

A mágica real é a API de listener em tempo real da Sanity. Você pode se inscrever em mudanças em qualquer query e obter updates instantâneos. Isso habilita experiências de live preview que são genuinamente impressionantes.

APIs do Payload

Payload auto-gera tanto APIs REST quanto GraphQL a partir de suas configs de collection. Sem setup adicional. Defina uma collection, obtenha endpoints CRUD completos para REST e GraphQL instantaneamente.

# Query GraphQL auto-gerada
query {
  Posts(where: { status: { equals: published } }, sort: "-publishedAt", limit: 10) {
    docs {
      id
      title
      content
      author {
        name
      }
      publishedAt
    }
    totalDocs
    hasNextPage
  }
}

Mas aqui está onde Payload tem uma vantagem única: porque executa no mesmo processo que sua app Next.js, você pode pular a API inteiramente e usar a Local API do Payload para fetching de dados side-server. Queries diretas de banco de dados com o mesmo controle de acesso, hooks e validação — mas com zero overhead de HTTP.

// Local API - nenhum HTTP, nenhum overhead de serialização
const posts = await payload.find({
  collection: 'posts',
  where: { status: { equals: 'published' } },
  sort: '-publishedAt',
  limit: 10,
})

Essa é uma vitória massiva de performance para páginas server-rendered. Nenhuma roundtrip de rede para uma API CMS. Apenas uma chamada de função.

Experiência Editorial

Desenvolvedores escolhem o CMS, mas editores vivem nele diariamente. Ignore sua experiência por sua conta e risco.

Contentful tem a UI editorial mais madura. É limpa, previsível e seu time não-técnico a aprenderá rapidamente. O scheduling, workflows e approval chains no plano Premium são sólidos. Porém, pode se sentir rígido — customizar a interface editorial requer construir um Contentful App, que é uma app React inteira separada.

Sanity Studio é a mais customizável. Você pode construir experiências de edição inteiramente bespoke. Mas essa customização vem com custo: pronto para usar, Sanity Studio pode se sentir sobrecarregado para editores não-técnicos. O structure builder requer tempo de desenvolvedor para configurar bem.

Painel admin do Payload melhorou dramaticamente em 3.0. É limpo, rápido (é uma app Next.js) e suporta componentes customizados, rendering de campos condicionais e live preview. Não é tão polido quanto a UI do Contentful, mas é mais customizável com menos esforço que Contentful e mais acessível pronto para usar que Sanity.

Self-Hosting vs SaaS: Os Reais Trade-offs

Essa é a divisão filosófica. Contentful e Sanity são plataformas SaaS. Você não gerencia infraestrutura; paga a eles para fazer. Payload é self-hosted por padrão.

O argumento SaaS: menos overhead de ops, CDN built-in, uptime gerenciado. Esses são benefícios reais, especialmente para times pequenos sem experiência de DevOps.

O argumento self-hosted: propriedade de dados, nenhuma lock-in de vendor, custos previsíveis, conformidade regulatória (GDPR, HIPAA, residência de dados) e liberdade para customizar qualquer coisa.

Para agências como a nossa fazendo desenvolvimento de headless CMS, self-hosting se tornou a recomendação para a maioria dos clientes em 2026. A ferramenta de infraestrutura amadureceu até o ponto onde implantar uma app Payload em Railway, Vercel ou AWS é direto. Docker a torna reproduzível. E a economia de custo sobre um CMS SaaS se compõe ano após ano.

Se você estiver preocupado com o ônus de ops, Payload Cloud cuida da hospedagem para você enquanto mantém os benefícios open-source.

Performance e Escalabilidade

A API de delivery backed em CDN do Contentful é rápida. Tempos de resposta típicos são 50-100ms de nós de edge. Foi teste de batalha em escala por uma década.

A API CDN da Sanity oferece performance similar para conteúdo cacheado, com sua camada em tempo real adicionando talvez 20-30ms para queries ao vivo.

A performance do Payload depende de sua infraestrutura, mas aqui está a coisa — quando você usa a Local API com Next.js server components, você está fazendo uma chamada de função para um banco de dados local. Tempos de resposta podem ser under 10ms. Adicione um CDN na frente de sua saída Next.js (Vercel, CloudFront, etc.) e você está igualando ou batendo as opções SaaS.

Para projetos baseados em Astro, todos os três funcionam bem como fontes de API, mas as APIs REST e GraphQL do Payload são particularmente diretas para consumir na camada de data fetching do Astro.

Ecossistema e Comunidade

Contentful tem o maior ecossistema corporativo. Toneladas de integrações, um marketplace de apps e amplo suporte de agência.

Sanity tem uma comunidade de desenvolvedores apaixonada, documentação excelente e um ecossistema de plugins crescente. Seu Slack comunitário é genuinamente útil.

Payload tem a comunidade que cresce mais rápido dos três. Seu Discord é extremamente ativo, com o core team respondendo perguntas regularmente. O ecossistema de plugins é menor mas crescendo rapidamente — e porque Payload é apenas Node.js/TypeScript, você pode npm install qualquer coisa que precisar.

O GitHub do Payload tem mais de 30K stars no início de 2026 e a trajetória é íngreme.

O Veredicto

Serei direto: Payload é o melhor headless CMS para a maioria dos projetos em 2026.

Aqui está o porquê:

  1. Zero taxas de licença em qualquer escala. Seu time corporativo de 50 editores não paga um tostão ao Payload.
  2. Config TypeScript-nativa significa que seu modelo de conteúdo é código, version-controlado, type-safe e revisável em PRs.
  3. Integração Local API + Next.js oferece performance que CMSes SaaS fisicamente não conseguem igualar.
  4. Propriedade de dados — seu conteúdo vive em seu banco de dados, não em um store proprietário de outro.
  5. Sem lock-in de vendor — se quiser trocar, seu dado está em Postgres ou MongoDB. Apenas query-o.

Há cenários onde os outros vencem:

  • Escolha Contentful se você é uma grande empresa com um time de conteúdo estabelecido que precisa de uma experiência editorial polida e sem ops e tem o orçamento.
  • Escolha Sanity se colaboração em tempo real é crítica para seu workflow, você precisa do Portable Text sem paralelo ou está construindo uma experiência de studio altamente customizada.
  • Escolha Payload para tudo mais. Startups, agências, empresas de médio mercado, times liderados por desenvolvedores, indústrias reguladas precisando de controle de dados e qualquer um que não quer acordar com uma conta surpresa.

Se você está avaliando um headless CMS para um novo projeto e quer falar pelos específicos, ficaremos felizes em ajudar. Disponibilizamos projetos em produção Payload, Sanity e Contentful e podemos oferecer conselho honesto baseado em seus requisitos reais e orçamento.

FAQ

Payload CMS é realmente grátis?

Sim. Payload é software open-source licenciado com MIT. Não há taxas de licença, nenhuma cobrança por usuário e nenhum limite de chamadas de API do Payload em si. Seus únicos custos são infraestrutura de hospedagem (servidor e banco de dados), que normalmente custa $20-$500/mês dependendo da escala. Payload Cloud está disponível como uma opção hospedada paga se preferir não gerenciar infraestrutura.

Sanity pode ser self-hosted?

Parcialmente. Sanity Studio (a UI admin) é uma app React que você pode implantar em qualquer lugar. Porém, o content lake — onde seus dados reais vivem — é um serviço hospedado gerenciado pela Sanity. Você não pode self-host a camada de dados. Isso significa que seu conteúdo sempre vive na infraestrutura da Sanity, o que pode ser uma preocupação para residência de dados ou requisitos de conformidade.

Qual headless CMS tem o melhor suporte a GraphQL?

Contentful e Payload ambos oferecem APIs GraphQL fortes. Payload auto-gera seu schema GraphQL diretamente a partir de suas configs de collection, o que significa zero manutenção de schema manual. A API GraphQL do Contentful é madura e bem documentada. Sanity oferece GraphQL mas prefere GROQ como sua linguagem de query primária e sua implementação GraphQL não suporta todas as features GROQ.

Vale a pena o preço do Contentful em 2026?

Para grandes empresas com operações de conteúdo complexas, workflows Contentful existentes e times que valorizam uma abordagem SaaS sem complicações — sim, pode valer a pena. Para times pequenos-a-médios, o custo é cada vez mais difícil de justificar quando Payload oferece funcionalidade comparável (e em alguns aspectos superior) a uma fração do preço. Vimos múltiplos clientes migrarem para longe do Contentful especificamente por custo.

Como Payload CMS lida com otimização de imagem?

Payload tem redimensionamento de imagem built-in e cropping de focal point. Quando você faz upload de uma imagem, Payload pode gerar múltiplos tamanhos automaticamente baseado em sua config. Em Payload 3.0 com Next.js, você pode combinar isso com otimização de Imagem Next.js para serving responsivo, WebP/AVIF. Não é tão feature-rich quanto a API de imagem do Contentful (que oferece transformações baseadas em URL), mas cobre 90% de casos de uso sem um serviço de terceiros.

Posso migrar do Contentful para Payload?

Sim. Já que Payload usa bancos de dados padrão (Postgres ou MongoDB), migração envolve exportar seu conteúdo Contentful via sua Management API e importá-lo em collections Payload. A tradução de modelagem de conteúdo de content types Contentful para collections Payload é normalmente direta. Manejamos várias dessas migrações — a parte mais complicada é tipicamente conversão de rich text, não os dados estruturados.

Qual CMS é melhor para editores não-técnicos?

Contentful tem a experiência editorial mais intuitiva pronto para usar para usuários não-técnicos. O painel admin do Payload é um segundo muito próximo e melhorando rapidamente. Sanity Studio pode ser o melhor de todos os três se um desenvolvedor investe tempo customizando-o, mas a experiência padrão tem uma curva de aprendizado mais íngreme para editores.

Payload CMS funciona com frameworks além de Next.js?

Absolutamente. Enquanto Payload 3.0 usa Next.js como seu framework de UI admin, as APIs REST e GraphQL funcionam com qualquer frontend — Astro, Nuxt, SvelteKit, Remix ou até apps mobile. A Local API é específica de Next.js, mas as APIs externas não têm dependências de framework. Regularmente emparelhamos Payload tanto com Next.js quanto com Astro dependendo dos requisitos do projeto.