06 de out. de 2025·8 min
MongoDB vs PostgreSQL: escolhendo o banco certo em 2026
Compare MongoDB e PostgreSQL em modelagem de dados, consultas, indexação, escala, transações e operação para escolher o melhor banco para sua aplicação.
Compare MongoDB e PostgreSQL em modelagem de dados, consultas, indexação, escala, transações e operação para escolher o melhor banco para sua aplicação.
A decisão não é “qual é o melhor?”—é “qual sistema se encaixa melhor nesta carga de trabalho e equipe?” MongoDB e PostgreSQL são bancos maduros e amplamente adotados, mas otimizam padrões diferentes: MongoDB para dados flexíveis em forma de documento e iteração rápida; PostgreSQL para modelagem relacional, expressividade SQL e garantias fortes de integridade.
A escolha importa mais quando sua carga de trabalho pende fortemente para um lado:
Um modelo mental útil: se seus dados são naturalmente um conjunto de entidades com relacionamentos, PostgreSQL costuma ser o ajuste mais simples. Se seus dados são naturalmente uma coleção de registros autocontidos que mudam de formato, MongoDB pode reduzir atrito — especialmente no início.
Para manter a comparação prática, avalie ambas as opções com as mesmas perguntas:
Muitas equipes usam persistência poliglota: PostgreSQL para dados system-of-record e MongoDB para conteúdo, modelos de leitura tipo cache ou recursos pesados em eventos. O objetivo é menos comprometer as partes que importam — não pureza ideológica.
Se você está construindo serviços novos rapidamente, pode ajudar escolher uma pilha e arquitetura que não prendam a equipe cedo demais. Por exemplo, Koder.ai (uma plataforma que gera apps full-stack a partir de chat) padroniza React + Go + PostgreSQL, que pode ser um “default seguro” para sistemas transacionais, mantendo campos semiestruturados via JSONB quando os requisitos são fluidos.
No nível do modelo de dados, MongoDB e PostgreSQL encorajam formas diferentes de pensar sobre a “forma” da sua aplicação. MongoDB é um banco de documentos: você armazena documentos JSON-like autocontidos em coleções. PostgreSQL é um banco relacional: você armazena linhas em tabelas, relaciona-as por chaves e consulta essas relações.
No MongoDB, um registro típico pode embutir dados relacionados diretamente:
orders
Isso se alinha bem com dados hierárquicos ou “agregados” que você geralmente busca por inteiro.
No PostgreSQL, você normalmente normalizaria isso em múltiplas tabelas:
orders (uma linha por pedido)order_items (muitas linhas por pedido)addresses (tabela separada opcional)Essa estrutura brilha quando você precisa de relacionamentos consistentes e joins frequentes — por exemplo, relatórios envolvendo clientes, produtos e pedidos.
MongoDB é flexível por padrão: documentos na mesma coleção podem ter campos diferentes. Isso pode acelerar a iteração, mas também facilita que formatos inconsistentes entrem, a menos que você adicione regras de validação e disciplina.
PostgreSQL impõe estrutura com tipos de coluna, constraints e chaves estrangeiras. Mudanças exigem migrations, mas você ganha fortes guardrails para integridade dos dados.
Um caminho intermediário existe: o JSONB do PostgreSQL permite armazenar dados semiestruturados dentro de uma tabela relacional. Muitas equipes usam colunas para campos estáveis (IDs, timestamps, status) e JSONB para atributos em evolução — mantendo integridade relacional e acomodando mudanças.
MongoDB geralmente é natural para objetos aninhados, payloads de eventos e dados tipo conteúdo que você lê como um todo. PostgreSQL se destaca quando relacionamentos são de primeira classe, joins são comuns e regras de consistência (constraints) fazem parte do modelo — não apenas do código da aplicação.
A consulta é onde a sensação do dia a dia entre MongoDB e PostgreSQL fica mais óbvia: PostgreSQL otimiza operações em conjuntos entre tabelas, enquanto MongoDB otimiza trabalhar com documentos aninhados na forma da aplicação.
O SQL do PostgreSQL é declarativo e composable: você descreve o conjunto de resultados e o planner decide como obtê-lo. Isso torna filtragens complexas, agrupamentos, funções de janela, CTEs e transformações em múltiplas etapas naturais — especialmente quando requisitos mudam no meio do caminho.
MongoDB tipicamente usa consultas find para recuperações simples e o Aggregation Pipeline para transformações (filter → project → group → sort, etc.). O pipeline pode ser expressivo, mas é mais procedural na forma — a ordem importa — e pipelines muito complexos podem ser mais difíceis de entender do que uma única declaração SQL.
PostgreSQL trata joins como ferramenta de primeira classe. Você pode normalizar dados e fazer joins sem mudar como consulta; a troca é que você precisa pensar em cardinalidade de joins, índices e, às vezes, tuning de consulta.
MongoDB incentiva embutir dados relacionados quando são normalmente lidos juntos (por exemplo, um pedido com itens). Isso pode eliminar joins totalmente e simplificar leituras. O downside é duplicação e atualizações mais complicadas.
Quando você precisa de relações entre coleções, MongoDB oferece $lookup em agregações. Funciona, mas geralmente não é tão ergonômico — nem tão previsivelmente performático em escala — quanto joins relacionais bem indexados, e pode empurrar você para pipelines maiores e mais complexos.
PostgreSQL tende a vencer para workloads de BI: consultas ad-hoc, joins exploratórios e reporting entre muitas entidades são diretos, e a maioria das ferramentas de analytics fala SQL nativamente.
MongoDB pode suportar reporting, especialmente se seus relatórios se alinharem aos limites de documentos, mas análise multi-entidade ad-hoc frequentemente exige mais trabalho de pipeline (ou ETL para um sistema columnar/armazém).
Ambos têm drivers maduros, mas “caem diferente” na mão. PostgreSQL se beneficia de um enorme ecossistema de ferramentas SQL, ORMs e analisadores de consulta. MongoDB pode parecer mais natural no código quando seus objetos de domínio já são JSON-like — até que relacionamentos e necessidades de reporting cresçam.
O design de esquema é onde MongoDB e PostgreSQL se diferenciam mais no dia a dia: MongoDB otimiza modelar dados como objetos da aplicação, enquanto PostgreSQL otimiza modelar dados como um conjunto de fatos relacionados.
No PostgreSQL, normalização é o default: você separa entidades em tabelas e as conecta com chaves estrangeiras. Isso reduz duplicação e torna atualizações cross-entity mais seguras (mudar um nome de cliente uma vez).
No MongoDB, embedding é comum: você armazena dados relacionados dentro de um único documento para buscá-lo em uma única viagem. Por exemplo, um documento de pedido pode embutir seus itens.
A troca é o custo de atualização e consistência. Embedding pode duplicar dados de referência (título do produto, snapshot de preço), enquanto excessiva normalização leva a muitos joins, APIs verborrágicas e surpresas de desempenho.
Quando os requisitos evoluem — por exemplo, adicionar múltiplos endereços de envio, introduzir campos de imposto opcionais ou suportar novos atributos de produto — os documentos flexíveis do MongoDB podem absorver novos campos com menos migração inicial.
PostgreSQL também pode evoluir suavemente, mas as mudanças são explícitas: ALTER TABLE, backfilling e apertar constraints ao longo do tempo. Muitas equipes usam a abordagem “nullable primeiro, constrain depois” para entregar rápido sem perder integridade a longo prazo.
Os guardrails embutidos do PostgreSQL (foreign keys, CHECK, unique) evitam que estados ruins entrem no banco.
MongoDB costuma depender mais da validação na aplicação, embora exista validação via JSON Schema. A diferença chave é cultural: PostgreSQL incentiva impor invariantes de forma central; equipes MongoDB frequentemente as aplicam em paths de código e testes.
Over-embedding leva a documentos muito grandes, hot spots (muitas escritas em um mesmo documento) e updates parciais complicados. Over-normalizing leva a joins excessivos, APIs “chatas” e surpresas de desempenho.
Uma regra prática: embed dados que mudam junto; referencie dados que mudam independentemente.
Índices são onde o debate MongoDB vs PostgreSQL frequentemente fica prático: o “melhor” banco costuma ser o que pode responder suas consultas mais comuns com latência previsível.
PostgreSQL por padrão usa índices B-tree, que cobrem grande parte dos workloads (igualdade, ranges, ordenação). Quando padrões mudam, você tem opções especializadas: GIN (ótimo para arrays e full-text, comumente usado com JSONB), GiST/SP-GiST (geoespacial e certos tipos customizados) e BRIN (tabelas grandes e naturalmente ordenadas como séries temporais).
MongoDB também usa índices de estilo B-tree para lookups comuns e ordenações, com tipos adicionais que você encontrará rapidamente: multikey para arrays, 2dsphere para geoespaciais e índices text para busca full-text básica.
Um enquadramento prático para a escolha “document database vs relational database” aqui: PostgreSQL tem mais “primitivas de índice” para diferentes tipos de dados e operadores, enquanto MongoDB enfatiza acesso flexível a documentos com forte suporte para indexar campos aninhados.
Ambos os sistemas dependem fortemente de índices compostos. A ideia central é a mesma: indexe os campos que você filtra juntos para que o mecanismo possa reduzir resultados cedo.
WHERE status = 'active').Ambos os bancos oferecem capacidades de full-text embutidas, mas devem ser vistas como “suficientes” para experiências de busca simples.
Se busca for um recurso central do produto (relevância complexa, autocomplete, faceting pesado), costuma ser mais limpo usar um motor de busca dedicado e integrá-lo — ao invés de esticar qualquer um dos bancos além do seu conforto.
Para considerações de desempenho, valide estratégias de índice com planos de consulta reais.
EXPLAIN (ANALYZE, BUFFERS) e observe scans sequenciais, estimativas erradas de linhas e sorts caros.explain() e analise os estágios (uso de índice, docs examinados vs retornados).Aqui é onde debates “SQL vs MongoDB query language” se apaziguam: o índice vencedor é o que reduz o trabalho no caminho que sua aplicação de fato executa.
Transações não são apenas uma checklist — elas definem que tipos de falhas sua aplicação pode sobreviver sem corromper dados. ACID normalmente significa: writes são tudo ou nada (Atomicidade), dados permanecem válidos (Consistency), requisições concorrentes não veem trabalho pela metade (Isolation) e, uma vez committed, os dados persistem após quedas (Durability).
PostgreSQL é construído em torno de transações multi-statement e multi-table. Você pode modelar com segurança fluxos como “criar pedido → reservar inventário → cobrar pagamento → gravar lançamento” como uma unidade de trabalho, confiando em garantias maduras e recursos (constraints, foreign keys, triggers) para impor invariantes.
Para concorrência, PostgreSQL usa MVCC: leitores não bloqueiam escritores e vice-versa, e níveis de isolamento (Read Committed, Repeatable Read, Serializable) permitem escolher quanta prevenção de anomalias você precisa. Isso importa para sistemas de escrita intensa com regras de negócio complexas.
MongoDB fornece atomicidade no nível de documento único por padrão, ideal quando você embute dados relacionados e mantém updates dentro de um documento. Também suporta transações multi-documento (replica sets e clusters sharded), possibilitando fluxos estilo relacional — mas com mais overhead e limites práticos (tamanho/tempo de transação, maior coordenação e bloqueios).
Consistência no MongoDB é configurável via read concern e write concern. Muitas aplicações usam gravações majority e leituras apropriadas para evitar rollbacks após failover.
Operações que envolvem múltiplas entidades são onde as diferenças aparecem:
Se seus fluxos centrais dependem de invariantes estritas entre múltiplos registros sob concorrência, PostgreSQL costuma parecer mais simples. Se você consegue manter updates críticos dentro de um documento (ou tolera reconciliações eventuais), MongoDB pode ser um encaixe limpo.
Diferenças de desempenho entre MongoDB e PostgreSQL geralmente têm menos a ver com “motor mais rápido” e mais com quão bem o seu modelo de dados casa com padrões de acesso — e quanto trabalho o banco precisa fazer por requisição.
Sistemas leitura-pesada recompensam designs que minimizam round trips e trabalho caro no servidor. MongoDB pode ser muito rápido quando uma requisição mapeia para um único fetch de documento (ou um scan de índice apertado) e o documento não é oversized.
Sistemas escrita-pesada frequentemente esbarram na manutenção de índices, amplificação de escrita e configurações de durabilidade. PostgreSQL pode performar extremamente bem com linhas estreitas, índices bem escolhidos e writes em batch; MongoDB também pode sobressair em padrões tipo append, mas documentos grandes com updates frequentes in-place podem ficar caros.
Workloads mistos expõem contenção: updates que tocam índices quentes, pressão de locks e churn de cache. Aqui, ambos os bancos se beneficiam de reduzir “trabalho extra por requisição” (índices desnecessários, projeções largas, queries excessivamente chatty).
Latência p99 baixa costuma ser dominada pelas queries mais lentas, não pela média. Throughput é dominado por quão eficientemente o banco usa CPU, memória e I/O sob concorrência.
Benchmark de forma justa mantendo:
Joins vs fetch de documento: joins do PostgreSQL são poderosos, mas podem ser caros em escala sem boas chaves de join e predicados seletivos. MongoDB evita joins quando dados são embutidos, mas pode pagar com documentos maiores e duplicação.
Tamanho do documento/row: performace do MongoDB pode cair quando documentos ficam grandes e a maioria das queries precisa de um pequeno subconjunto de campos. Em PostgreSQL, rows largas e blobs JSONB grandes também aumentam I/O e pressão de memória.
Manutenção de índices: mais índices melhoram leituras — até o ponto em que esmagam as gravações. Ambos os sistemas pagam um custo por write para atualizar cada índice, então mantenha índices atrelados a padrões reais de consulta.
Crie um pequeno harness que reproduza seus 5–10 endpoints ou consultas principais com concorrência e distribuições de dados realistas. Comece com uma baseline e depois varie uma coisa por vez (conjunto de índices, embedding de documento, JSONB vs tabelas normalizadas). Mantenha a checklist num repositório e itere — não confie em benchmarks sintéticos de query única.
Alta disponibilidade (HA) e escalabilidade não são apenas “ligar replicação” — são escolhas de design que afetam esquema, padrões de consulta e carga operacional. O caminho mais rápido para crescer é alinhar a mecânica de escala com seus padrões de acesso dominantes (leitura-pesada, escrita-pesada, séries temporais, multi-tenant, etc.).
MongoDB comumente usa replica sets: um primary aceita writes, secondaries replicam o oplog e uma eleição promove um novo primary em falha. Esse modelo é direto para HA, mas você deve planejar para:
PostgreSQL normalmente usa streaming replication (física), com um primary e um ou mais standbys. Failover geralmente é orquestrado por ferramentas (serviços gerenciados, Patroni, etc.), e as trocas incluem:
Sharding do MongoDB é embutido e pode distribuir leituras e escritas entre shards. O porém é a complexidade operacional: escolher uma shard key, evitar hotspots, lidar com migrações de chunks e entender custos de queries cross-shard.
PostgreSQL escala “up” muito bem, e “out” de forma mais seletiva. Padrões comuns são read scaling via réplicas e write scaling via:
Antes de se comprometer, modele suas consultas futuras: quais campos filtram mais, quais ordenações são necessárias e o que precisa ser transacional. Um design que serve hoje mas força fan-out cross-shard, partições quentes ou replicação excessivamente síncrona vai travar antes do esperado.
Trabalho operacional é onde “MongoDB vs PostgreSQL” deixa de ser sobre recursos e vira hábito: como você faz backup, quão rápido restaura e com que confiança muda versões.
PostgreSQL tipicamente usa uma mistura de backups lógicos e físicos:
pg_dump/pg_restore são flexíveis (restaurações por tabela, portabilidade) mas podem ser lentos em datasets grandes.pg_basebackup) mais arquivamento de WAL permitem recuperação ponto-a-ponto. Esse é o caminho usual para RPO baixos e RTO previsíveis.MongoDB aborda isso via ferramentas e estratégias de snapshot:
mongodump/mongorestore são simples, mas podem ter dificuldades em escala ou com RTO apertado.Para ambos, defina RPO/RTO explicitamente e teste restores regularmente. Um “backup” que nunca foi restaurado na prática é só dados armazenados.
Monitore sintomas que se correlacionam fortemente com dor do usuário:
pg_stat_statements, auto_explain e logs de slow query no Postgres; profiler e logs de slow query no MongoDB.Também acompanhe saúde de armazenamento: progresso de vacuum e bloat no PostgreSQL; eviction de cache, page faults e impacto de builds de índice no MongoDB.
Upgrades maiores do PostgreSQL geralmente envolvem pg_upgrade ou cutovers via replicação lógica; planeje compatibilidade de extensões e janelas de downtime. Upgrades do MongoDB normalmente usam procedimentos rolling com atenção ao Feature Compatibility Version (FCV), builds de índice e (se sharded) balanceamento de chunks.
Na prática, equipes dependem de serviços gerenciados (ex.: Atlas ou Postgres cloud) ou automação via Terraform/Ansible e operadores Kubernetes. A questão chave não é “pode ser automatizado?” — é se sua equipe está pronta para assumir runbooks, sinais on-call e drills de restauração.
Se você está gerando serviços rapidamente (por exemplo, usando Koder.ai para criar múltiplos ambientes), vale padronizar defaults operacionais cedo — estratégia de backup, fluxo de migrations e abordagem de rollback — para que velocidade não vire fragilidade.
Segurança não é só “ligar auth e pronto”. Para ambos, a pergunta prática é quão fácil é aplicar princípio do menor privilégio, rotacionar credenciais e provar (para auditor ou para si) quem acessou quais dados e quando.
Ambos suportam autenticação forte e RBAC, mas se sentem diferentes na prática.
O modelo do PostgreSQL gira em torno de users/roles, grants em schemas/tabelas/views e privilégios SQL previsíveis. Isso tende a mapear bem para papéis separados (aplicação — escrita vs analistas — leitura), muitas vezes via réplicas de leitura dedicadas.
RBAC do MongoDB também é maduro, com privilégios escopados a databases e coleções, além de opções mais finas dependendo do deployment. É um bom encaixe quando equipes já pensam em termos de “serviço X pode read/write collection Y”.
Um padrão útil de menor privilégio em ambos:
Para criptografia em trânsito, trate TLS como obrigatório. Aplique no driver e no servidor e desative versões de protocolo antigas.
Para criptografia em repouso, capacidades variam conforme o modelo de deployment:
Se você tem requisitos de compliance (SOC 2, ISO 27001, HIPAA, PCI), tenha uma história clara para auditoria e retenção: logs de conexão, mudanças DDL, mudanças de privilégios e acesso a tabelas/coleções sensíveis. Governança inclui classificação de dados (o que é PII?), políticas de retenção e processos documentados para resposta a incidentes.
Uma abordagem pragmática é decidir cedo quais eventos devem ser capturados (auth, ações de admin, acesso a datasets específicos) e centralizar logs no seu SIEM.
A maioria dos incidentes reais começa em credenciais e conectividade, não em sintaxe de query.
Feito direito, ambos atendem requisitos estritos de segurança e governança — a diferença é qual modelo casa melhor com padrões de acesso e expectativas de auditoria da sua organização.
Custo raramente é “apenas o banco”. Para MongoDB vs PostgreSQL, o custo total normalmente se divide entre consumo de recursos, overhead de durabilidade e tempo de equipe para manter tudo saudável.
Compute é frequentemente a maior variável. Workloads com muitos joins, reporting complexo ou consistência rígida podem empurrar CPU e memória de forma diferente de leituras/escritas centradas em documentos. Storage depende do tamanho bruto dos dados, footprint de índices e qualquer duplicação introduzida por denormalização.
IOPS e latência viram item quando o working set não cabe em memória ou seus índices são grandes. Altas taxas de escrita amplificam overhead de backup (frequência de snapshots, retenção de WAL/oplog e testes de restauração). Réplicas multiplicam custos: um setup HA de três nós multiplica aproximadamente compute+storage por três, e réplicas cross-region adicionam rede e classes de storage mais caras.
PostgreSQL é tipicamente open-source; deployments MongoDB variam entre builds comunitários e ofertas comerciais. Serviços gerenciados para qualquer um podem transferir custo de tempo de equipe para preço unitário mais alto. Suporte pago pode valer para resposta a incidentes e tuning, mas o ROI depende da experiência e tolerância a risco da sua equipe.
Esforço operacional aparece como folha de pagamento e custo de oportunidade: migrations de esquema, tuning de índices, regressões de query, planejamento de capacidade, on-call e trabalho de compliance. Se sua organização já tem forte experiência e ferramentas em PostgreSQL, trocar de engine pode custar mais do que a fatura de infraestrutura (e vice-versa).
Escolher entre document database vs relational database é menos sobre velocidade bruta e mais sobre como seus dados se comportam sob mudanças, quanto integridade você precisa impor e como sua equipe prefere consultar.
MongoDB tende a sobressair em domínios centrados em documentos onde a “coisa” que você armazena se parece naturalmente com um objeto JSON aninhado e evolui frequentemente:
PostgreSQL é geralmente a escolha mais segura quando integridade relacional e SQL expressivo são requisitos centrais:
JSONBUm corte pragmático é: mantenha entidades autoritativas e com muitas restrições no PostgreSQL, e armazene documentos flexíveis de interação/conteúdo no MongoDB.
Exemplos: pedidos/pagamentos no Postgres; descrições de produto, blobs de personalização, eventos de clickstream ou projeções em cache no MongoDB. Use IDs imutáveis e um padrão de event/outbox para sincronizar mudanças, tratando um sistema como fonte de verdade por entidade.
| Necessidade | Preferir MongoDB | Preferir PostgreSQL |
|---|---|---|
| Formato de dados muda frequentemente | ✅ | ➖ |
| Joins complexos & reporting SQL | ➖ | ✅ |
| Integridade relacional rígida | ➖ | ✅ |
| Armazenar documentos aninhados tal quais | ✅ | ✅ (JSONB) |
| Equipe/ferramentas centradas em SQL | ➖ | ✅ |
Se quiser reduzir churn de decisão enquanto entrega rápido, escolha um default forte e mantenha uma rampa de saída: comece com Postgres para entidades core, reserve MongoDB para domínios claramente em forma de documento e valide com planos de consulta reais.
Para planejar uma troca (ou adicionar um segundo armazenamento), veja /blog/database-migration-checklist.
Comece casando o banco de dados com sua carga de trabalho e equipe:
Se diferentes partes do sistema tiverem necessidades distintas, assuma que uma opção híbrida é válida.
Uma regra prática comum:
Em seguida, valide com suas consultas e padrões de atualização reais.
O MongoDB armazena objetos aninhados de forma natural, então uma única leitura pode retornar um agregado inteiro (por exemplo, um pedido com itens embutidos). Isso reduz round trips e simplifica a iteração inicial.
A troca é duplicação e atualizações mais complexas — especialmente se a mesma informação embutida precisa ser atualizada em muitos documentos.
O PostgreSQL faz respeitar a correção no banco de dados:
CHECK e UNIQUE para evitar estados inválidosIsso reduz a chance de dados inconsistentes entrarem por um caminho de código esquecido e torna regras de negócio concorrentes mais fáceis de raciocinar a longo prazo.
Sim — JSONB é frequentemente o “caminho do meio”. Um padrão comum é:
JSONBIsso mantém a integridade relacional ao mesmo tempo que permite atributos flexíveis.
O PostgreSQL trata joins como ferramenta de primeira classe e costuma ser mais ergonômico para consultas multi-entidade e análise ad-hoc.
O MongoDB frequentemente evita joins incentivando o embedding. Quando você precisa relacionar coleções, $lookup funciona, mas pipelines complexos podem ficar mais difíceis de manter e, em escala, nem sempre são tão previsíveis quanto joins relacionais bem indexados.
Se reporting estilo BI e consultas exploratórias são requisitos centrais, o PostgreSQL normalmente vence porque:
O MongoDB pode gerar relatórios quando eles se alinham aos limites dos documentos, mas análise multi-entidade costuma exigir mais trabalho de pipeline ou ETL.
PostgreSQL é “primeiro por transações” e se destaca em fluxos ACID multi-statement e multi-table (por exemplo, pedido + inventário + lançamentos contábeis).
MongoDB é atômico por padrão ao nível de documento único (ótimo quando você embute) e oferece transações multi-documento quando necessário — tipicamente com mais overhead e limites práticos. Se seus invariantes centrais abrangem muitos registros sob concorrência, o PostgreSQL costuma ser mais simples.
Use suas consultas reais e inspecione planos de execução.
EXPLAIN (ANALYZE, BUFFERS) para detectar scans sequenciais, estimativas ruins e sorts caros.explain() e compare docs examined vs returned.Em ambos os sistemas, índices compostos e seletividade importam, e índices excessivos podem asfixiar as gravações.
Sim — e é comum. Uma divisão pragmática é:
Para manter a sanidade, defina uma fonte única de verdade por entidade, use IDs imutáveis e sincronize via padrões como outbox/events. Se estiver planejando mudanças, a checklist em /blog/database-migration-checklist ajuda a estruturar o trabalho de migração.