O Fim da "Gambiarra NoSQL": Por Que Migramos de MongoDB para PostgreSQL (via Supabase)

Mas aqui no Abstract Studio, nós não construímos apenas MVPs de fim de semana. Construímos produtos que escalam. E conforme nossos projetos cresceram, a liberdade do "schema-less" do Mongo, que antes era uma bênção, começou a se tornar nosso maior pesadelo técnico.

A decisão de migrar para PostgreSQL (adotando o Supabase como nossa infraestrutura de Backend-as-a-Service) não foi baseada em hype. Foi uma decisão de sobrevivência baseada em três pilares: Integridade de Dados (ACID), Relacionamentos Complexos e a previsibilidade do SQL.

A Ilusão da Flexibilidade (e o Custo da Dívida Técnica)

O argumento de venda do NoSQL é a flexibilidade. "Mude seus dados quando quiser". Na prática, isso transfere a responsabilidade da integridade dos dados do banco para o código da aplicação.

Quando você tem um objeto User que em 2023 tinha o campo address como uma string, e em 2024 virou um objeto, e em 2025 virou um array de objetos, seu código vira um museu de arqueologia de dados. Você acaba escrevendo dezenas de verificações defensivas no frontend e no backend:

JavaScript

// O clássico "Code Smell" de quem usa Mongo em produção há muito tempo
const userAddress = user.address 
  ? (Array.isArray(user.address) ? user.address[0] : user.address) 
  : 'Endereço não informado';

No PostgreSQL, a estrutura é rígida por design. Se você tenta inserir um dado que viola a estrutura, o banco grita. E acredite: você quer que o banco grite. É melhor um erro de inserção no log do que um banco de dados silenciosamente corrompido com dados mistos que quebrarão seu relatório financeiro no final do mês.

O Inferno do $lookup vs. A Elegância do JOIN

Aplicações modernas são relacionais. Ponto. Usuários têm Pedidos, Pedidos têm Itens, Itens têm Categorias.

No MongoDB, modelar isso exige decisões difíceis logo no dia 1: Embeddar ou Referenciar?

• Embeddar: Seus documentos ficam gigantes. Atualizar o nome de uma categoria exige varrer todos os produtos.

• Referenciar: Bem-vindo ao inferno das agregações.

Fazer um relatório simples de "Vendas por Categoria por Mês" no Mongo exige um pipeline de agregação que parece um hieróglifo.

Compare a legibilidade:

MongoDB (Aggregation Pipeline simplificado):

JavaScript

db.orders.aggregate([
  { $lookup: { from: "items", localField: "items", foreignField: "_id", as: "order_items" } },
  { $unwind: "$order_items" },
  { $lookup: { from: "categories", localField: "order_items.category_id", foreignField: "_id", as: "category" } },
  // ... e mais 20 linhas de agrupamento
])

PostgreSQL:

SQL

SELECT c.name, SUM(o.total)
FROM orders o
JOIN items i ON o.item_id = i.id
JOIN categories c ON i.category_id = c.id
GROUP BY c.name;

O SQL é declarativo. Você diz o que quer, e o otimizador de consultas do Postgres descobre a maneira mais eficiente de buscar. Isso não é apenas sobre sintaxe; é sobre performance previsível.

Por Que Supabase? (Postgres com Superpoderes)

Mudar para Postgres "vanilla" (puro) exigiria configurar servidores, gerenciar backups, cuidar de conexões, etc. Como uma agência focada em growth e shipar rápido, não queríamos gastar tempo gerenciando infraestrutura AWS RDS.

Escolhemos o Supabase porque ele nos dá um Postgres open-source completo, mas com uma camada de abstração que acelera o desenvolvimento em 10x:

1. Row Level Security (RLS)

Isso mudou o jogo para nós. Em vez de escrever lógica de autorização complexa na API ("se o usuário é admin, pode ver X, se não, Y"), nós definimos isso diretamente no banco de dados.

SQL

-- Política de segurança real no nosso banco
CREATE POLICY "Users can only see their own data"
ON profiles
FOR SELECT
USING ( auth.uid() = user_id );

Isso garante que, não importa de onde venha a requisição (Frontend, Edge Function, Script), a segurança é aplicada na raiz.

2. Tipagem Forte com TypeScript

O Supabase gera automaticamente os tipos TypeScript baseados no nosso schema SQL. Se alteramos uma coluna no banco, nosso build do CI/CD quebra imediatamente, nos avisando onde precisamos ajustar o código. Isso é integridade ponta a ponta.

3. Realtime Nativo

Precisávamos de funcionalidades em tempo real (chat, notificações). O Supabase expõe o "Postgres Replication log" via WebSockets. Não precisamos subir um servidor Socket.io separado. É literalmente "grátis" na arquitetura.

A Estratégia de Migração: Não Pare o Carro

Migrar um banco em produção é como trocar o pneu do carro com ele em movimento. Não fizemos um "Big Bang". Nossa estratégia foi:

1. Dual Write: Durante duas semanas, escrevemos nos dois bancos, mas líamos apenas do Mongo.

2. Backfill: Criamos scripts (Node.js) para migrar o histórico, tratando as inconsistências do Mongo caso a caso (e encontramos muitas).

3. Switch de Leitura: Passamos a ler do Postgres para entidades não-críticas primeiro.

4. Desligamento: Removemos o código legado.

Conclusão: Maturidade Técnica é Escolher a Ferramenta Certa

Não me entenda mal: NoSQL tem seu lugar (logs, dados de sensores, caching). Mas para o core business de 95% das aplicações SaaS e plataformas digitais, dados relacionais exigem um banco relacional.

A migração para PostgreSQL via Supabase nos deu paz de espírito. Sabemos que nossos dados estão consistentes, nossas queries são eficientes e nossa segurança é robusta. Deixamos de gastar tempo "consertando dados" e voltamos a gastar tempo "construindo features".

Se você sente que seu banco de dados está segurando o crescimento do seu produto, talvez seja hora de parar de lutar contra a ferramenta.

Sua arquitetura de dados está pronta para escalar ou é um castelo de cartas? No Abstract Studio, somos especialistas em transformar débitos técnicos em vantagens competitivas. Se você precisa de uma auditoria na sua stack ou está planejando um novo produto de alto desempenho, vamos conversar.

[Agende uma consultoria técnica com a Abstract]

O que você pode fazer a seguir?

Posso criar um diagrama Mermaid detalhando o fluxo de migração "Dual Write" mencionado no artigo ou gerar os scripts SQL de exemplo para as políticas de RLS (Row Level Security) que você pode usar como anexo técnico no blog. O que prefere?