Para um SaaS que vai escalar, a escolha padrão correta é o PostgreSQL. Ele cobre cerca de 90% do que um produto web ou mobile precisa: dados transacionais, relações entre entidades, pesquisa, JSON, filas leves e até parte da carga vetorial para a IA. A verdadeira pergunta quase nunca é "relacional ou NoSQL": é "tenho uma razão concreta para NÃO usar Postgres". Na maioria das vezes, não.
PostgreSQL por padrão: por que funciona 9 em cada 10 vezes
Um SaaS lida com dados estruturados e relacionados entre si: utilizadores que pertencem a organizações, subscrições ligadas a faturas, projetos ligados a tarefas. É exatamente para isso que as bases relacionais foram feitas. O Postgres acrescenta a essa base superpoderes que evitam empilhar ferramentas: colunas JSONB para o semiestruturado, pesquisa full-text integrada, a extensão pgvector para os embeddings de IA e restrições que garantem a integridade dos teus dados.
- Transações ACID: os teus pagamentos e dados críticos mantêm-se coerentes, mesmo após uma falha.
- Um único sistema para operar, fazer backup e monitorizar em vez de três: menos custos, menos falhas.
- Ecossistema maduro: Prisma, migrações, replicação, hosting gerido em todo o lado (Cloud Run, Neon, Supabase, RDS).
- JSONB quando precisas de flexibilidade, sem abrir mão do relacional para o resto.
Relacional vs NoSQL: quando sair do Postgres
O NoSQL (MongoDB, DynamoDB, Firestore) não é "mais moderno", responde a outras restrições. Só ganhas se o teu caso de uso encaixar mesmo: volume massivo com escrita muito intensa, um esquema realmente imprevisível ou a necessidade de uma distribuição geográfica extrema. Para um SaaS B2B típico em fase de lançamento e crescimento, essas restrições ainda não existem, e adotar NoSQL cedo demais faz-te pagar em complexidade algo que nunca vais usar.
Escolher NoSQL porque "escala" quando tens 200 utilizadores é otimizar um problema que não tens, à custa dos que já tens.
Índices, migrações, escalabilidade: três reflexos desde a V1
Uma base bem escolhida não chega: são três hábitos que decidem se o teu SaaS aguenta com 10.000 utilizadores. Primeiro, os índices: uma query que varre uma tabela inteira é rápida com 100 linhas e catastrófica com 1 milhão. Indexa as colunas que filtras e juntas com frequência, e mede com EXPLAIN. Depois, as migrações: cada mudança de esquema deve ser versionada e reproduzível (Prisma Migrate), nunca aplicada à mão em produção. Por fim, a escalabilidade: primeiro vertical (mais CPU/RAM), depois réplicas de leitura, e no sharding só se pensa muito tarde: a maioria dos SaaS nunca lá chega.
- Índices: mira nas colunas das cláusulas WHERE, JOIN e ORDER BY; um índice mau custa na escrita, um em falta mata a leitura.
- Migrações: versionadas, testadas, reversíveis: a base evolui com o produto sem downtime.
- Escalabilidade: primeiro vertical, depois réplicas de leitura; o Postgres aguenta milhões de linhas muito antes de se falar em sharding.
A decisão certa para uma V1
Escolher PostgreSQL desde o primeiro dia, modelar de forma limpa, pôr os índices certos e versionar as migrações: é isso que te evita uma reescrita ao 12.º mês. É exatamente a base que montamos nas nossas V1 entregues em 7 dias por 15.000 € — Next.js, NestJS, Prisma e Postgres —, uma base que te acompanha do primeiro cliente até ao salto de escala, sem dívida técnica escondida.