Comparei oito alternativas ao Convex. Não vou mudar

Comparei oito alternativas ao Convex em julho de 2026 e nenhuma deu aos meus agentes de IA um backend mais simples de alterar. O Appwrite é o concorrente estabelecido mais forte e o InsForge a novidade mais interessante, mas continuo no Convex porque todo o backend fica reunido em TypeScript.

Como os classifiquei: menos sistemas pesaram mais do que o preço

Classifiquei as plataformas pelo número de sistemas separados que um agente tem de compreender para concluir uma alteração no backend. Esse critério pesou mais do que o preço, porque cinco dos nove planos pagos mais baratos custam entre 25 e 30 $ por mês. O Convex ficou em primeiro lugar, o InsForge em segundo e o Appwrite em terceiro.

O fator decisivo não foi o número de funcionalidades oferecidas por cada plataforma. Foi a possibilidade de um agente ver e alterar uma funcionalidade completa do backend sem passar por vários sistemas de configuração.

Porque é que o Convex funciona tão bem ao programar com IA?

O Convex é mais simples porque mantém todo o backend como código numa só pasta. Esquema, queries, mutations, trabalhos agendados, armazenamento de ficheiros, índices vetoriais e configuração da autenticação ficam lado a lado em ficheiros TypeScript. Um agente de IA consegue, por isso, alterar uma funcionalidade como qualquer outro módulo, sem recorrer a um painel.

convex/
  schema.ts       # tables, indexes, vector indexes
  users.ts        # queries and mutations
  billing.ts      # actions calling Stripe
  crons.ts        # scheduled jobs
  http.ts         # webhook endpoints
  auth.config.ts  # auth providers

Aqueles são os ficheiros que um agente precisa realmente de compreender antes de conseguir lançar uma funcionalidade, e cabem num ecrã. Nos meus projetos, uma funcionalidade de convites com limite de utilização costuma tocar em três ficheiros dessa pasta. Se o modelo definir os dados de forma incorreta, os tipos gerados indicam o erro. Também não há uma alteração separada num painel que possa ficar esquecida.

O Convex também dá aos agentes acesso direto ao backend através de ferramentas oficiais. O guia do Convex Developer Hub para Claude Code instala o plugin com /plugin install convex@claude-plugins-official; depois, o plugin consegue ler dados e registos de desenvolvimento, executar funções e manter os tipos gerados atualizados [1]. O guia para Codex oferece acesso semelhante através de MCP e acrescenta os subagentes convex-expert e convex-reviewer [2]. Assim, o meu agente pode inspecionar o backend real em vez de adivinhar como funciona.

A pesquisa vetorial segue a mesma abordagem: declaro um vectorIndex no esquema, defino 1536 dimensões para os embeddings da OpenAI e consulto-o a partir do código do servidor [3]. Não há uma segunda base de dados nem um processo de sincronização separado para gerir. Há quem chame vibe coding a esta forma de desenvolver, mas o nome importa menos do que a vantagem prática. Menos componentes dão ao agente e a mim menos coisas para esquecer.

Porque escolhi o Convex em vez do Supabase para programar com IA

Escolhi o Convex porque, no Supabase, uma alteração ao backend atravessava frequentemente migrações SQL, políticas de row-level security, Edge Functions, regras de armazenamento e tipos gerados. Valorizo o ecossistema Postgres, mas no meu trabalho em produção estas partes separadas davam aos agentes de IA mais oportunidades para deixarem uma alteração a meio.

O guia de migrações do Supabase documenta claramente a disciplina necessária. A regra principal é “nunca alterar diretamente a base de dados remota”, por isso cada mudança de esquema passa a ser uma migração SQL com data e hora, testada localmente, guardada no repositório e depois aplicada. Uma alteração feita no painel pode deixar as versões local e remota dessincronizadas [4].

É um processo de engenharia sensato, mas dá ao agente de IA mais lugares onde pode fazer apenas parte da alteração. Nos meus projetos, os agentes atualizavam regularmente quatro partes e esqueciam a quinta. O Convex elimina esse erro específico porque o quinto lugar não existe.

As alterações ao esquema do Convex podem continuar a exigir uma atualização dos dados existentes, mas o código desse trabalho fica junto do resto do backend, em vez de entrar numa cadeia paralela de ficheiros e ferramentas.

Porque ficaram as outras alternativas ao Convex para trás

Cada uma das restantes alternativas deixa de fora uma parte diferente do processo que procuro. O Appwrite distribui o backend por vários recursos, o InstantDB precisa de outra plataforma para a lógica do servidor e a Cloudflare obriga-me a montar o backend. O Firebase, o Nhost e o Encore.ts trazem compromissos semelhantes.

O Appwrite é a alternativa estabelecida mais forte

O Appwrite é a alternativa tudo-em-um estabelecida mais forte, sobretudo quando a escala da autenticação importa mais do que manter tudo numa só base de código. O plano mensal de 25 $ cobre toda a organização e inclui 200.000 utilizadores ativos mensais, 150 GB de armazenamento, 2 TB de largura de banda, 3,5 milhões de execuções de funções e cópias de segurança diárias [5].

O Appwrite também disponibiliza skills para agentes em nove SDK no Claude Code, Codex e Cursor [6], enquanto os seus servidores MCP conseguem gerir diretamente bases de dados, utilizadores e ficheiros [7]. Há, portanto, bastante apoio ao trabalho com agentes. Se o seu editor é o Cursor, escrevi sobre porque a Agents Window pode abrir primeiro e como recuperar o IDE.

Ainda assim, coloquei o Appwrite em terceiro lugar porque o backend é uma coleção de recursos, como buckets, permissões e agendamentos, em vez de uma base de código que eu consiga ler como um todo. Além disso, a pesquisa vetorial exige outro serviço: o próprio guia do Appwrite liga uma Function à OpenAI para criar embeddings e usa um índice Pinecone externo para a pesquisa [8]. Esse serviço adicional era precisamente o que eu queria evitar.

O InstantDB precisa de uma segunda plataforma para a lógica do servidor

O InstantDB é o que apresenta um processo mais parecido com o do Convex, mas cobre apenas parte do backend de que preciso. O esquema e as permissões são código, e os agentes podem usar um servidor MCP para criar aplicações e aplicar alterações a ambos. O InstantDB também disponibiliza ficheiros de instruções para o Claude Code e o Codex [9].

O plano gratuito inclui 1 GB, pedidos de API ilimitados e nenhuma pausa automática, enquanto o plano Pro de 30 $ aumenta o armazenamento para 10 GB e acrescenta dez membros da equipa e cópias de segurança diárias [10]. Estas condições são atraentes, mas não resolvem a falta de funcionalidades do lado do servidor.

O problema é que o InstantDB é um motor de sincronização com autenticação e armazenamento, não um lugar para a lógica do servidor. A documentação cobre presença, cursores, permissões e uma API HTTP de administração, mas não funções alojadas, tarefas cron ou pesquisa vetorial [11]. Continuaria a precisar de uma segunda plataforma para a metade do produto que corre no servidor, por isso não satisfaz os meus requisitos.

A Cloudflare é barata, mas não é um único backend

A Cloudflare tem o preço inicial mais baixo, mas chegar ao mesmo conjunto de funcionalidades exige vários produtos separados. O plano mensal de 5 $ inclui 10 milhões de pedidos e 30 milhões de milissegundos de CPU [12], enquanto o Vectorize oferece uma base de dados vetorial que se liga diretamente aos Workers [13].

Para criar um backend completo, tenho de combinar Workers, D1, R2, Queues e Vectorize, cada um com a sua configuração, e depois fornecer separadamente a autenticação dos utilizadores. A configuração dos dados na UE também exige cuidado: o D1 consegue manter a base de dados numa jurisdição da UE, mas os Workers podem continuar a aceder-lhe a partir de qualquer lugar, porque a restrição de localização se aplica à base de dados e não à computação [14].

O Firebase continua a ser um conjunto de produtos separados

O Firebase continua competitivo, com autenticação gratuita até 50.000 utilizadores ativos mensais antes de se aplicar o preçário do Google Cloud Identity Platform [15]. Continua a ser um grupo de produtos Google Cloud com consolas e preços separados, por isso não satisfaz o meu requisito de ter uma só base de código para o backend.

O Nhost volta a introduzir migrações em várias partes

O Nhost combina Postgres, GraphQL, autenticação e armazenamento a partir de 25 $, incluindo 15 $ de créditos de computação e utilizadores ilimitados [16]. Uma alteração ao esquema produz uma migração SQL e metadados Hasura em YAML, que o guia de desenvolvimento local do Nhost indica que devem ser guardados no repositório e aplicados em conjunto [17]. Este processo assemelha-se ao do Supabase que causou problemas nos meus projetos.

O Encore.ts começa nos 148 $ antes da fatura da cloud

O Encore.ts resolve um problema diferente: declaro a infraestrutura em TypeScript e o Encore cria-a na minha própria conta AWS ou GCP. A produção começa nos 49 $ por membro e nos 99 $ por ambiente cloud, aos quais se somam 2,50 $ por recurso e a fatura separada da AWS [18]. A taxa mínima da plataforma é, portanto, 148 $ por mês.

Esta opção pode fazer sentido para uma equipa que já gere uma conta cloud, e o apoio do Encore ao desenvolvimento com IA é útil. Não se adapta à minha forma de lançar rapidamente produtos pequenos.

O InsForge é a alternativa ao Convex que estou a acompanhar

O InsForge é o que mais se aproxima do processo que procuro, porque é a única alternativa da lista criada especificamente para agentes de IA. A direção do produto encaixa no meu trabalho, mas a idade da empresa e o financiamento ainda me impedem de transferir para lá dados de clientes.

Quando a versão 2.0 foi lançada a 9 de março de 2026, o InsForge apresentou-se como um backend para desenvolvimento com agentes e afirmou que os agentes já realizavam 99% das operações na plataforma [19]. A OpenAI chega à infraestrutura para agentes pelo lado oposto, e explico o que a Agents API aloja e que custos continuam a ser seus.

O produto sustenta essa afirmação com Postgres e pgvector, autenticação, armazenamento, edge functions, realtime e um gateway compatível com a OpenAI para modelos de vários fornecedores [19]. Suporta funções acionadas por cron através de pg_cron [20], e o código com licença Apache 2.0 pode ser alojado em infraestrutura própria com Docker [21]. O plano Pro de 25 $ inclui 100.000 utilizadores ativos mensais, uma base de dados de 8 GB e 10 $ de créditos de computação, com pequenas instâncias sempre ativas a partir de 5 $ [22].

Coloquei o InsForge em segundo lugar, e não em primeiro, em parte porque o Postgres volta a trazer migrações e row-level security ao sistema, mesmo quando os agentes os gerem. A minha maior preocupação é a idade da empresa. A Crunchbase regista uma ronda pré-seed de 1,5 milhões de dólares da MindWorks Capital e da Baidu Ventures [23], enquanto a MindWorks data a empresa de 2025 [24].

O Convex está muito mais avançado: angariou 24 milhões de dólares em novembro de 2025 numa ronda liderada pela a16z e coliderada pela Spark Capital [25], e depois afirmou ter quase 10.000 equipas pagantes em abril de 2026 [26].

Convex, ronda mais recente

24 M$

liderada pela a16z, novembro de 2025

equipas pagantes no Convex

10.000

número da empresa, "quase 10.000", abril de 2026

InsForge, pré-seed

1,5 M$

MindWorks Capital e Baidu Ventures, 2025

A diferença de maturidade explica porque testaria o InsForge, mas ainda não transferiria dados de clientes para lá. A licença Apache 2.0 e a possibilidade de alojamento próprio tornam um teste futuro menos arriscado.

Quanto custa o Convex na UE? Mais 30%, com menos incluído

Um deployment pago do Convex na UE custa mais 30% do que o equivalente nos EUA e não recebe a utilização incluída nos planos norte-americanos. A página de preços do Convex inclui 25 milhões de chamadas a funções no plano Pro dos EUA [27], enquanto os recursos pagos na UE custam mais 30% e são faturados por consumo [28].

A região da UE funciona em AWS eu-west-1, na Irlanda, e está disponível em todos os planos, incluindo o gratuito. Num produto europeu com tráfego significativo, a diferença de preço deve entrar no cálculo antes de escolher a região.

O custo adicional na UE não é a minha única preocupação. Os deployments Free e Starter usam a classe S16, com 16 queries e 16 mutations simultâneas, enquanto o Professional passa para S256 [29]. O tráfego pode, por si só, obrigar à atualização de 25 $ por programador [27].

O Convex Auth é outra limitação. Continua em beta, e a documentação avisa que “não está completo e pode mudar de formas incompatíveis com versões anteriores”. Para autenticação em produção, o Convex recomenda Clerk, Auth0 ou WorkOS, sendo este último gratuito até um milhão de utilizadores [30].

A simplicidade do backend numa só pasta também cria lock-in. O meu backend usa queries e mutations do Convex sobre um modelo de documentos, e não SQL que eu possa ligar diretamente a uma ferramenta comum de relatórios.

Apesar destas preocupações, o preço de entrada é bom. O plano Starter gratuito suporta aplicações em produção para até seis programadores e inclui um milhão de chamadas a funções nos deployments dos EUA [27]. Continuo a aceitar os custos do Convex porque todas as alternativas que encontrei exigem mais tempo de desenvolvimento, e esse tempo custa-me mais do que a fatura da plataforma.

Que alternativa ao Convex deve escolher?

Para um produto assistido por IA que tenha de ser lançado depressa, eu escolheria o Convex. Testaria o Appwrite se a autenticação de centenas de milhares de utilizadores se tornasse a principal limitação. Com uma equipa em crescimento, o preço fixo de 25 $ por organização torna-se mais atraente do que a fatura por programador do Convex [5].

Voltaria a avaliar o InsForge em meados de 2027. Outra ronda de financiamento e clientes de produção identificados poderiam mudar a minha resposta, enquanto a licença que permite alojamento próprio já torna um teste futuro menos arriscado.

O teste prático é simples: se você abrir o repositório depois de uma semana sem lhe tocar, veja se uma pasta basta para encontrar toda a lógica do backend. Se bastar, é mais provável que um agente de IA conclua uma alteração sem se esquecer de uma configuração separada. Para tudo o que fica fora da pasta do backend, apoio-me num mapa de quatro camadas que orienta os meus agentes para os factos atuais.

O meu artigo anterior analisou quanta autoridade devemos dar a um modelo de IA. Escolher um backend levanta uma questão relacionada: quantas partes separadas tem esse modelo de compreender? Continuo a escolher o Convex porque mantém esse número baixo.