Quando o MySQL chega ao limite: o que muda com TiDB X
Migração e modernizaçãoO limite do MySQL raramente aparece em um único número. Ele se revela na curva: o writer satura, o QPS deixa de crescer, p95/p99 sobem, as conexões se esgotam e replication lag aumenta nos picos. Fora da curva, o custo aparece quando aumentar a capacidade exige mover dados e manter recursos ociosos para o pico, enquanto DDL, backups, importações e consultas analíticas disputam recursos com o OLTP. Quando subir a classe da instância ou adicionar outra réplica apenas adia o próximo gargalo, o problema deixa de ser dimensionamento e passa a ser arquitetural. Na Plaid, uma equipe de seis pessoas precisou mover 234 bancos de Aurora MySQL usados por cerca de 100 serviços. A migração exigiu classificar os serviços por criticidade, automatizar o processo e escolher cutovers controlados. Na LINE, operar cerca de 7.000 instâncias MySQL e manter sharding na aplicação revelou outro limite: escalar a frota sem multiplicar o trabalho operacional. Na Micoworks, a decisão não foi substituir tudo: Aurora e Redis permaneceram, enquanto DynamoDB e Redshift foram consolidados para simplificar a operação e acelerar as análises. Essas histórias levam à pergunta central: o que realmente muda com TiDB X, e como saber se essa mudança vale para o seu workload? Vamos relacionar cada sinal a uma decisão de arquitetura: quando tuning ainda resolve, quando a topologia precisa mudar e quando escala horizontal, isolamento de workloads ou análise operacional sobre os mesmos dados justificam avaliar SQL distribuído. Ao final, você terá critérios para reconhecer o próximo passo no seu próprio ambiente.