Airton Lastori

Gerente de Produto · TiDB, powered by PingCAP

Airton Lastori é Gerente de Produto na TiDB, com mais de duas décadas de experiência em bancos de dados, cloud e produtos para o ecossistema MySQL. Trabalha com adoção, migração e experiência de produto no TiDB e já atuou como Gerente de Produto do MySQL na Oracle, professor e consultor técnico.

/ Palestras

O próximo banco de dados não é para você. É para o seu agente de IA

IA, vector search e dados modernos

Agentes de IA não acessam o banco de dados como uma aplicação tradicional. Eles criam schemas, alteram estruturas, abrem ambientes, executam cargas imprevisíveis e precisam retomar tarefas com estado consistente. Quando milhares de agentes fazem isso em paralelo, provisionamento, isolamento, DDL online, observabilidade e controle de custo tornam-se requisitos centrais da plataforma. Vamos entrar em dois cenários que já acontecem em produção. Na Kimi, um prompt vira uma aplicação completa, e o agente precisa receber um banco isolado em menos de um segundo. Na Manus, ciclos de planejamento, execução e verificação precisam sobreviver entre etapas, enquanto branches de banco permitem testar alternativas sem colocar o estado principal em risco. Quando o software também vira operador do banco, quais garantias continuam sendo responsabilidade do DBA e do SRE? Mostraremos como TiDB X lida com esse cenário por meio de SQL compatível com MySQL, elasticidade, isolamento de workloads, mudanças de schema online e processamento transacional, analítico e vetorial sobre um estado consistente. Ao final, você terá critérios para decidir o que consolidar, o que manter em sistemas especializados e quais workloads de agentes justificam uma avaliação técnica.

Quando o MySQL chega ao limite: o que muda com TiDB X

Migração e modernização

O 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.

/ Participe

Te esperamos em São Paulo.

Vagas limitadas. Reserve a sua no Sympla e faça parte da MySQL BR Conf 2026.

Garanta seu ingresso

Ingressos disponíveis no Sympla.