# Read Replicas vs Sharding: Escolha a Estrategia Certa > Read Replicas e Sharding são estratégias de escalabilidade de banco de dados com propósitos distintos. Read replicas aumentam a capacidade de leitura ao duplicar dados em servidores secundários, enquanto sharding particiona dados em múltiplos servidores para distribuir carga de escrita e leitura. A escolha entre replicas e sharding depende do gargalo predominante: leituras intensas favorecem replicas; crescimento de dados e escrita exigem sharding. *Blog Sem Juízo · Destaques · 03 de setembro de 2026 · Zeca Maranhão* Read replicas e sharding sao estrategias de escalabilidade distintas. Replicas aumentam leituras; sharding distribui dados. Descubra qual atende seu cenario. Read replicas e sharding aparecem com frequencia em debates de arquitetura, mas resolvem dores distintas. Um copia o livro para varios leitores; o outro racha o livro em capitulos separados. Antes de escolher, vale entender o que cada tecnica entrega e onde ela quebra. Read replicas sao copias do banco principal que atendem consultas de leitura. Sharding divide o conjunto de dados em partes menores, distribuindo-as por servidores independentes. A decisao entre um e outro nao e hierarquica, e contextual: depende do gargalo atual, do tamanho dos dados e da complexidade que a equipe consegue sustentar. ## Custo Replicas de leitura costumam ser mais baratas de operar. Voce adiciona um servidor, configura a replicacao e o banco cuida da sincronizacao. O custo principal esta em infraestrutura e em possiveis atrasos de replicacao, que em geral ficam na casa dos milissegundos. Sharding exige planejamento e, muitas vezes, mudanca na aplicacao. A distribuicao dos dados por chave precisa ser definida antes do crescimento, e rebalancear um shard depois que ele enche e uma operacao delicada. O custo inicial e maior, tanto em engenharia quanto em operacao. ## Facilidade de implementacao Implementar read replicas e simples. A maioria dos bancos relacionais, como PostgreSQL e MySQL, oferece replicacao nativa com configuracao relativamente curta. O aplicativo precisa apenas separar consultas de leitura e escrita, geralmente via um proxy ou uma configuracao de conexao. Sharding adiciona complexidade em varias camadas. Alem da particao dos dados, queries que cruzam shards precisam ser repensadas, transacoes distribuidas entram em cena e a consistencia vira um desafio. Sem ferramentas prontas, o time precisa construir logica de roteamento propria. ## Performance Read replicas melhoram a vazao de leituras. Se o banco primario esta saturado com consultas de leitura, replicas distribuem essa carga. Mas o volume total de dados continua limitado ao tamanho de um servidor. Quando o conjunto de dados excede a capacidade de armazenamento ou a CPU de uma maquina, replicas nao resolvem. Sharding endereca exatamente esse limite. Ao dividir os dados, cada servidor guarda apenas uma fracao do total, o que reduz o impacto de scans e permite escalar horizontalmente. A contrapartida: queries que precisam de dados de varios shards se tornam mais lentas ou inviaveis. | Criterio | Read Replicas | Sharding | |---|---|---| | Custo inicial | Baixo | Alto | | Complexidade | Baixa | Alta | | Escala de dados | Limitada | Ilimitada na pratica | | Consistencia | Eventual (atraso) | Depende da chave | | Tipo de carga | Leitura intensa | Volume total alto | ## Consistencia Read replicas introduzem replicacao assincrona na maioria dos setups. Isso significa que um dado recem-escrito pode nao aparecer imediatamente numa replica. Para aplicacoes que toleram leituras ligeiramente defasadas, o impacto e aceitavel. Para sistemas financeiros ou de inventario em tempo real, pode ser um problema. Sharding nao muda a consistencia dentro de cada shard. Se a chave de particao for bem escolhida, cada transacao afeta um unico shard e mantem as propriedades ACID. O problema aparece quando uma transacao envolve multiplos shards: ai, a consistencia distribuida exige protocolos como two-phase commit, que adicionam latencia e complexidade. ## Quando usar cada um Read replicas sao a escolha natural quando o banco primario esta sobrecarregado por consultas de leitura, mas o volume de dados ainda cabe num servidor. Um dashboard com muitos acessos, um relatorio pesado ou uma API publica de consulta sao cenarios classicos. Sharding entra quando o conjunto de dados cresce alem da capacidade de uma maquina, ou quando a carga de escrita ultrapassa o limite de um unico servidor. Redes sociais, sistemas de mensagens e plataformas de e-commerce com alto volume de pedidos costumam chegar a esse ponto. ## Veredito Para quem busca aliviar a carga de leitura sem reescrever a aplicacao, read replicas sao o caminho. Para quem precisa escalar alem do limite de um servidor, sharding e inevitavel. Muitas arquiteturas maduras combinam os dois: sharding para distribuir os dados e replicas dentro de cada shard para garantir disponibilidade e performance de leitura. ## FAQ ### Read replicas e sharding sao mutuamente exclusivos? Nao. E comum usar replicas dentro de cada shard para garantir alta disponibilidade e distribuir leituras. A escolha nao e entre um e outro, mas sobre qual aplicar primeiro, conforme o gargalo atual. ### Quando usar read replicas em vez de sharding? Quando o banco principal esta sobrecarregado por leituras, mas o volume total de dados ainda cabe em um unico servidor. Replicas sao mais simples e baratas de implementar. ### Sharding resolve problemas de performance de leitura? Indiretamente. Ao reduzir o volume de dados por servidor, consultas em um unico shard ficam mais rapidas. Mas leituras que cruzam shards podem ficar mais lentas que num banco unico. ### Read replicas melhoram a performance de escrita? Nao. Replicas so aliviam consultas de leitura. Toda escrita continua indo para o primario, e replicas adicionam custo de sincronizacao, o que pode ate aumentar levemente a latencia de confirmacao. ### Quais bancos suportam read replicas nativamente? PostgreSQL, MySQL, MongoDB e a maioria dos bancos gerenciados em nuvem, como RDS e Cloud SQL, oferecem replicas de leitura com configuracao simples. Sharding exige mais planejamento, mas bancos como MongoDB e Cassandra tem suporte integrado. ### Sharding e dificil de reverter? Sim. Uma vez que os dados estao distribuidos, juntar tudo de volta em um unico banco exige migracao completa. Por isso, a decisao de sharding precisa considerar o crescimento de longo prazo e a possibilidade de mudanca de chave. --- Fonte (canonical): https://blogsemjuizo.com.br/destaques/read-replicas-vs-sharding-escolha-a-estrategia-certa/