Como uma empresa de tecnologia, a escolha de nosso principal banco de dados é de extrema importância. Nesse post iremos trazer os motivos e benchmarks que fizemos para escolha de nosso principal banco de dados.

Os critérios que usamos para essa escolha foram:

• Performance
• Velocidade de desenvolvimento
• Curva de aprendizado
• Integração com IA e diferentes índices no banco
• Integração com o backend
• Disponibilidade de desenvolvedores no mercado

---

⚖️ Performance

Um outro candidato que estávamos considerando como banco de dados seria o postgres. Para comparar a performance do postgres e mongodb criamos dois projetos de API Rest, um com golang + postgres e outro com nodejs + mongodb.

• Github da API Rest em Golang + Postgres
• Github da API Rest em NodeJs + MongoDb

Especificação da API e modelos:

Modelos

Financial Record

Representa um lançamento financeiro, possuindo os campos:

Campo	Descrição
amount	Valor absoluto do lançamento financeiro (float)
direction	Qual a natureza do lançamento, entrada (IN) ou saída (OUT)
dueDate	Data de vencimento do lançamento financeiro (date)
tags	Lista de tags do lançamento (via tabela de relação para o postgres e campo direto para o mongodb)

Tag

Representa uma tag, possuindo os campos:

Campo	Descrição
name	Nome da tag (string)

Endpoints

POST /organizations/:organizationId/tags

Cria uma tag.

POST /organizations/:organizationId/financial-records/bulk

Cria vários lançamentos financeiros.

GET /organizations/:organizationId/financial-records/reports/cash-flow

Gera um relatório do fluxo de caixa mês a mês de entradas e saídas ao longo dos últimos dois anos.

Especificação do teste

O teste de cada tecnologia possui duas etapas:

Etapa 1

Nessa etapa, o teste era executado por 1 min simulando 100 usuários simultâneos de 10 organizações distintas. Em cada iteração, o usuário criava se necessário 32 tags para cada organização e criava 400 lançamentos financeiros (com valores aleatórios e data de vencimento nos últimos dois anos) chamando o endpoint de inserção em lote.

Etapa 2

Nessa etapa, o teste era executado por 1 min simulando 100 usuários simultâneos de 10 organizações distintas. Em cada iteração, o usuário chamava o endpoint para gerar o relatório de fluxo de caixa.

Ambiente dos testes

Os testes foram realizados em um macbook air m3 de 8gb de ram. Os testes foram realizados em containers docker, sendo que o server (em nodejs ou golang) possuía 1gb de ram e 4 vcpu e o banco de dados (postgres ou mongodb) possuía 2gb de ram e 4 vcpu.

Resutados

Etapa 1

Métrica	Resultado de Golang + Postgres	Resultado de NodeJS + MongoDb
Tempo de execução	1m 0.8s	1m 1.7s
Total de lançamentos criados	1.608.400	1.314.000
Lançamentos criados por segundo	26.453,9 lançamentos / segundo	21.296,6 lançamentos / segundo

Etapa 2

Métrica	Resultado de Golang + Postgres	Resultado de NodeJS + MongoDb
Tempo de execução	1m 8.9s	1m 4.1s
Total de relatórios gerados de fluxo de caixa	545	730
Relatórios de fluxo de caixa gerados por segundo	7,9 relatórios / segundo	11,4 relatórios / segundo

Análise do benchmark

Em relação a inserção de lançamentos, ambas soluções atenderiam bem as demandas de nossa empresa. Na média cada organização de nosso sistema terá 2.000 lançamentos financeiros por mês. Sendo assim, o hardware empregado para cada tecnologia suportará a seguinte quantidade de organizações:

Número de organizações (Golang + Postgres) = (26.453,9 lançamentos / segundo) x (60x60x24x30 segundos no mês) / (2.000 lançamentos por mês por organização) = 34.284.254,4

Número de organizações (NodeJS + MongoDb) = (21.296,6 lançamentos / segundo) x (60x60x24x30 segundos no mês) / (2.000 lançamentos por mês por organização) = 27.600.393,6

Sendo assim, em relação à criação de lançamentos financeiros, ambas tecnologias atenderiam tranquilamente nossas demandas a um custo baixo por organização.

Em relação aos relatórios de fluxo de caixa, supondo que cada organização veja 100 vezes o relatório no dia, nosso sistema suportaria, para cada tecnologia, a seguinte quantidade de organizações:

Número de organizações (Golang + Postgres) = (7,9 relatórios / segundo) x (60x60x24 segundos no dia) / (100 visualizações por dia por organização) = 6.825,6

Número de organizações (NodeJS + MongoDb) = (11,4 relatórios / segundo) x (60x60x24 segundos no dia) / (100 visualizações por dia por organização) = 9.849,6

Obviamente, o tempo de gerar o relatório de fluxo de caixa com Golang + Postgres leva mais tempo por haver mais lançamentos financeiros, mas de qualquer forma, ambas soluções atenderiam nossas demandas em relação a geração de relatórios, pois nosso custo de servidores e banco de dados por organização continuariam sendo baixos em relação ao nosso ticket médio de R$ 200,00 mensais por organização.

Podemos notar também que o grande gargalo dos nossos servidores (principalmente dos bancos de dados) será a geração de relatórios, mostrando assim a importância de implementarmos estratégias sofisticadas de cache e de índices para reduzir nossos custos.

---

⚡ Velocidade de desenvolvimento

Golang + Postgres

Inicialmente mais lenta. Go exige mais configuração e código boilerplate; equipe sem experiência pode ter ritmo reduzido no começo . Definição de schemas SQL e migrações adicionam overhead. Em compensação, tipagem forte e menor ocorrência de bugs podem acelerar desenvolvimento futuro.

NodeJS + MongoDb

Muito rápida. JavaScript dinâmico e enorme ecossistema NPM agilizam a codificação. Mongo permite mudar o modelo de dados sem fricção (schema-less). Equipe já experiente em Node alavanca conhecimento prévio, acelerando entregas.

---

🎢 Curva de aprendizado

Golang + Postgres

Mais íngreme para a equipe atual. Go é relativamente fácil de aprender, mas é diferente de JS (novos paradigmas) - requer tempo de adaptação. Postgres requer conhecimento de SQL/modelagem relacional.

NodeJS + MongoDb

Suave. Equipe já domina Node.js; JavaScript é a linguagem mais popular. MongoDB é familiar para devs JavaScript (JSON) e amplamente adotado por iniciantes sem dificuldade. Onboarding de novos devs é rápido dado o pool experiente.

---

🤖 Integração com IA e diferentes índices no banco

Golang + Postgres

Capaz, porém demanda configuração. Postgres oferece full-text search e extensão pg_trgm para fuzzy search; extensão pgvector viabiliza busca semântica (muito usada em RAG) com boa performance. Integração com OpenAI via Go é possível, mas não tão plug-and-play. Pode exigir serviços adicionais (ex: Elastic) para busca avançada, aumentando complexidade.

NodeJS + MongoDb

Pronta para uso. MongoDB Atlas fornece busca de texto fuzzy e recursos avançados (sinônimos, autocomplete) embutidos via Lucene . Suporte nativo a Vector Search integra armazenamento de embeddings e consultas semânticas. Node possui SDKs maduros para OpenAI e libs como LangChain.js, facilitando RAG. A stack entrega IA e busca inteligente com mínimo esforço extra.

---

🔗 Integração com o backend

Golang + Postgres

Requer mais mapeamento. Necessário traduzir entre objetos Go <=> tabelas SQL (ORM ou consultas manuais). Mudanças de schema implicam migrar DB e ajustar código. Apesar de maior esforço, integração fortemente tipada reduz erros de integração em runtime. Go conta com binaries fáceis de implantar e SDKs para serviços cloud, porém ecossistema menor comparado ao Node.

NodeJS + MongoDb

Integração fluida. Objeto JavaScript <=> documento Mongo (JSON) se alinham naturalmente , eliminando impedâncias. Adicionar um campo no objeto reflete no banco sem migração . Grande oferta de libs para integrar APIs, serviços e front-end (mesma linguagem). Stack JavaScript unificada (front e back) simplifica comunicação e aproveitamento de código.

---

🧑‍💻 Disponibilidade de desenvolvedores no mercado

Golang + Postgres

Moderada. Go tem comunidade crescente, mas base menor; encontrar devs experientes pode ser mais difícil que em JS. Postgres em si é conhecido pela maioria, amenizando parte do desafio. Em geral, há menos profissionais especializados em Go disponíveis imediatamente no mercado local.

NodeJS + MongoDb

Alta. Node/JS conta com um vasto pool de desenvolvedores (JavaScript usado por ~62% dos devs). MongoDB é popular entre desenvolvedores web e full-stack. Facilidade de contratar ou treinar devs nessa stack é grande - desde juniors saídos de bootcamps até seniors com histórico em empresas modernas.

---

✅ Conclusão

Considerando o contexto específico – uma startup em estágio inicial, com prioridade máxima na rápida iteração de produto e uma equipe já experiente em Node.js – a recomendação mais alinhada é adotar a stack Node.js + MongoDB como plataforma principal neste momento. Os motivos podem ser sintetizados assim:

• Time-to-market acelerado: Node+Mongo otimiza o desenvolvimento ágil, permitindo que a equipe entregue novas funcionalidades e ajustes de forma veloz, capitalizando sua experiência prévia. Em uma fase early-stage, lançar e validar features rapidamente pode ser o fator decisivo de sucesso. A capacidade de alterar esquemas de dados em voo e aproveitar centenas de libs prontas dá uma flexibilidade incomparável.
• Adequação às necessidades atuais de IA: A integração nativa do MongoDB Atlas com busca avançada (texto, fuzzy, vetorial) simplifica adicionar features “inteligentes” sem desviar o foco para infraestrutura extra. Com Node, a equipe também consegue prototipar chamadas aos serviços da OpenAI e pipelines de RAG rapidamente usando o rico ecossistema JS. Essa stack suporta bem os experimentos de IA planejados, atendendo os requisitos sem atrito.
• Risco técnico baixo no curto prazo: Embora Go+Postgres tenha vantagens de performance e rigor, no curto prazo Node+Mongo supre com folga a escala de usuários e transações de uma aplicação em estágios iniciais. Qualquer diferença de desempenho teórica não deve se manifestar de forma preocupante em volumes iniciais. Além disso, MongoDB hoje oferece transações ACID e pode manter a integridade razoável dos dados financeiros, desde que usado apropriadamente (com validações e índices). Ou seja, não há impedimento técnico imediato que inviabilize Node+Mongo para o caso de uso – ao contrário, ela já impulsiona inúmeras aplicações web (incluindo fintechs) no início de vida.
• Alinhamento com talentos e comunidade: A empresa pode aproveitar integralmente as skills atuais do time, entrando em produção mais cedo. E se precisar contratar, há um mercado amplo de desenvolvedores Node/JS para recrutar, evitando gargalos de crescimento por falta de pessoal. A curva de aprendizado para Go, neste momento, representaria uma distração e possivelmente atraso na entrega de valor ao usuário.

Em termos estratégicos, portanto, Node.js + MongoDB é a stack recomendada para a startup neste estágio inicial, privilegiando velocidade e flexibilidade. Importante frisar que essa decisão não é irrevogável: conforme o produto amadurece e o volume de usuários e dados cresce, a equipe pode introduzir otimizações e até serviços em outras tecnologias de forma incremental. Por exemplo, partes do sistema com demanda extrema de performance ou cálculos financeiros críticos poderiam, no futuro, ser refatoradas em Go ou C++ como microsserviços, ou a persistência de alguns módulos poderia migrar para PostgreSQL ou outro DB relacional conforme as necessidades de consistência/analítica aumentem. Essa abordagem híbrida é comum – adotar Node+Mongo agora não impede de evoluir a arquitetura mais adiante, quando performance e escala se tornarem prioridades primárias.

Resumindo, para a conjuntura atual de uma startup financeiera early-stage que valoriza entregas rápidas e aprendizado contínuo do usuário, optar por Node.js com MongoDB maximiza a agilidade de desenvolvimento sem comprometer os objetivos. Golang+PostgreSQL, apesar de poderoso, seria uma escolha otimizada para um patamar de exigência que ainda não é a realidade da empresa – poderia alongar o desenvolvimento inicial e subutilizar recursos. A recomendação é: comece com Node+Mongo para ganhar tração e adapte futuramente conforme necessário, garantindo assim o melhor dos dois mundos no decorrer da evolução do produto.

---

🧠 FAQ

MongoDB não tem consistência forte como o Postgres. E os dados financeiros?

Verdade parcial. MongoDB suporta transações ACID desde a versão 4.0 (em múltiplos documentos desde a 4.2). Com uso correto de transações, validações no schema (via validator) e índices bem definidos, é possível manter integridade de dados perfeitamente aceitável para sistemas financeiros early-stage. Além disso, trabalhamos com validações também no nível de aplicação.

Postgres tem SQL e modelagem relacional, muito mais madura.

Verdade, mas maturidade nem sempre é sinônimo de agilidade. SQL é poderoso, mas em ambientes com modelos de dados altamente mutáveis, como em startups que estão iterando rápido, MongoDB brilha pela flexibilidade. Mudou um campo? Adicionou um array? Nenhum stress. Pra nossa fase, schema-less nos ajuda, não atrapalha.

E joins? Como vocês lidam com relacionamentos complexos?

MongoDB não é ruim de relacionamento — ele só faz diferente. Você pode modelar via embedded documents ou via referências e lookup. Sabendo quando usar cada um (baseado em leitura vs escrita), dá pra construir modelos limpos e performáticos. Além disso, desnormalização controlada é uma aliada poderosa para performance e simplicidade.

Busca avançada? Postgres tem pg_trgm, full-text, pgvector…

E nós temos MongoDB Atlas Search:

• Fuzzy search
• Synonyms
• Autocomplete
• Busca vetorial nativa

Tudo isso embutido, com zero necessidade de serviços externos. E o melhor: direto em JSON, na linguagem que já usamos.

Postgres escala melhor vertical e horizontalmente.

Depende do uso. MongoDB oferece sharding horizontal nativo, balanceamento automático de carga e escalabilidade sob demanda via Atlas. Na nossa escala atual, ambas soluções sobram. E quando a dor chegar, podemos escalar com tranquilidade — ou até isolar partes da stack em outros serviços (incluindo Postgres, se fizer sentido).

No longo prazo vocês vão sofrer com MongoDB.

Talvez. Mas não estamos otimizando o longo prazo ainda — estamos otimizando pelo agora:

• Time pequeno
• Time experiente em Node
• Produto mudando rápido
• IA integrada na stack
• Precisamos colocar coisa no ar e validar

E o Mongo entrega isso como poucos.

Então vocês estão descartando Postgres pra sempre?

Jamais. Nossa decisão é estratégica, não ideológica. Postgres pode (e provavelmente vai) entrar no stack no futuro, como banco analítico, para relatórios complexos ou serviços com consistência mais crítica. Mas pra esse momento da empresa, MongoDB é o cavalo certo para a corrida.

---

❗ Disclaimers

• Os testes não são extremamente rigorosos, mas dão uma boa base de comparação entre as tecnologias consideradas.
• Sabemos que cada microserviço tem suas necessidades específicas e que podem demandar diferentes bancos de dados. Nesse post, buscamos definir o nosso principal banco de dados, aquele que atenderia bem nossos principais microserviços.