Se você reduziu sua escolha de headless CMS a Sanity versus o pessoal do Payload-or-Storyblok, já eliminou 80% do ruído que o resto dessa categoria emite. A decisão que fica é a interessante: você está otimizando para a experiência do time editorial, ou para o ownership do time de engenharia? Se acertar essa pergunta, o resto da escolha é praticamente forçado.
Sanity é a resposta quando o time editorial é o protagonista. Depois de rodar mais de 12 mil builds de clientes na Seahawk Media e fazer deploy de alguns diretamente em Sanity nos últimos 18 meses, aqui está a análise honesta de onde vence, onde Payload a come, e onde Storyblok faz. Preço, capacidade, caminho de migração, e os trade-offs que ninguém nas páginas de vendas dos fornecedores vai te contar.
O que Sanity realmente é em 2026
Sanity é uma headless CMS hospedada onde você escreve o schema em TypeScript ou JavaScript, executa um aplicativo admin customizável baseado em React chamado Sanity Studio (tipicamente deployado em seu próprio domínio), e consulta o conteúdo via GROQ — uma linguagem de query estilo graph que se assemelha a GraphQL mas é mais expressiva em relacionamentos de documentos. O conteúdo é em tempo real entre editores nativamente: dois editores no mesmo documento veem as posições do cursor um do outro ao vivo, como Figma.
A plataforma é madura: Sanity v3 tem sido a versão major estável nos últimos dois anos, o Studio é genuinamente customizável até componentes de input único, e a Live Content API faz stream das mudanças de documento para seu front end sem polling. Sanity é uma das poucas escolhas de headless CMS em 2026 que não parece um produto em estágio inicial numa terça de tarde.
Preços da Sanity em 2026 — a verdadeira curva de custos
Três planos. O nível gratuito parece generoso até você bater nos limites rígidos; o plano Growth começa em $15 por assento por mês; Enterprise é customizado e começa onde o plano Growth para de escalar.
Plano gratuito
- $0/mês, 20 assentos inclusos sem sobrecarga permitida.
- Limitado aos papéis de Administrador e Visualizador — sem papéis de Editor, Developer ou Contributor.
- Limites rígidos em documentos, assets, requisições de API, largura de banda CDN. Se você atingir uma cota, a funcionalidade afetada fica bloqueada até a cota ser resetada ou você fazer upgrade.
- Realista para: protótipos, ferramentas internas ou sites de conteúdo com menos de 5.000 documentos com uma pequena equipe editorial.
Plano Growth
- $15 por assento por mês, até 50 assentos.
- Todos os cinco papéis desbloqueados: Admin, Viewer, Editor, Developer, Contributor.
- 250 mil requisições de API por mês incluídas, 1 milhão de requisições de API CDN, com pagamento conforme o uso acima disso.
- Limite rígido de 25 mil documentos — sem pagamento conforme o uso acima disso no Growth, você precisa migrar para Enterprise.
- Rascunhos agendados, recursos de colaboração, autenticação única se você adicionar o complemento SSO (mais sobre isso abaixo).
- Realista para: maioria dos sites de conteúdo em produção com 1 a 10 editores e menos de 25 mil documentos.
Plano Enterprise
- Preços customizados, gerenciados por vendas.
- Limites de documentos maiores, retenção customizada, segurança avançada, suporte dedicado, desempenho com SLA garantida.
- Realista para: sites com mais de 50 mil documentos, indústrias reguladas, empresas com requisitos de procurement.
O complemento SSO que torna o Growth mais caro do que parece
SAML SSO no plano Growth é um complemento de $1.399 por mês. Para um time de 5 usuários pagando $75 por mês, adicionar SSO multiplica o custo por 19. Se sua política de segurança exigir SSO desde o início, o plano Growth é uma falsa economia e você está efetivamente em preços Enterprise sem o conjunto de recursos do Enterprise. Vale a pena saber antes de se comprometer.
Onde a Sanity vence (e que tipo de briefing a escolhe)
Editorial em tempo real em equipes distribuídas
O modelo de colaboração da Sanity é o mais próximo de trabalhar em um Google Doc no universo dos CMS headless. Dois editores no mesmo documento veem os cursores um do outro. Comentários ficam vinculados a campos individuais. A presença no documento fica visível na navegação. Para equipes de marca, equipes de marketing de conteúdo e qualquer um onde duas ou mais pessoas tocam regularmente no mesmo documento na mesma hora, essa é genuinamente uma feature que define a categoria.
Customização de schema que não parece um template de CMS
O Studio é uma aplicação React que você faz deploy. Componentes de input customizados, previews customizados, botões de workflow customizados, validação customizada, asset pipelines customizados — tudo vive no seu repo. Se sua equipe editorial tem necessidades específicas (um date-and-timezone picker customizado que rejeita feriados bancários, um campo slug que valida contra uma lista de concorrentes, uma UI de crop de imagem customizada), Sanity Studio é o único CMS headless onde você consegue construir isso sem brigar com a plataforma.
GROQ como linguagem de query
GROQ é mais expressivo que GraphQL para queries de document-graph. Você consegue fazer join entre referências, projetar campos aninhados, filtrar em valores computados e fatiar listas em uma única query. O trade-off é que GROQ é específico da Sanity — você não consegue levar suas queries para outro lugar. Para equipes que entregam content surfaces complexos (diretórios com facetas, widgets de conteúdo relacionado, cadeias de fallback multi-locale), GROQ é mais rápido de escrever e mais rápido de iterar do que a query GraphQL equivalente mais lógica no front-end.
Visual Editing em front ends Next.js
O Visual Editing da Sanity, geralmente disponível desde 2025, permite que editores cliquem diretamente em uma página Next.js ou Nuxt em modo preview e editem o campo subjacente no Studio. É a história de visual editing mais limpa no espaço de CMS headless fora da Storyblok. Se seu workflow editorial é predominantemente preview-first, isso é um ganho real de produtividade.
Onde a Payload come a Sanity
Payload é a escolha certa quando o time de engenharia é o protagonista da construção, e o time de editor pode ser integrado a uma experiência de admin um pouco mais orientada para desenvolvedores.
Schemas TypeScript-first como fonte canônica
Os schemas do Payload vivem nos seus arquivos TypeScript ao lado do código da sua aplicação. A segurança de tipos é end-to-end: o schema, o cliente da API e sua app Next.js compartilham os mesmos tipos sem etapas de geração de código. O schema do Sanity também é definido em código, mas o fluxo de geração de tipos é mais complexo e a história do TypeScript é menos nativa.
Self-hosted, seu banco de dados Postgres, seu bucket S3
Payload é a melhor resposta quando a propriedade dos dados não é negociável. O CMS roda na sua infraestrutura, o banco de dados é sua instância Postgres ou MongoDB, os assets ficam no seu bucket S3 (ou compatível). Sanity armazena documentos na infraestrutura hospedada do Sanity — tudo bem para a maioria dos times, um impedimento para indústrias reguladas ou qualquer time com uma política de 'nenhum data store de terceiros'.
Local API sem overhead HTTP
A Local API do Payload permite chamar funções do CMS diretamente do seu código Next.js sem uma requisição HTTP. Para apps fortemente integrados onde o CMS é apenas uma de várias fontes de dados, isso tem desempenho mensurável melhor do que o padrão de acesso apenas por rede do Sanity.
Cobri a decisão Payload-versus-Strapi em profundidade aqui: Payload vs Strapi in 2026. A versão curta tem a mesma forma: Payload para times pesados em TypeScript que querem propriedade, Strapi para times que querem um ecossistema de plugins mais rico.Payload vs Strapi in 2026. The short version is the same shape: Payload for TypeScript-heavy teams that want ownership, Strapi for teams that want a richer plugin ecosystem.
Onde Storyblok vence Sanity (um caso específico)
Storyblok vence Sanity em uma dimensão específica e apenas uma: o editor visual para times de marketing que querem fazer layout de páginas componente-por-componente sem tocar em código. O Visual Editor do Storyblok permite que um gerente de marketing não-técnico construa um hero, hero-with-cta, layout de grid de três colunas a partir de blocos de componentes pré-definidos e veja a prévia ao vivo conforme avança. O Visual Editing do Sanity é bom mas não é desenhado em torno da mesma persona.
Se seu time editorial é dominado por usuários não-técnicos focados em marketing que querem montar páginas, Storyblok é a escolha certa. Se seu time editorial é focado em conteúdo (redatores, editores, jornalistas, gestores de conhecimento), o editor document-first do Sanity oferece uma experiência melhor.
Migrando para Sanity: o caminho realista
De WordPress
Padrão comum: exporte conteúdo do WordPress via WP All Export, transforme para o formato NDJSON do Sanity, importe via CLI do Sanity. O mapeamento de schema é o trabalho — páginas, posts, tipos de post customizados, campos ACF todos precisam de um equivalente no Sanity. O playbook de migração WordPress para Next.js cobre o lado de transporte SEO que se aplica independentemente do CMS de destino. Tempo em um site de 5.000 páginas: 4 a 8 semanas de trabalho focado apenas na migração, mais tempo se o schema incluir conteúdo relacional complexo.The WordPress to Next.js migration playbook covers the SEO transport side that applies regardless of CMS target. Time on a 5,000-page site: 4 to 8 weeks of focused work for the migration alone, longer if the schema includes complex relational content.
De Contentful
Mais fácil que WordPress porque o modelo de conteúdo do Contentful mapeia de forma clara para a estrutura document-and-reference do Sanity. A ferramenta de migração do Sanity tem importadores dedicados para exportações do Contentful. Timeline realista em um site de tamanho similar: 2 a 4 semanas.
De Drupal
A mais difícil das três porque o modelo entity-and-bundle do Drupal é estruturalmente diferente. A maioria dos times acaba reconstruindo o schema do zero no Sanity em vez de fazer auto-migração. 6 a 12 semanas para um site Drupal complexo com múltiplos idiomas.
FAQ
O Sanity é compatível com HIPAA?
Sanity não publica um Business Associate Agreement HIPAA em seu plano Growth, então por padrão Sanity não é elegível para HIPAA para armazenar PHI. Clientes Enterprise com fluxos de trabalho de saúde podem negociar um acordo customizado de manipulação de dados, mas não é o padrão. Se seu app de saúde precisa de um CMS que armazene PHI diretamente, Supabase com o complemento HIPAA ou um deployment auto-hospedado do Payload em um host elegível para HIPAA é um caminho mais defensável.
Sanity é melhor que Contentful?
Para a maioria dos times em 2026, sim — Sanity oferece mais flexibilidade de schema, melhor colaboração em tempo real, uma linguagem de query mais capaz (GROQ), e um preço significativamente menor para conjuntos de features equivalentes. A força do Contentful é a procura enterprise e integrações com stacks de marketing legados. Se seu time é técnico e o fluxo de trabalho editorial é a prioridade, Sanity é a melhor escolha. Se seus stakeholders exigem um contrato enterprise amigável à procura, Contentful é a escolha mais segura.
Quanto custa Sanity para um time de 5 pessoas?
No plano Growth, $75 por mês para 5 seats a $15 por seat. Se você precisar de SAML SSO, adicione $1.399 por mês — tornando o mesmo time $1.474 mensais. O plano gratuito cobre 20 seats com limites rígidos, então se seu time é pequeno e seu uso é baixo, a camada gratuita pode sustentá-lo no primeiro ano.
Posso usar Sanity com Next.js?
Sim — Next.js é o front end mais comum para Sanity em 2026. O pacote oficial @sanity/client manipula as chamadas de API, queries GROQ rodam server-side em Server Components ou via rotas de API, e Visual Editing é suportado em modo preview. Sanity tem um template starter Next.js mantido; cloná-lo é a forma mais rápida para um projeto funcionando.
O que é GROQ e por que importa?
GROQ é a linguagem de query de conteúdo do Sanity — uma linguagem de query baseada em grafo, orientada a projeção, desenhada para o tipo de joins e filters que conteúdo de headless CMS precisa. É mais expressiva que GraphQL para queries de document-graph. A desvantagem é que GROQ é específico do Sanity, então uma migração futura para fora do Sanity significa reescrever toda query. Para a maioria dos times o ganho de produtividade no curto prazo supera o risco de lock-in.
Leitura relacionada
Alternativas ao WordPress em 2026: quando no-code não é a resposta — o post pai sobre alternativas de stack, incluindo a seção sobre escolhas de CMS headless. — the parent post on stack alternatives, including the section on headless CMS choices.
Migração de WordPress para Next.js sem perder rankings — vale se seu CMS de destino é Sanity, Payload ou qualquer outro. O transporte SEO é o mesmo independentemente do CMS. — applies whether your CMS target is Sanity, Payload, or anything else. The SEO transport is the same regardless of CMS.
Prós e contras da arquitetura headless — trade-offs honestos do modelo headless em si, útil como prelúdio do framework de decisão. — honest tradeoffs of the headless model itself, useful as the decision framework prequel.
WordPress Stack Advisor — cole sua URL, receba uma recomendação personalizada que inclui se Sanity é o CMS certo para seu brief específico. — paste your URL, get a tailored recommendation that includes whether Sanity is the right CMS for your specific brief.
A escolha do CMS raramente é o gargalo. O gargalo é o primeiro mês da equipe de edição na nova ferramenta. Escolha Sanity se sua equipe de edição está animada; escolha Payload se sua equipe de engenharia está.
Agende uma call de 30 minutos para escolher o CMS — descreva o brief, a equipe, o timeline, as integrações, e saia com uma decisão Sanity-vs-Payload-vs-Storyblok que seja honesta sobre os trade-offs. — describe the brief, the team, the timeline, the integrations, and walk away with a Sanity-vs-Payload-vs-Storyblok decision that is honest about the trade-offs.