Directus vs Payload vs Supabase: Qual Backend se Encaixa na Sua Stack em 2026
Seu deploy termina, o site fica online, e três semanas depois seu time de conteúdo te contacta: os uploads de imagem estão com timeout, categorias aninhadas não salvam, e a resposta da API ultrapassa 800ms. Reconstruí esse cenário com Directus, Payload e Supabase em projetos em produção nos últimos dois anos — mesmos sintomas, causas raiz diferentes toda vez. A resposta depende de coisas que as landing pages pulam: como seus editores estruturam workflows, como seu grafo relacional realmente se parece, e se você ainda está usando essa stack quando o Series A fecha. Aqui está o framework que determina qual backend sobrevive aos seus próximos seis sprints.
Isso não é uma comparação de checklist de features. É o framework de decisão que eu realmente uso ao escopar projetos na Social Animal, refinado através de dezenas de builds headless. No final, você saberá qual ferramenta se encaixa em sua situação específica sem se questionar.
Índice
- A Identidade Central de Cada Ferramenta
- Arquitetura e Modelagem de Dados Comparadas
- Experiência de Edição de Conteúdo
- Experiência do Desenvolvedor e Design da API
- Autenticação, Permissões e Row-Level Security
- Self-Hosting, Cloud e Preços em 2026
- Benchmarks de Performance e Escalabilidade
- O Framework de Decisão: Quando Usar Qual
- Cenários Reais de Projeto
- Caminhos de Migração e Considerações de Lock-In
- FAQ

A Identidade Central de Cada Ferramenta
Antes de entrar em detalhes, você precisa entender o que cada ferramenta realmente é em seu núcleo, porque a sobreposição em conjuntos de features pode ser enganosa.
Directus é um CMS headless orientado por banco de dados. Envolve um banco de dados SQL existente (Postgres, MySQL, SQLite, MS SQL, MariaDB, CockroachDB) com uma API auto-gerada e um painel admin polido. Você projeta seu banco de dados, Directus o inspeciona e oferece uma UI. É escrito em TypeScript e executa em Node.js.
Payload é um CMS headless orientado por código construído em Next.js (a partir do Payload 3.0). Você define collections e fields em arquivos de configuração TypeScript, e Payload gera o schema do banco de dados, UI admin, endpoints de API e tipos TypeScript dessa configuração. Usa MongoDB ou Postgres como camada de banco de dados.
Supabase é uma alternativa open-source ao Firebase -- um backend-as-a-service construído em cima do Postgres. Não é realmente um CMS. É uma plataforma de banco de dados com auth, storage, assinaturas em tempo real e edge functions. Mas times a usam como backend de CMS constantemente, é por isso que continua aparecendo nessas comparações.
Essa distinção importa mais do que qualquer outra coisa neste artigo. Directus e Payload são sistemas de gerenciamento de conteúdo propósito-construído. Supabase é um backend de propósito geral que você pode moldar em um sistema de gerenciamento de conteúdo com esforço suficiente.
Arquitetura e Modelagem de Dados Comparadas
Directus: Orientado por Banco de Dados
Directus não possui seu schema. Você pode apontá-lo para um banco de dados existente e ele gerará um painel admin automaticamente. Isso é genuinamente poderoso quando você está trabalhando com sistemas legados ou quando seu modelo de dados serve múltiplas aplicações além do gerenciamento de conteúdo.
A modelagem de relacionamento no Directus é sólida. M2M, M2O, O2M, e até traduções são tratadas através da UI. Mas há uma pegadinha: porque Directus inspeciona o banco de dados em vez de gerá-lo a partir de código, suas mudanças de schema acontecem em dois lugares -- migrations e o admin do Directus. Isso pode ficar bagunçado em ambientes de time se você não for disciplinado.
# Snapshot de schema do Directus (simplificado)
collections:
- collection: articles
fields:
- field: title
type: string
interface: input
- field: content
type: text
interface: input-rich-text-md
- field: author
type: uuid
interface: select-dropdown-m2o
related_collection: authors
Payload: Orientado por Código
Payload 3.0 (a versão atual em 2026) executa dentro do Next.js como um plugin. Suas collections são definidas em TypeScript:
import { CollectionConfig } from 'payload'
export const Articles: CollectionConfig = {
slug: 'articles',
admin: {
useAsTitle: 'title',
},
fields: [
{
name: 'title',
type: 'text',
required: true,
},
{
name: 'content',
type: 'richText',
},
{
name: 'author',
type: 'relationship',
relationTo: 'authors',
},
],
}
Essa abordagem orientada por código significa que seu schema vive em controle de versão. Você obtém tipos TypeScript completos auto-gerados de sua configuração. É a melhor DX dos três para times pesados em TypeScript. A desvantagem? Não-desenvolvedores não podem modificar o modelo de dados sem uma mudança de código.
Supabase: Orientado por SQL
Com Supabase, você está escrevendo SQL. Postgres puro. Você define suas tabelas, configura políticas de row-level security, e depois interage através da API REST auto-gerada (PostgREST) ou do cliente JavaScript.
CREATE TABLE articles (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
title TEXT NOT NULL,
content JSONB,
author_id UUID REFERENCES authors(id),
created_at TIMESTAMPTZ DEFAULT now(),
published BOOLEAN DEFAULT false
);
-- Row Level Security
ALTER TABLE articles ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Public can read published articles"
ON articles FOR SELECT
USING (published = true);
Você obtém flexibilidade máxima mas zero UI de gerenciamento de conteúdo pronta para usar. Você construirá um admin customizado, usará uma ferramenta de terceiros, ou ligará algo como Directus em cima da mesma instância Postgres (sim, pessoas realmente fazem isso).
Experiência de Edição de Conteúdo
Aqui é onde a distinção CMS-vs-não-é-um-CMS bate mais forte.
| Feature | Directus | Payload | Supabase |
|---|---|---|---|
| UI Admin Integrada | ✅ Polida, customizável | ✅ Nativa em Next.js, muito boa | ❌ Apenas editor de tabela |
| Editor de Rich Text | ✅ WYSIWYG + Markdown | ✅ Baseado em Lexical (excelente) | ❌ Nenhum |
| Media Library | ✅ Completa | ✅ Completa | ⚠️ Buckets de storage (sem UI de biblioteca) |
| Content Preview | ✅ Via módulos customizados | ✅ Live preview nativa | ❌ Construa seu próprio |
| Localização | ✅ Sistema de tradução integrado | ✅ Localização no nível de field | ❌ Implementação manual |
| Versionamento de Conteúdo | ✅ Revisões integradas | ✅ Drafts + versions | ❌ Construa seu próprio |
| Workflow / Publicação | ✅ Sistema Flows | ✅ Estados Draft/publish | ❌ Lógica customizada necessária |
| Amigável para não-desenvolvedores | ✅ Muito | ✅ Sim | ❌ De jeito nenhum |
Se seu projeto envolve editores de conteúdo -- pessoas que escrevem posts de blog, gerenciam catálogos de produtos, atualizam landing pages -- Supabase é a ferramenta errada. Ponto final. Você gastaria semanas construindo o que Directus e Payload dão no dia um.
A experiência de editor do Payload melhorou notavelmente desde 3.0. O editor de rich text baseado em Lexical é flexível, o recurso de live preview funciona lindamente com frontends Next.js, e o painel admin se sente nativo porque literalmente executa dentro de seu app Next.js.
Directus tem o painel admin mais maduro dos três. Foi refinado ao longo dos anos, e o sistema customizado de display/interface significa que você pode construir workflows editoriais complexos sem tocar código frontend. Para organizações pesadas em conteúdo, isso importa muito.

Experiência do Desenvolvedor e Design da API
Estilos de API
Directus oferece REST e GraphQL pronto para uso, além de um SDK JavaScript. A API REST segue um padrão consistente, e a implementação GraphQL é auto-gerada de seu schema. Funciona, mas o GraphQL pode parecer limitado para queries aninhadas complexas.
Payload gera APIs REST e GraphQL, além disso você obtém acesso completo à Local API (queries de banco de dados diretas sem overhead HTTP). Como Payload 3.0 executa dentro de seu app Next.js, você pode chamar payload.find() diretamente em seus Server Components. Essa é uma vantagem massiva para projetos Next.js.
// Payload Local API em um Server Component Next.js
import { getPayload } from 'payload'
import config from '@payload-config'
export default async function ArticlePage({ params }) {
const payload = await getPayload({ config })
const article = await payload.findByID({
collection: 'articles',
id: params.id,
depth: 2,
})
return <Article data={article} />
}
A API do Supabase é auto-gerada por PostgREST, e a biblioteca cliente JavaScript é genuinamente excelente. O query builder se sente natural:
const { data, error } = await supabase
.from('articles')
.select('*, author:authors(*)')
.eq('published', true)
.order('created_at', { ascending: false })
.range(0, 9)
Supabase também tem assinaturas em tempo real, que nem Directus nem Payload oferecem nativamente. Se você precisa de atualizações de dados ao vivo (chat, notificações, edição colaborativa), Supabase vence por padrão.
Type Safety
Payload tem a melhor história TypeScript. Tipos são gerados a partir de suas configurações de collection, e tudo é fortemente tipado de ponta a ponta. Supabase tem geração de tipos sólida através de sua CLI (supabase gen types typescript), que cria tipos a partir de seu schema de banco de dados. Directus tem um SDK TypeScript mas a geração de tipos requer setup adicional e não é tão integrada.
Autenticação, Permissões e Row-Level Security
Aqui é onde Supabase genuinamente brilha. Postgres Row-Level Security (RLS) é o modelo de permissões mais granular, mais testado em batalha dos três. Você define políticas no nível do banco de dados, e elas se aplicam independentemente de como os dados são acessados. É incrivelmente poderoso para aplicações SaaS multi-tenant.
Directus tem um sistema de permissões baseado em roles que funciona no nível de collection e field. É intuitivo no painel admin e suficiente para a maioria dos casos de uso de CMS. Você pode definir permissões CRUD por role e até adicionar regras de filtro customizadas.
Payload oferece controle de acesso no nível de field e collection através de funções em sua configuração:
{
slug: 'articles',
access: {
read: () => true,
create: ({ req: { user } }) => user?.role === 'editor',
update: ({ req: { user } }) => user?.role === 'editor',
delete: ({ req: { user } }) => user?.role === 'admin',
},
fields: [
{
name: 'internalNotes',
type: 'textarea',
access: {
read: ({ req: { user } }) => user?.role === 'admin',
},
},
],
}
Para um CMS padrão com editores, revisores e admins, todos os três funcionam bem. Para aplicações multi-tenant complexas com regras de permissão dinâmicas, o RLS do Supabase é a opção mais poderosa.
Self-Hosting, Cloud e Preços em 2026
Todos os três são open source e auto-hospedáveis. Mas o preço da cloud diz muito sobre seus mercados-alvo.
| Plano | Directus Cloud | Payload Cloud | Supabase Cloud |
|---|---|---|---|
| Free tier | ❌ Sem cloud gratuita | ✅ 1 projeto, limitado | ✅ 2 projetos, 500MB DB |
| Starter/Pro | $99/mês (Professional) | $35/mês (Standard) | $25/mês (Pro) |
| Team/Business | $399/mês (Enterprise) | Preços customizados | $599/mês (Team) |
| Custo self-hosted | Gratuito (open source) | Gratuito (open source) | Gratuito (open source) |
| Banco de dados incluído | ✅ Gerenciado | ✅ Postgres gerenciado | ✅ Postgres gerenciado |
| CDN/Storage | Incluído | Incluído | Incluído com limites |
Preços conforme Q1 2026. Verifique a página de preços de cada plataforma para taxas atuais.
Payload Cloud é a opção gerenciada mais acessível para projetos pequenos a médios. O free tier do Supabase é o mais generoso para prototipagem e projetos secundários. Directus Cloud tem como alvo organizações maiores dispostas a pagar por uma experiência gerenciada polida.
O self-hosting muda a equação dramaticamente. Todos os três executam bem em uma VPS de $5-20/mês. Directus e Supabase têm setups Docker Compose oficiais que funcionam confiávelmente. Payload se integra em qualquer lugar que Next.js execute -- Vercel, Railway, Fly.io, seu próprio servidor.
Para nossos projetos de desenvolvimento de CMS headless, tipicamente recomendamos self-hosting em Railway ou Fly.io para eficiência de custo, apenas com cloud gerenciada quando o cliente precisa de SLAs garantidos.
Benchmarks de Performance e Escalabilidade
Executei alguns benchmarks informais em hardware equivalente (4 vCPU, 8GB RAM, Postgres 16) com um dataset de ~50.000 registros de conteúdo.
| Operação | Directus | Payload | Supabase |
|---|---|---|---|
| Query de lista simples (20 itens) | ~45ms | ~12ms (Local API) / ~38ms (REST) | ~18ms |
| Query de relacionamento aninhada (profundidade 3) | ~120ms | ~35ms (Local API) / ~95ms (REST) | ~55ms |
| Busca full-text (1000 resultados) | ~180ms | ~85ms | ~40ms (pg_trgm) |
| Inserção em massa (1000 registros) | ~2.1s | ~1.8s | ~0.9s |
| Tempo de cold start | ~3.5s | ~2.8s | N/A (sempre executando) |
A Local API do Payload é a opção mais rápida para aplicações Next.js porque não há overhead HTTP -- você está consultando o banco de dados diretamente do seu processo de renderização. A performance bruta do Postgres do Supabase é difícil de vencer para operações pesadas em dados. Directus adiciona um certo overhead através de sua camada de abstração, mas é perfeitamente adequado para workloads de entrega de conteúdo.
Para busca especificamente, Supabase tem uma vantagem significativa porque você pode usar busca full-text nativa do Postgres, índices trigram e até a extensão pgvector para busca semântica. Directus e Payload suportam busca mas contam com suas próprias implementações em vez de alavancar Postgres diretamente.
O Framework de Decisão: Quando Usar Qual
Aqui está o framework real. Responda essas perguntas, e sua escolha se torna óbvia.
Escolha Directus Quando:
- Seu time de conteúdo é grande e não-técnico
- Você precisa envolver um banco de dados existente com uma camada de CMS
- Você está usando um banco de dados diferente de Postgres (MySQL, MS SQL, etc.)
- Você precisa de um CMS independente que serve múltiplos frontends (web, mobile, kiosk)
- Seu frontend não é Next.js (talvez você esteja usando Astro, Nuxt ou SvelteKit)
- Você quer flexibilidade máxima em customização de UI admin sem código
Directus se emparelha lindamente com Astro para sites com muito conteúdo onde renderização em tempo de build e arquitetura de ilhas fazem mais sentido que um framework React completo.
Escolha Payload Quando:
- Seu frontend é Next.js (esse é o caso de uso decisivo)
- Seu time é TypeScript-first e quer type safety em todos os lugares
- Você quer CMS e frontend em uma única unidade implementável
- Você precisa de capacidades de live preview e edição visual
- Você quer schemas definidos por código em controle de versão
- Você está construindo um site onde o modelo de conteúdo é bem definido antecipadamente
Payload é nossa recomendação padrão para projetos de desenvolvimento Next.js onde gerenciamento de conteúdo é um requisito central. A integração é incomparável.
Escolha Supabase Quando:
- Você está construindo uma aplicação, não um website de conteúdo
- Você precisa de recursos em tempo real (chat, atualizações ao vivo, edição colaborativa)
- Você precisa de permissões multi-tenant complexas (RLS é rei)
- Sua necessidade principal é um backend, e conteúdo é secundário
- Você quer usar extensões Postgres (pgvector, PostGIS, pg_cron)
- Seu time é confortável em construir suas próprias interfaces admin
- Você está construindo um produto SaaS onde dados gerados pelo usuário importam mais que conteúdo editorial
Cenários Reais de Projeto
Cenário 1: Website de Marketing com Blog
Melhor escolha: Payload (se Next.js) ou Directus (se Astro/outro)
Um site de marketing com 50-200 páginas, um blog, e um pequeno time de conteúdo de 2-3 pessoas. Você precisa flexibilidade de landing page, otimização de imagem, gerenciamento de metadados SEO, e talvez algum teste A/B.
O recurso de live preview do Payload é perfeito aqui. Editores de conteúdo podem ver exatamente como a página ficará antes de publicar. O tipo de field baseado em blocos deixa você construir landing pages flexíveis sem dar aos editores corda suficiente para se enforcar.
Cenário 2: Catálogo de Produtos E-commerce
Melhor escolha: Directus ou Payload
Um catálogo de produtos com 5.000+ SKUs, categorização complexa, múltiplas listas de preços e integração com sistemas de inventário. A chave aqui é flexibilidade de modelagem de dados e a habilidade de lidar com dados estruturados eficientemente.
Directus se adianta se você precisa conectar a um banco de dados de produtos existente sem migrar dados. Payload vence se você está construindo do zero e quer queries de produtos type-safe em sua vitrine Next.js.
Cenário 3: Plataforma SaaS Multi-Tenant
Melhor escolha: Supabase
Uma plataforma onde cada cliente tem seu espaço de dados, com acesso baseado em roles, notificações em tempo real e conteúdo gerado pelo usuário. Você precisa de row-level security, edge functions para lógica de negócio e a habilidade de escalar horizontalmente.
Isso não é um projeto de CMS -- é um projeto de backend de aplicação. Supabase foi construída exatamente para isso.
Cenário 4: Knowledge Base Interno
Melhor escolha: Payload ou Directus
Um wiki/knowledge base interno para uma empresa de 200 pessoas. Conteúdo rich text, categorização, busca e acesso baseado em roles. Editores de conteúdo variam de técnicos a não-técnicos.
Ambos os CMS funcionam bem aqui. Directus tem uma vantagem leve para times não-técnicos porque o painel admin requer zero código para customizar. Payload é melhor se você quer uma experiência frontend polida e com marca própria.
Caminhos de Migração e Considerações de Lock-In
Lock-in é real. Pense nisso antes de se comprometer.
Directus tem o menor lock-in porque seu schema de banco de dados é independente do CMS. Remova Directus, e você ainda tem um banco de dados SQL limpo e padrão. Seus dados não estão presos em um formato proprietário.
Payload armazena dados em tabelas Postgres padrão (ou MongoDB), mas o schema segue as convenções do Payload. Migrar para fora significa reestruturar algumas coisas, mas seus dados ainda estão em um banco de dados padrão.
Supabase é apenas Postgres. Zero lock-in. Você pode pegar o dump de seu banco de dados e executá-lo em qualquer instância Postgres. Se Supabase desaparecesse amanhã, você precisaria substituir algumas chamadas de API mas seus dados e schema estariam perfeitamente intactos.
Todos os três pontua bem em lock-in comparados a plataformas de CMS proprietárias como Contentful ou Sanity, onde seus dados vivem na nuvem de alguém e exportá-los é sempre um processo parcial.
FAQ
Posso usar Supabase como um headless CMS?
Tecnicamente sim, mas você estará construindo features de CMS do zero -- UI de edição de conteúdo, gerenciamento de mídia, histórico de revisão, workflows de publicação. Para pequenos projetos com gerenciamento de conteúdo apenas por desenvolvedores, pode funcionar. Para qualquer coisa envolvendo editores não-técnicos, use um CMS real como Payload ou Directus e conecte Supabase para dados de aplicação se necessário.
Payload é realmente grátis? Qual é a pegadinha?
Payload CMS é genuinamente open source sob licença MIT. Você pode auto-hospedar gratuitamente para sempre. Payload Cloud é seu serviço de hospedagem gerenciada pago, começando em $35/mês. A pegadinha, se quiser chamar assim, é que Payload Cloud tem algumas features premium como form builder e plugins de SEO que são grátis mas se beneficiam do ambiente hospedado. O CMS central é totalmente funcional sem pagar nada.
Posso usar Directus e Supabase juntos?
Absolutamente, e esse é um padrão que usei múltiplas vezes. Aponte Directus para um banco de dados Postgres do Supabase. Você obtém o painel admin do Directus para gerenciamento de conteúdo e as assinaturas em tempo real do Supabase, auth e edge functions para features de aplicação. As duas ferramentas se complementam bem porque operam em camadas diferentes.
Qual é melhor para um projeto Next.js?
Payload, e não está nem perto. Desde Payload 3.0, o CMS executa dentro de sua aplicação Next.js como um plugin. Você obtém a Local API para queries de banco de dados sem overhead em Server Components, live preview nativa e uma deployment única. Usamos essa combinação constantemente em nosso trabalho de desenvolvimento Next.js.
Como esses se comparam com Strapi em 2026?
Strapi v5 é uma opção sólida mas ficou atrás em alguns aspectos. Seu painel admin parece desatualizado comparado ao do Payload, seu suporte TypeScript não é tão forte e seu modelo de licenciamento ficou mais restritivo. Directus oferece uma abordagem similar de envolvimento de banco de dados com uma UI mais moderna. Payload oferece melhor DX para times TypeScript. A principal vantagem do Strapi é seu ecossistema de plugins maior e comunidade maior, mas a lacuna está diminuindo.
E quanto a Sanity, Contentful ou outras plataformas de CMS SaaS?
Sanity e Contentful são ótimos produtos mas são plataformas SaaS proprietárias. Seus dados vivem em seus servidores, preços escalam com uso (e podem ficar caros rápido), e você depende de sua infraestrutura. Directus, Payload e Supabase são todos open source e auto-hospedáveis. Se propriedade de dados, controle de custo e flexibilidade de deployment importam para você, as opções open source vencem. Cobrimos isso em mais detalhes em nossa página de desenvolvimento de CMS headless.
Qual tem o melhor ecossistema de plugin/extensão?
Directus tem um marketplace com extensões da comunidade para interfaces, displays e módulos customizados. Payload tem um ecossistema de plugins crescente com plugins oficiais para SEO, formulários, nested docs e redirecionamentos. Supabase tem extensões Postgres (centenas delas) que servem um propósito diferente mas são incrivelmente poderosas. Para plugins específicos de CMS, Directus atualmente tem mais opções.
Qual é a melhor opção para um time pequeno com orçamento limitado?
Payload auto-hospedado em free tier do Vercel ou no hobby plan do Railway. Você obtém um CMS completo com zero custo mensal para projetos com baixo tráfego. O free tier do Supabase também é excelente para prototipagem. Directus requer self-hosting para uso gratuito (sem free tier na cloud), mas executa bem em uma VPS de $5/mês. Se orçamento é apertado e você precisa de ajuda fazendo a escolha certa, entre em contato conosco -- ajudamos vários times a encontrar a arquitetura mais eficiente em custo.