Existe um ponto em que uma única máquina não dá conta: a tabela é grande demais, as escritas são muitas demais. Quando você chega lá, precisa dividir os dados. Particionamento e sharding são as duas formas de fazer isso — e confundi-los, ou escolher mal a chave, é um erro que assombra sistemas em produção por anos.
Partição vertical vs horizontal
Dividir uma tabela pode ser feito em dois sentidos:
- Partição vertical — separa colunas. Colunas pouco usadas ou pesadas (um blob, um texto longo) vão para uma tabela à parte, deixando a principal enxuta e rápida de ler.
- Partição horizontal — separa linhas. Você divide as linhas em grupos segundo um critério, por exemplo pedidos de 2024 numa partição e de 2025 em outra.
A partição horizontal é a mais relevante para escala, porque é a base do sharding.
Sharding: partição horizontal entre máquinas
Sharding é particionamento horizontal levado para fora de uma única máquina: cada fatia (shard) vive em um servidor diferente. Em vez de um banco gigante, você tem vários bancos menores, cada um responsável por um pedaço dos dados. Assim, capacidade de armazenamento e de processamento crescem somando máquinas.
roteador (decide o shard pela chave)
/ | \
+---------+ +---------+ +---------+
| Shard A | | Shard B | | Shard C |
| ids | | ids | | ids |
| 0–999 | |1000–1999| |2000–2999|
+---------+ +---------+ +---------+A chave de partição e o problema dos hotspots
A decisão mais crítica é a chave de partição: a coluna que decide em qual shard cada linha mora. Uma boa chave distribui as linhas e a carga uniformemente. Uma má chave cria hotspots — um shard sobrecarregado enquanto os outros ficam ociosos.
Exemplo clássico: shardear por data faz o shard "do mês atual" receber todas as escritas, enquanto os meses antigos dormem. Já uma chave como o id do cliente costuma distribuir melhor, desde que nenhum cliente seja desproporcionalmente grande.
O custo: queries e joins entre shards
Sharding não é grátis. Se a consulta filtra pela chave de partição, o roteador vai direto ao shard certo — ótimo. Mas uma consulta que precisa varrer todos os shards (um COUNT global, ou um filtro por outra coluna) tem que perguntar a cada máquina e juntar os resultados — lento e complexo. Pior ainda são JOINs entre tabelas que vivem em shards diferentes: muitas vezes inviáveis, forçando você a desnormalizar ou a juntar na aplicação.
Rebalanceamento
Os dados crescem de forma desigual, e cedo ou tarde você precisa mover fatias entre shards ou adicionar máquinas — o rebalanceamento. Mover dados sem parar o sistema é difícil; por isso técnicas como consistent hashing existem, para minimizar quanto dado se desloca quando um shard entra ou sai.
Sharding não é replicação
São frequentemente confundidos, mas resolvem problemas diferentes:
| Aspecto | Replicação | Sharding |
|---|---|---|
| O que faz | Copia os mesmos dados em várias máquinas | Divide dados distintos entre máquinas |
| Resolve | Disponibilidade e leitura | Volume e escrita |
| Cada nó tem | Tudo (cópia completa) | Uma fatia |
| Se um nó cai | Outro assume (dado existe em outro lugar) | Aquela fatia fica indisponível |
Na prática combinam-se: cada shard é replicado para ter tolerância a falhas.
Sharding troca um problema de escala por um problema de design: a partir do momento em que você divide os dados entre máquinas, a escolha da chave de partição vira a decisão que define o desempenho de tudo. Errar nela é caríssimo de corrigir depois.
É comum em entrevista pedirem para você escolher uma chave de partição para um cenário e explicar como evitaria hotspots — e diferenciar sharding de replicação. No dia a dia isso aparece quando um banco monolítico atinge o limite e o time precisa decidir como escalar sem se prender numa chave ruim.
Conclusão
Particionamento divide dados — vertical por colunas, horizontal por linhas — e o sharding estende a divisão horizontal entre máquinas para escalar volume e escrita. A chave de partição governa o equilíbrio da carga e o custo das consultas; replicação é coisa diferente, voltada à disponibilidade. Entender esses trade-offs é o que permite escalar um banco sem criar gargalos novos.
There's a point where a single machine can't cope: the table is too big, the writes are too many. When you get there, you need to split the data. Partitioning and sharding are the two ways to do that — and confusing them, or picking the wrong key, is a mistake that haunts production systems for years.
Vertical vs horizontal partitioning
Splitting a table can be done in two directions:
- Vertical partitioning — separates columns. Rarely used or heavy columns (a blob, a long text) go to a separate table, leaving the main one lean and fast to read.
- Horizontal partitioning — separates rows. You split the rows into groups by some criterion, for example 2024 orders in one partition and 2025 in another.
Horizontal partitioning is the most relevant for scale, because it's the basis of sharding.
Sharding: horizontal partitioning across machines
Sharding is horizontal partitioning taken beyond a single machine: each slice (shard) lives on a different server. Instead of one giant database, you have several smaller ones, each responsible for a piece of the data. That way, storage and processing capacity grow by adding machines.
router (picks the shard by key)
/ | \
+---------+ +---------+ +---------+
| Shard A | | Shard B | | Shard C |
| ids | | ids | | ids |
| 0–999 | |1000–1999| |2000–2999|
+---------+ +---------+ +---------+The partition key and the hotspot problem
The most critical decision is the partition key: the column that decides which shard each row lives on. A good key spreads rows and load evenly. A bad key creates hotspots — one overloaded shard while the others sit idle.
Classic example: sharding by date makes the "current month" shard receive all the writes while the old months sleep. A key like customer id usually distributes better, as long as no customer is disproportionately large.
The cost: cross-shard queries and joins
Sharding isn't free. If the query filters by the partition key, the router goes straight to the right shard — great. But a query that has to scan all shards (a global COUNT, or a filter on another column) has to ask every machine and merge the results — slow and complex. Even worse are JOINs between tables that live on different shards: often unworkable, forcing you to denormalize or join in the application.
Rebalancing
Data grows unevenly, and sooner or later you need to move slices between shards or add machines — rebalancing. Moving data without stopping the system is hard; that's why techniques like consistent hashing exist, to minimize how much data moves when a shard joins or leaves.
Sharding is not replication
They're often confused, but they solve different problems:
| Aspect | Replication | Sharding |
|---|---|---|
| What it does | Copies the same data onto several machines | Splits distinct data across machines |
| Solves | Availability and reads | Volume and writes |
| Each node has | Everything (full copy) | One slice |
| If a node goes down | Another takes over (data exists elsewhere) | That slice becomes unavailable |
In practice they're combined: each shard is replicated for fault tolerance.
Sharding swaps a scale problem for a design problem: from the moment you split data across machines, the choice of partition key becomes the decision that defines the performance of everything. Getting it wrong is very expensive to fix later.
In interviews they often ask you to pick a partition key for a scenario and explain how you'd avoid hotspots — and to tell sharding apart from replication. Day to day, this shows up when a monolithic database hits its limit and the team has to decide how to scale without locking themselves into a bad key.
Conclusion
Partitioning divides data — vertically by columns, horizontally by rows — and sharding extends the horizontal split across machines to scale volume and writes. The partition key governs load balance and query cost; replication is a different thing, aimed at availability. Understanding these trade-offs is what lets you scale a database without creating new bottlenecks.