Como os LLMs Escolhem Bancos de Dados a partir das Necessidades do Produto — e Como Falham

Por que as pessoas usam LLMs para escolher bancos de dados

Times pedem a LLMs que recomendem um banco de dados pelo mesmo motivo que pedem para redigir e-mails ou resumir especificações: é mais rápido do que começar do zero. Quando você está diante de uma dúzia de opções — PostgreSQL, DynamoDB, MongoDB, Elasticsearch, Redis, ClickHouse e mais — um LLM pode rapidamente produzir uma lista curta, delinear trade-offs e fornecer um ponto de partida “bom o suficiente” para a discussão da equipe.

Usado corretamente, isso também força você a articular requisitos que poderia deixar vagos.

O que “inferir a partir das necessidades do produto” realmente significa

Em termos simples, você descreve o produto (“um marketplace com anúncios e chat”), os dados (“usuários, pedidos, mensagens”) e as restrições (“deve escalar para 1M de usuários, precisa de busca rápida, baixo esforço operacional”). O LLM então mapeia essas necessidades para padrões arquiteturais comuns:

• dados relacionais → SQL
• documentos flexíveis → document store
• analytics → data warehouse colunar
• cache → key-value store
• busca full-text → mecanismo de busca

Esse mapeamento pode ser genuinamente útil no começo, especialmente quando a alternativa é uma página em branco.

Conselho vs. decisão final de arquitetura

Uma recomendação de LLM deve ser tratada como uma hipótese, não um veredito arquitetural. Ela pode ajudar você a:

• nomear as perguntas-chave a responder
• identificar incompatibilidades óbvias cedo
• rascunhar um memorando de decisão que você refinará com a equipe

Mas não pode conhecer o formato real do seu tráfego, crescimento de dados, habilidades do time, restrições de fornecedor ou tolerância operacional sem entradas cuidadosas — e mesmo assim não executará testes em produção.

O que pode dar errado (e como reduzir o risco)

LLMs tendem a falhar de maneiras previsíveis: apoiar-se em regras de bolso populares, adivinhar detalhes faltantes, negligenciar necessidades de transações e consistência, assumir desempenho sem benchmarks e subestimar custo e ônus operacional.

O resto deste artigo detalha esses modos de falha e termina com um checklist prático para validar qualquer conselho de banco de dados vindo de um LLM antes de você se comprometer.

Como os LLMs transformam requisitos em uma escolha de banco de dados

Quando você pede a um LLM para “recomendar um banco de dados”, ele não avalia bancos de dados como um engenheiro faria. Converte seu prompt em requisitos inferidos, dá match com padrões que viu antes e então produz uma resposta que parece uma decisão.

O que ele usa como entrada

As entradas não são apenas detalhes explícitos que você fornece (tráfego, tamanho dos dados, necessidades de consistência). O modelo também usa:

• a redação e estrutura do seu prompt (o que você enfatiza, o que omite)
• sua descrição do produto (mapeia “chat”, “analytics”, “pagamentos”, “IoT”, etc. para arquiteturas típicas)
• restrições declaradas (provedor cloud, orçamento, habilidades do time, prazos)
• “padrões passados” aprendidos nos dados de treinamento (stacks comuns, conselhos populares de blog, emparelhamentos frequentes)

Como muitos prompts são incompletos, o modelo frequentemente preenche lacunas com suposições implícitas — às vezes corretamente, às vezes não.

O que ele produz como saída

A maioria das respostas tem três camadas:

1. uma categoria (SQL vs NoSQL; relacional vs documento vs key-value)
2. engines específicas (PostgreSQL, MySQL, DynamoDB, MongoDB, BigQuery, Redis)
3. um pacote de “boas práticas” (índices, cache, read replicas, sharding, event sourcing)

O resultado pode soar como uma recomendação clara, mas muitas vezes é um resumo estruturado de opções convencionais.

Por que pode soar certo sem ser certo

LLMs generalizam a partir de exemplos; eles não executam sua carga, não inspecionam seu esquema nem benchmarkam queries. Se os dados de treinamento associam fortemente “alta escala” a “NoSQL”, você pode receber essa resposta mesmo quando um SQL bem ajustado seria adequado.

Linguagem confiante é estilo, não medida. A menos que o modelo declare explicitamente suposições (“estou assumindo escritas majoritariamente append-only e que consistência eventual é aceita”), a certeza pode ocultar uma incerteza real: entradas faltantes e afirmações de desempenho não testadas.

O que “necessidades do produto” realmente inclui

Quando as pessoas dizem “escolha um banco de dados com base nas necessidades do produto”, muitas vezes querem muito mais do que “armazenamos usuários e pedidos”. Uma boa escolha de banco de dados reflete o que o produto faz, como deve se comportar sob estresse e o que seu time pode realisticamente operar.

Necessidades funcionais (o que você constrói)

Comece com a forma do produto: as entidades centrais, como elas se relacionam e quais queries alimentam fluxos reais.

Você precisa de filtragem ad-hoc e relatórios por muitos atributos? Depende de joins entre relacionamentos? Está lendo principalmente um registro por ID ou fazendo varreduras por intervalos de tempo? Esses detalhes determinam se tabelas SQL, modelos de documento, padrões wide-column ou índices de busca são mais adequados.

Necessidades não funcionais (como deve se comportar)

Bancos de dados são escolhidos tanto por restrições quanto por recursos:

• metas de latência (p95/p99) para ações-chave do usuário
• requisitos de disponibilidade e recuperação (qual downtime é aceitável?)
• mistura leitura/escrita e picos de tráfego
• taxa de crescimento em volume de dados e tráfego nos próximos 6–24 meses

Um sistema que tolera alguns segundos de atraso é muito diferente de um que deve confirmar um pagamento em menos de 200ms.

Necessidades operacionais (o que você consegue rodar)

Mesmo um modelo de dados “perfeito” falha se as operações não se encaixarem:

• backups e testes de restauração
• migrações e evolução de esquema
• carga de on-call e time (experiência DBA vs generalistas)
• limites de fornecedor: quotas de serviço gerenciado, suporte de regiões, janelas de manutenção

Necessidades regulatórias (o que você deve provar)

Requisitos de compliance podem restringir escolhas rapidamente:

• garantias de retenção e exclusão de dados
• trilhas de auditoria (quem mudou o quê e quando)
• controle de acesso, criptografia e separação de funções

LLMs frequentemente inferem essas necessidades a partir de prompts vagos — ser explícito aqui faz a diferença entre uma recomendação útil e um erro confiante.

Onde o raciocínio do LLM pode divergir da realidade

LLMs frequentemente mapeiam algumas necessidades declaradas (“tempo real”, “escala”, “schema flexível”) para um rótulo familiar (“use NoSQL”, “use Postgres”). Isso pode ser útil para brainstorming, mas o raciocínio deriva quando o modelo trata recursos do banco como se fossem a mesma coisa que requisitos do produto.

Recursos ≠ necessidades do produto

Uma lista de recursos (transações, suporte a JSON, busca full-text, sharding) soa concreta, porém as necessidades do produto descrevem resultados: latência aceitável, regras de correção, auditabilidade, habilidades do time, restrições de migração e orçamento.

Um LLM pode “marcar” recursos e ainda assim perder que o produto precisa de workflows de suporte previsíveis, um ecossistema maduro ou uma opção de hospedagem que sua empresa possa usar.

Checklists ignoram a forma dos dados e das queries

Muitas recomendações assumem que, se um banco consegue armazenar um tipo de dado, ele servirá bem ao produto. A parte difícil é a relação entre dados e queries: como você vai filtrar, unir, ordenar e agregar — a que volumes e com que padrões de atualização.

Dois sistemas que ambos “armazenam eventos de usuário” podem se comportar muito diferente dependendo se você precisa:

• analytics ad-hoc por muitas dimensões
• timelines por usuário com ordenação estrita
• restrições entre entidades (ex.: inventário não pode ficar negativo)

Performance é um detalhe de implementação, não uma promessa

LLMs podem dizer “Banco X é rápido”, mas desempenho depende de escolhas de esquema, índices, particionamento, padrão de queries e concorrência. Pequenas mudanças — como adicionar um índice composto ou evitar varreduras sem limite — podem inverter o resultado. Sem dados e queries representativos, “rápido” é apenas um palpite.

Ajuste operacional pode ser mais importante que capacidade bruta

Mesmo que dois bancos possam tecnicamente atender requisitos, a escolha melhor pode ser aquela que seu time sabe operar de maneira confiável: tempo de restore de backups, monitoramento, carga de on-call, lock-in de fornecedor e previsibilidade de custos.

LLMs tendem a subestimar essas realidades, a menos que você as forneça explicitamente.

Modo de falha 1: Generalizar demais a partir de regras populares

LLMs costumam responder perguntas de banco com “regrinhas” amplamente repetidas, como “NoSQL escala melhor” ou “Postgres faz tudo”. Esses atalhos soam confiantes, mas achatam a realidade dos produtos: o que você armazena, como consulta e o que significa falhar quando algo dá errado.

O atalho clássico: “Use NoSQL para escalar”

Um padrão comum é assumir que, se você menciona crescimento, alto tráfego ou “big data”, a escolha mais segura é NoSQL. O problema é que “escala” raramente é o primeiro problema sem solução. Muitos apps atingem limites por:

• índices ausentes ou queries ineficientes
• retenção de dados sem controle
• estratégia de cache ruim
• recursos subprovisionados

Nesses casos, trocar de banco não resolve a causa raiz — apenas muda as ferramentas.

O que é ignorado: joins, transações e correção estrita

Regras de bolso também encobrem requisitos que influenciam fortemente o fit do banco. Um LLM pode recomendar um document store enquanto ignora que você precisa de:

• atualizações multi-etapa que devem ocorrer todas ou nenhuma (transações)
• correção estrita para saldos, inventário ou reservas (consistência forte)
• queries de relatório que combinam dados entre entidades (joins complexos)

Essas necessidades não descartam automaticamente NoSQL, mas elevam o nível: talvez seja preciso design de esquema cuidadoso, lógica adicional na aplicação ou trade-offs diferentes do que o LLM implicou.

Por que essa falha é cara

Quando uma recomendação se baseia em um slogan em vez de seus padrões de acesso, o risco não é só uma escolha subótima — é a replatformação custosa mais adiante. Migrar dados, reescrever queries e treinar o time costuma acontecer quando você menos pode arcar com downtime.

Trate “regras” como prompts para perguntas, não como respostas. Pergunte o que você está escalando (reads, writes, analytics), o que precisa ser correto e quais queries são inevitáveis.

Modo de falha 2: Entradas faltantes ou ambíguas

LLMs são bons em transformar uma descrição curta em uma escolha confiante — mas não conseguem inventar as restrições faltantes que realmente determinam se uma escolha funciona. Quando as entradas são vagas, a recomendação vira um palpite com aparência de resposta.

A armadilha “tempo real” e “alto tráfego”

Palavras como “tempo real”, “alto tráfego”, “escalável” ou “enterprise-grade” não mapeiam claramente para um banco específico. “Tempo real” pode significar “atualizações em 5 segundos” para um dashboard — ou “fim a fim sub-50ms” para alertas de trading. “Alto tráfego” pode ser 200 requisições por segundo ou 200.000.

Sem números concretos, um LLM pode recorrer a heurísticas populares (ex.: “NoSQL para escala”, “Postgres para tudo”) mesmo quando as necessidades reais apontam para outro caminho.

Números faltantes que mudam a resposta

Se você não fornecer isto, o modelo assumirá silenciosamente:

• QPS de leitura/escrita (pico vs média)
• metas de latência p95/p99 (e se valem para reads, writes ou ambos)
• tamanho do dataset hoje, taxa de crescimento, política de retenção
• tamanho de objetos (linhas largas? blobs grandes?) e cardinalidade de índices

Padrões de query ocultos que você esqueceu de mencionar

As omissões mais danosas muitas vezes são moldadas por queries:

• relatórios e analytics (group-bys, buckets de tempo)
• filtragem/ordenção por muitos campos
• queries ad-hoc para suporte e debugging
• backfills, reprocessamento e buscas “me mostre tudo do usuário X”

Um banco que brilha no acesso key-value pode sofrer quando o produto de repente precisa de filtragem flexível e relatórios confiáveis.

Dica prática: force clarificações antes de recomendar

Trate “seleção de banco” como uma interação em duas etapas: primeiro colecione restrições, depois recomende. Um bom prompt (ou checklist interno) deve exigir números e queries exemplo antes de nomear qualquer engine.

Modo de falha 3: Desalinhamento do modelo de dados

Um erro comum do LLM é recomendar uma categoria de banco (SQL, documento, grafo, wide-column) sem validar se os dados do produto realmente cabem nesse modelo. O resultado é escolher um armazenamento que parece certo para a carga, mas luta contra a estrutura da informação que você precisa representar.

O desalinhamento geralmente começa pelos relacionamentos

LLMs frequentemente ignoram profundidade e cardinalidade de relacionamentos: um-para-muitos vs muitos-para-muitos, propriedade aninhada, entidades compartilhadas e com que frequência usuários atravessam entre elas.

Um banco de documentos pode parecer natural para “perfis de usuário”, mas se o produto constantemente responde a queries entre entidades — “todos os projetos onde qualquer membro mudou de papel nos últimos 7 dias” ou “top 20 tags em todas as equipes filtradas por status de compliance” — você não está mais apenas buscando um documento; está fazendo joins.

Quando esses joins são frequentes, você ou:

• simula joins no código da aplicação (idas e vindas e complexidade extra), ou
• denormaliza fortemente (duplicar dados entre documentos)

O custo oculto da denormalização

Duplicação não é de graça. Aumenta amplificação de escrita, torna atualizações mais difíceis de manter consistentes, complica auditorias e pode criar bugs sutis (“qual cópia é a fonte da verdade?”). LLMs às vezes recomendam denormalização como se fosse uma escolha pontual de modelagem, não um ônus operacional contínuo.

Cheque de sanidade: esquema candidato + queries-chave

Antes de aceitar uma recomendação de LLM, force um teste rápido de realidade:

1. Esboce um esquema candidato (tabelas/coleções/nós) com chaves primárias e os relacionamentos críticos.
2. Escreva 5–10 “queries-chave” que o produto deve suportar (filtros, ordenações, agregações, buscas entre entidades).
3. Pergunte: esse banco expressa essas queries de forma natural e eficiente, sem denormalização heróica ou joins multi-etapa na aplicação?

Se o modelo e as queries não se alinham, a recomendação é ruído — mesmo que soe confiante.

Modo de falha 4: Pontos cegos em transações e consistência

LLMs frequentemente tratam “consistência” como preferência em vez de restrição do produto. Isso leva a recomendações que parecem razoáveis no papel (“use um NoSQL escalável”) mas desmoronam quando ações reais de usuário exigem atualizações atômicas multi-etapa.

A lacuna da atomicidade: atualizações multi-etapa que devem acontecer juntas

Muitos fluxos de produto não são uma única escrita — são várias escritas que devem acontecer todas ou nenhuma.

Pagamento é o exemplo clássico: criar uma cobrança, marcar uma fatura como paga, decrementar saldo da conta e anexar um registro de auditoria. Se qualquer etapa falhar depois da primeira, você criou uma inconsistência que usuários e finanças notarão.

Inventário é similar: reservar estoque, criar um pedido e atualizar disponibilidade. Sem transações, você pode vender em excesso durante picos ou sofrer falhas parciais.

Consistência eventual não é o mesmo que “usuários não vão se importar”

LLMs às vezes equiparam consistência eventual a “a UI pode atualizar depois”. Mas a questão é se a ação de negócio pode tolerar divergência.

Conflitos de reserva mostram por que isso importa: dois usuários tentam reservar o mesmo horário. Se o sistema aceita ambos e “resolve depois”, você não está melhorando a UX — está gerando tickets de suporte e reembolsos.

Semânticas operacionais ausentes: idempotência, retries e exactly-once

Mesmo com um banco que suporte transações, o fluxo ao redor precisa de semânticas claras:

• Chaves de idempotência para que clicar “Pagar” duas vezes não cobre duas vezes.
• Retries seguros sob falhas parciais e timeouts.
• Efeitos exactly-once (ou uma alternativa deliberada como “at-least-once + dedupe”) para eventos, webhooks e jobs em background.

Quando um LLM ignora isso, pode recomendar arquiteturas que exigem trabalho de nível especialista em sistemas distribuídos só para alcançar a correção mínima do produto.

Modo de falha 5: Suposições de desempenho sem testes

LLMs frequentemente recomendam um banco “rápido” como se velocidade fosse propriedade intrínseca do engine. Na prática, desempenho é interação entre seu workload, esquema, forma das queries, índices, hardware e configurações operacionais.

“Rápido” sem contexto de workload

Se você não especifica o que precisa ser rápido — latência p99 para leituras de linha única, analytics em lote, vazão de ingestão ou time-to-first-byte — um LLM pode escolher heurísticas populares.

Dois produtos podem ambos dizer “baixa latência” e ainda ter padrões de acesso opostos: um faz lookups key-value; o outro faz busca + filtragem + ordenação por muitos campos.

Restrições ocultas: índices, amplificação e hot partitions

O conselho de desempenho também desvia quando modelos ignoram:

• Limites e trade-offs de indexação: índices secundários aceleram leituras mas aumentam custo de escrita e armazenamento. Alguns sistemas têm restrições sobre índices compostos, tempo de build de índice ou mudanças de índice online.
• Amplificação de escrita: engines baseadas em LSM transformam “escritas simples” em trabalho de compactação de fundo significativo, importante sob ingestão contínua.
• Partições quentes: um design particionado ainda pode engarrafar se o tráfego se concentrar numa faixa de chaves pequena (ex.: tenant mais novo, data de hoje, item popular).

Comportamento de cache e forma das queries

Um LLM pode assumir que caches irão salvar você, mas caches só ajudam padrões de acesso previsíveis. Queries que varrem grandes intervalos, ordenam por campos não indexados ou usam filtros ad-hoc podem ignorar cache e estressar disco/CPU.

Pequenas mudanças na forma da query (ex.: paginação por OFFSET vs paginação por keyset) podem inverter resultados de desempenho.

Um plano simples de benchmarking (melhor que palpites)

Em vez de confiar em “X é mais rápido que Y”, execute um teste leve moldado ao produto:

1. Escolha 3–5 queries representativas (incluindo os piores filtros/ordenções) e 1–2 padrões de escrita (steady + burst).
2. Use volume de dados realista (pelo menos suficiente para exceder memória; inclua skew e chaves quentes).
3. Meça latência p50/p95/p99 e throughput separadamente para leituras e escritas.
4. Teste variantes de índice (sem índice, índices mínimos, índices “ideais”) e registre overhead de escrita.
5. Rode com concorrência próxima ao pico esperado e monitore CPU, disco, compactação e métricas de lock/transação.

Benchmarks não preveem tudo, mas revelam rapidamente se as suposições de desempenho de um LLM batem com a realidade.

Modo de falha 6: Descuidos operacionais e de custo

LLMs frequentemente otimizam para fit no papel — modelo de dados, padrões de query, buzzwords de escalabilidade — enquanto encobrem o que torna um banco sobrevivível em produção: operações, recuperação de falhas e a fatura real que você pagará mês a mês.

Trabalho oculto: backups, recuperação e migração

Uma recomendação de banco não está completa a menos que responda perguntas básicas: como fazer backups consistentes? Quão rápido você pode restaurar? Qual o plano de disaster recovery entre regiões?

Conselhos de LLM frequentemente pulam esses detalhes, ou assumem que estão “embutidos” sem checar o fine print.

Migração é outra cegueira. Trocar de banco depois pode ser caro e arriscado (mudanças de esquema, dual writes, backfills, reescrita de queries). Se seu produto tende a evoluir, “fácil para começar” não é suficiente — você precisa de um caminho realista de migração.

Observabilidade é parte do produto

Times não precisam apenas do banco — precisam operá-lo.

Se a recomendação ignora slow query logs, métricas, dashboards, hooks de tracing e alertas, você talvez só note problemas quando usuários reclamarem. Ferramentas operacionais variam muito entre ofertaa gerenciadas e self-hosted, e entre fornecedores.

Custo total não é só a tarifa por hora

LLMs tendem a subestimar custo focando em tamanho de instância e esquecendo multiplicadores:

• crescimento de storage e política de retenção
• IOPS/throughput e tarifação de burst
• réplicas para escala de leitura e alta disponibilidade
• tempo on-call, resposta a incidentes e planos de suporte do fornecedor

Combine o banco ao time

Um banco “ideal” que seu time não consegue operar com confiança raramente é o melhor. Recomendações devem alinhar habilidades da equipe, expectativas de suporte e requisitos de compliance — caso contrário o risco operacional vira custo dominante.

Modo de falha 7: Designs multi-banco complicados demais

LLMs às vezes tentam “resolver tudo de uma vez” propondo um stack tipo: Postgres para transações, Redis para cache, Elasticsearch para busca, Kafka + ClickHouse para analytics, mais um banco de grafos “só por precaução”. Isso pode soar impressionante, mas frequentemente é um desenho prematuro que cria mais trabalho que valor — especialmente cedo no produto.

Por que o conselho erra

Designs multi-banco parecem hedge seguro: cada ferramenta é “a melhor” em algo. O custo escondido é que cada datastore adicional acrescenta deploy, monitoramento, backups, migrações, controle de acesso, resposta a incidentes e um novo conjunto de modos de falha.

Times acabam mantendo infraestrutura em vez de entregar features.

Quando a persistência poliglota é justificada

Um segundo (ou terceiro) banco costuma ser justificado quando há uma necessidade clara e medida que o banco primário não resolve sem dor inaceitável, por exemplo:

• requisitos de qualidade/latência de busca que o DB principal não alcança
• workloads analíticos que degradam o desempenho transacional
• padrões de escala que exigem modelos de armazenamento ou indexação diferentes

Se você não consegue nomear a query específica, meta de latência, restrição de custo ou risco operacional que motiva a separação, provavelmente é prematuro.

Armadilhas de consistência e duplicação cross-store

Quando dados vivem em vários lugares, surgem perguntas difíceis: qual store é a fonte da verdade? Como manter registros consistentes durante retries, falhas parciais e backfills?

Dados duplicados também significam bugs duplicados — resultados de busca obsoletos, contagens divergentes e reuniões do tipo “depende de qual dashboard você olha”.

Regra prática de decisão

Comece com um banco generalista que suporte transações e relatórios centrais. Adicione um store especializado só depois de (1) demonstrar que o sistema atual falha contra um requisito e (2) definir um modelo de propriedade para sincronização, consistência e recuperação.

Mantenha a saída de emergência, não a complexidade.

Checklist prático para validar conselhos de banco de dados vindos de LLMs

LLMs podem ser úteis para gerar um rascunho inicial de recomendação, mas trate-o como hipótese. Use o checklist abaixo para validar (ou rejeitar) a sugestão antes de comprometer tempo de engenharia.

1) Clarifique entradas (escreva-as)

Transforme o prompt em requisitos explícitos. Se você não consegue escrever claramente, o modelo provavelmente chutou.

• Qual é a carga central do produto: OLTP, analytics, busca, séries temporais, mensageria?
• Escala esperada: usuários, writes/sec, reads/sec, crescimento de storage, pico vs média.
• Requisitos não funcionais: uptime, multi-região, compliance, orçamento, habilidades do time.

2) Modele os dados e as queries-chave

Rascunhe as entidades reais e relacionamentos (mesmo que seja um esboço). Depois liste seus principais padrões de acesso.

• Quais são as 10 principais leituras e escritas?
• Quais queries devem ser rápidas no pico?
• O que precisa ser indexado, unido, agregado ou buscado?

3) Defina testes de aceitação (critérios de sucesso)

Traduza “deve ser rápido e confiável” em testes mensuráveis.

• metas de latência e throughput (p95/p99) para as queries principais
• requisitos de consistência e transação (o que precisa ser atômico?)
• casos de falha: perda de nó, partições de rede, failover regional, tempo de backup/restore

4) Rode um proof-of-concept leve

Use formatos de dados e mix de queries realistas, não exemplos toy. Carregue um dataset representativo, rode queries sob carga e meça.

Se o LLM propôs múltiplos bancos, teste primeiro a opção mais simples de banco único, depois prove por que dividir é necessário.

Se quiser acelerar este passo, uma abordagem prática é prototipar a fatia do produto que dirige a escolha do banco (duas ou três entidades centrais + endpoints principais + queries mais importantes). Plataformas como Koder.ai podem ajudar aqui: descreva o workflow no chat, gere um app web/backend funcional (frequentemente React + Go + PostgreSQL) e itere rápido enquanto refina esquema, índices e forma das queries. Recursos como modo de planejamento, snapshots e rollback são especialmente úteis quando você experimenta modelos de dados e migrações.

5) Documente a decisão — e os “gatilhos de mudança”

Escreva uma justificativa curta: por que esse banco serve o workload, quais trade-offs você aceitou e quais métricas forçarão uma reavaliação depois (ex.: crescimento sustentado de escrita, novos tipos de query, requisitos multi-região, limites de custo).