Aja rápido sem quebrar as coisas: escalando bancos de dados para a era da IA — PlanetScale

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Move Fast and Don’t Break Things: Scaling Databases for the AI Era — PlanetScale · Canal: AI Engineer · 18:45 · Assistir no YouTube

Tópicos: Agentes de IA, Dados, bancos de dados e embeddings, Ferramentas de desenvolvimento com IA, Infraestrutura e hardware de IA

Resumo

Ben, da PlanetScale, apresenta princípios para criar sistemas que suportem crescimento rápido sem comprometer a disponibilidade. Ele destaca isolamento, redundância, sharding, back pressure e desacoplamento como práticas importantes para escalar bancos de dados e outros componentes da infraestrutura. Em seguida, explica como interfaces simples, fluxos de trabalho semelhantes ao Git e ferramentas de automação podem permitir que agentes ajudem a operar bancos de dados com segurança. A experiência do desenvolvedor, segundo ele, também cria boas bases para que agentes trabalhem com a infraestrutura de forma confiável.

Pontos-chave

Projetar componentes isolados ajuda a evitar que uma falha em uma parte da infraestrutura afete o sistema inteiro.
Redundância com nós primários e réplicas permite que bancos de dados se recuperem de falhas.
Sharding distribui dados e consultas entre vários servidores para atender a cargas maiores.
Back pressure limita ou rejeita parte do tráfego quando os recursos estão sobrecarregados, evitando uma falha total.
Desacoplar serviços permite escalar seus recursos de forma independente e reduz contenção.
Arquivos de configuração simples, como um vSchema em JSON, tornam tarefas complexas mais acessíveis a agentes.
Orçamentos de recursos e degradação gradual ajudam a proteger o banco de dados diante de picos de tráfego.
Ramificações de esquema e deploy requests permitem testar e aplicar mudanças no banco de dados em um fluxo semelhante ao Git.
APIs, CLI e MCP podem dar aos agentes meios para automatizar operações, mantendo humanos no processo de revisão.

Capítulos

Início	Capítulo	Resumo
00:12	Velocidade de desenvolvimento e confiabilidade	Ben apresenta a ideia de entregar funcionalidades rapidamente sem comprometer a disponibilidade da infraestrutura.
02:21	Princípios de sistemas confiáveis	A palestra introduz isolamento e redundância como bases para limitar o impacto de falhas.
05:56	Escalar bancos de dados e serviços	O palestrante aborda sharding, back pressure e desacoplamento para atender a cargas maiores.
11:03	Agentes de IA na operação da infraestrutura	Ben discute os riscos de permitir que agentes alterem bancos de dados e apresenta o Vitess e o vSchema como interfaces para sharding.
14:07	Controle de tráfego e mudanças no esquema	A palestra apresenta orçamentos de recursos, degradação gradual e um fluxo de ramificações e deploy requests para mudanças no banco.
17:12	Experiência do desenvolvedor e automação segura	O encerramento destaca o papel de APIs, CLI e MCP para ajudar agentes a operar bancos de dados com segurança, com revisão humana quando necessário.

Citações

Na minha opinião, podemos alcançar as duas coisas. — 00:44

Quero manter saudáveis os usuários existentes ou parte do tráfego, degradando gradualmente o restante. — 09:01

É muito melhor do que deixar toda a aplicação fora do ar para todos os usuários. — 15:41

Quando você se concentra na experiência do desenvolvedor, também acaba criando boas bases para a IA trabalhar com um banco de dados com segurança e confiabilidade. — 18:14

Conceitos e entidades

PlanetScale (empresa): Empresa de bancos de dados que atende organizações com aplicações em rápido crescimento.
Ben (pessoa): Palestrante da PlanetScale que apresenta práticas para escalar bancos de dados com confiabilidade.
Cursor (empresa): Empresa citada como cliente da PlanetScale.
Vitess (repo): Projeto open source usado para sharding de bancos de dados MySQL.
VTGate (ferramenta): Proxy do Vitess que interpreta consultas MySQL e as encaminha aos shards apropriados.
vSchema (conceito): Arquivo JSON usado para configurar como dados e tabelas são distribuídos entre shards no Vitess.
Traffic Control (ferramenta): Sistema descrito pela PlanetScale para categorizar tráfego e definir orçamentos de recursos para o banco de dados.
sharding (conceito): Técnica que distribui dados e consultas entre vários servidores para escalar um banco de dados.
back pressure (conceito): Prática de limitar ou rejeitar solicitações quando um sistema ultrapassa determinados limites de recursos.
MCP (conceito): Interface mencionada como uma das formas de disponibilizar recursos de banco de dados para agentes.
CLI (ferramenta): Interface de linha de comando que pode ser usada por agentes para automatizar operações no banco de dados.
GitHub (empresa): Empresa citada como exemplo de serviço que enfrentou aumentos de tráfego associados a agentes de IA.

Tradução completa (pt-BR)

00:12 Olá, pessoal, como vão? Espero que estejam tendo um bom último dia do AI Engineer. Hoje vou falar sobre como avançar rápido sem quebrar as coisas. A expressão “avançar rápido e quebrar as coisas” provavelmente já é conhecida por vocês. Ela vem dos primórdios da cultura de engenharia do Facebook, certo? A ideia era poder avançar e lançar rápido, sem ficar limitado por bancos de dados que caem ou por recursos que quebram, porque a prioridade era que havia muito valor em lançar rapidamente. E isso foi há 20

00:44 anos, certo? Antes de termos AI agents escrevendo código para nós, lançando coisas e fazendo deploy em nosso nome. Então, se há algo, essa ideia é mais verdadeira do que nunca. Mas, na minha opinião, podemos alcançar as duas coisas, certo? Quero poder lançar rápido, criar ótimos recursos e disponibilizá-los aos meus clientes, mas também não quero quebrar os bancos de dados, a infraestrutura nem os servidores de aplicação que fazem tudo funcionar. E provavelmente todos já vimos algo parecido com isto. Não estou apontando para nenhuma empresa em particular. Há várias empresas que, devido ao tipo de

01:16 escala insana que vimos nos últimos seis meses, um ano, dois anos, certo? Em que o número de usuários ativos diários dobrou, triplicou, aumentou 10x, 100x — muito disso impulsionado pela demanda de AI agents — e a infraestrutura tem dificuldade para acompanhar. Parte disso acontece simplesmente porque é um problema muito difícil, certo? Não pretendo apontar para ninguém em particular. É difícil escalar para dezenas ou centenas de milhões de usuários. Mas queremos ter ótimos produtos que escalem bem para muitos usuários e páginas de status

01:47 que se pareçam um pouco mais com esta, certo? Três ou quatro noves de disponibilidade, talvez cinco noves, com bancos de dados e aplicações saudáveis e, no fim das contas, usuários felizes, certo? Essa é a ideia por trás do que quero abordar, algo um pouco diferente da maioria das palestras a que vocês provavelmente foram. Muitas delas provavelmente falam de inference ou, especificamente, de como fazer coisas com agents ou diferentes tipos de automação. Esta é mais uma palestra sobre infraestrutura, mas sobre como fazer isso e lançar rápido, tanto diante da demanda de AI agents quanto usando AI agents

02:21 para otimizar e tornar mais fluidos todos esses processos. Quero falar sobre três partes disso. Primeiro: como construir sistemas que não fiquem caindo o tempo todo, independentemente do número de usuários? Depois, conectando isso: se vocês forem criar o próximo aplicativo de sucesso, que vai escalar para milhões de pessoas, como escalá-lo usando esses mesmos princípios? E, por fim, como podemos pegar essas duas coisas e deixar que AI agents façam isso por nós ou, pelo menos, trabalhem em parte

02:51 com eles para fazer isso? Também deveria me apresentar um pouco e explicar por que estou falando sobre esse assunto. Sou Ben, da PlanetScale, e trabalhamos com bancos de dados. Essa é a nossa especialidade, e trabalhamos com muitas dessas empresas de IA que estão escalando extremamente rápido. Trabalhamos, por exemplo, com a Cursor e fornecemos bancos de dados para ela. Por isso, levamos esse assunto muito a sério como empresa. Como escalar e dar suporte a empresas que têm milhões de usuários em suas plataformas? Parte do que vou abordar vem de um artigo que

03:23 publicamos no ano passado sobre a nossa filosofia de operação de bancos de dados. Recomendo que pesquisem no Google e leiam o artigo. Vamos passar por alguns desses princípios. O primeiro, e um dos mais importantes, é o isolamento, certo? Ao operar infraestrutura, uma das coisas que vocês precisam garantir é ter uma configuração em que, se algo falhar, isso não derrube o sistema inteiro; cada componente deve ser muito bem isolado. O que mostro aqui é o plano de dados. Basicamente, isso significa: onde estão os bancos de dados? Onde ficam os dados mais críticos de que vocês precisam para que os usuários façam login e interajam com a aplicação? Mas há muitos outros componentes, certo? Há os planos de controle, os pipelines de observabilidade, talvez os frameworks de análise, os aplicativos, os MCPs e todos esses componentes diferentes que podem falhar. Na verdade, supondo que vocês usem uma boa plataforma de banco de dados, o banco de dados provavelmente terá pouca chance de falhar, mas os outros componentes, que vocês lançam e implantam com mais frequência, têm mais chances de falhar. Então, queremos garantir que projetamos tudo de modo que, se eu fizer um deploy ruim no plano de controle e derrubá-lo,

03:53 nada mais seja afetado e ainda seja possível acessar o banco de dados, certo? E qualquer coisa no meu plano de dados. Esse é um dos princípios fundamentais que levamos muito a sério. Outra coisa é a redundância. Se algum de vocês já trabalhou com bancos de dados, provavelmente viu um diagrama parecido com este. Coisas semelhantes também se aplicam à infraestrutura dos aplicativos e a outras infraestruturas. Mas, no caso dos servidores de aplicação, geralmente é um pouco mais fácil resolver a redundância porque

04:25 a carga de trabalho não tem estado, certo? Há muitos workers do Cloudflare com escalabilidade automática, funções da Vercel e AWS Lambda que podem escalar e ter redundância com muita facilidade, porque não armazenam estado. Mas, no mundo dos bancos de dados, é preciso armazenar o estado de forma confiável. Não se pode perder um único byte de dados. Então, como fazer isso? Uma abordagem muito comum, que custa mais e é mais complexa, mas é a maneira de escalar com confiabilidade, é ter um nó primário. É para ele que vai a maior parte do tráfego. Mas sempre há servidores de réplica ou servidores seguidores

04:55 de prontidão em diferentes data centers ou diferentes zonas de disponibilidade, preparados para assumir porque, na verdade, os servidores às vezes falham. Em pequena escala, quando vocês têm um aplicativo com cem usuários e um servidor de banco de dados, talvez só enfrentem uma falha a cada dois anos. Mas, em grande escala, com milhares de servidores, uma falha que acontece uma ou duas vezes por ano passa a acontecer semanal ou mensalmente. Portanto, é preciso ter sistemas preparados para lidar muito bem com isso. Certo. Falamos sobre quais são os princípios para escalar com confiabilidade ou para ter sistemas confiáveis. Mas a questão é que poderíamos escrever um livro inteiro sobre o que acabei de explicar, certo? Há muito mais, e há pessoas que dedicam toda a carreira a esse assunto. Então, estamos passando por isso um pouco rápido, mas esses princípios se aplicam, seja qual for o ponto em que vocês estejam neste gráfico de crescimento de usuários, certo? Vocês podem ter cem usuários e, nesse caso, ainda é bom ter redundância, isolamento e tolerância a falhas, mesmo para esse

05:25 grupo menor de usuários. E vocês vão querer aplicar esses mesmos princípios quando chegarem até aqui. Não sei se dá para ver bem essa linha, mas ela representa milhões de usuários ativos diários. Mas chega um ponto em que é preciso incorporar tecnologias diferentes para escalar de forma eficiente e eficaz. Então, vamos falar por alguns minutos sobre como escalar esses sistemas. E provavelmente a parte que mais empolga vocês é a dos AI agents, a que chegaremos no final. Uma das coisas principais, e algo que fazemos muito na PlanetScale, é o sharding. Eu só

05:56 …

06:27 um grupo menor de usuários. E você quer aplicar esses mesmos princípios quando chega até aqui em cima. Não sei se dá para ver muito bem essa linha, mas estamos falando de milhões de usuários ativos diariamente. Mas chega um ponto em que você realmente precisa incorporar tecnologias diferentes para escalar de forma eficiente e eficaz. Então, vamos falar por alguns minutos sobre como escalamos esses sistemas. E provavelmente a parte que mais empolga vocês é a dos agents de IA, a que vamos chegar no final. Então, uma das coisas principais — e fazemos muito isso na PlanetScale — é o particionamento horizontal (sharding). Eu só

06:58 Percebi que o cursor do mouse está na tela, então vou tirá-lo daqui. Vamos ver se ele desaparece depois de um tempo. Então, sharding de banco de dados. O que é isso? Em vez de depender de um único nó, que funciona bem quando você tem 10 gigabytes de dados, mas não funciona tão bem quando tem 10 terabytes, 100 terabytes ou um petabyte de dados, o que você precisa começar a fazer? Bem, você precisa distribuir seus dados e consultas entre vários servidores. E é isso que são todos esses shards aqui embaixo. Normalmente, você coloca

07:30 algum tipo de proxy entre eles — e depois vamos falar mais sobre o que significa VTGate — que gerencia de forma inteligente a distribuição de todas as solicitações dos usuários, ou solicitações de consulta, entre esses servidores. E é exatamente isso que fazemos bastante para alguns clientes de grande porte na PlanetScale. Fazemos sharding com Vitess para MySQL e Niki para Postgres. E essa é uma maneira bem fundamental de fazer sharding. Mas outra coisa é que você não usa sharding isoladamente. Se olharmos para isso e, por exemplo, observarmos o shard A, dentro dessa caixa, na verdade

08:00 você vai querer um sistema redundante. Então, teria um nó primário e várias réplicas ali. Se um desses servidores falhar, esse shard pode se recuperar sozinho e voltar a ficar online muito rapidamente se houver algum problema. Essa é uma das maneiras que vemos e provavelmente a forma mais comum e eficiente de escalar bancos de dados. Mas, na verdade, o mesmo princípio de distribuir consultas e dados entre muitos servidores, muitos nós e muitos drives se aplica a várias outras áreas da stack que você está construindo. Controle de fluxo de retorno. Então, esse é outro aspecto

08:31 que, de certa forma, faz parte tanto da escalabilidade quanto da confiabilidade. O que queremos dizer é que há muitos sistemas, como MySQL, Postgres e SQLite, bancos de dados muito populares que as pessoas usam, que não lidam bem com sobrecarga. Quando recebem consultas demais, usam CPU demais ou, em muitos casos, ficam sem RAM para o cache, se você não tomar bastante cuidado, eles simplesmente travam. Aí, seu servidor fica fora do ar, todos os seus usuários são afetados e não conseguem usar o serviço

09:01 que o banco de dados sustenta. Controle de fluxo de retorno é projetar um sistema capaz de reagir e dizer: quando detecto que ultrapassei determinado limite de recursos, posso reagir e começar a falhar solicitações, rejeitar consultas, rejeitar conexões, certo? Assim, consigo manter saudáveis os usuários existentes ou parte do tráfego, enquanto degrado de forma controlada parte do outro tráfego. E o restante da sua stack precisa ser construído para dar suporte a isso. Esse é um princípio que se aplica a muitas áreas da stack, mas, no banco de dados, é

09:32 possivelmente o mais importante. Vamos ver. O controle remoto. Aí está. E o último componente sobre o qual quero falar antes de passarmos a como fazer tudo isso com IA é o desacoplamento. Há muita gente com quem você conversa que, quando o assunto são bancos de dados, vai argumentar que provavelmente você deveria combinar todos os seus serviços em um só, porque isso oferece algumas conveniências: seu banco de dados Postgres, suas cargas de trabalho OLTP combinadas com o que você faz para analytics, seu sistema de filas e tarefas e seu cache. Há

10:03 conveniência, e algumas tecnologias tentam fazer isso, colocando tudo em um só lugar. Mas, além de acrescentar muita complexidade, isso também quebra alguns dos princípios fundamentais de que falamos antes, como o isolamento de falhas, certo? Se um serviço ficar fora do ar, isso significa que tudo ficará fora do ar. E você também precisa lidar com a contenção de recursos. Se, de repente, houver um pico de tarefas na fila e você precisar escalar suas filas, mas talvez nada mais precise ser escalado, seria bom poder escalar de forma independente os recursos computacionais alocados a cada uma dessas partes do serviço de

10:33 backend que sustenta seu aplicativo favorito. Certo? Então, esta não é uma lista completa. O que vimos até agora? Falamos de sharding. Falamos de controle de fluxo de retorno. E agora estamos falando de desacoplamento. Há muitos outros aspectos da escalabilidade. E, mais uma vez, você poderia passar a carreira inteira se tornando especialista em escalabilidade. Mas muito do que pensamos bastante na PlanetScale é isso, porque nossos clientes dependem de nós para ter confiabilidade e escalar. Então, finalmente, vamos à última parte

11:03 disso. Digamos que tenhamos todos esses princípios em vigor. Fazemos as coisas com confiabilidade e temos tolerância a falhas. Fazemos as coisas de forma altamente escalável. Mas, hoje em dia, em muitas organizações — e conversamos com muitas pessoas que sentem isso tanto em empresas pequenas quanto em organizações muito grandes —, como podemos permitir que agents tenham, em parte ou totalmente, controle sobre o que é possivelmente a infraestrutura mais importante da sua empresa, certo? Os bancos de dados, as filas, as coisas que sustentam todas as outras camadas da sua

11:34 stack. E isso pode ser um pouco intimidante, porque hoje em dia é praticamente padrão escrever código com IA, certo? Em alguns casos, as pessoas já nem escrevem mais nenhuma linha de código, certo? A IA escreve todo o seu código e revisa todo o seu código. E você fica apenas orientando esses agents. Mas é bem diferente dizer: “Agora também vou dar aos meus agents a capacidade de fazer deploy de alterações no banco de dados, mudar a configuração ou fazer sharding do meu banco de dados”, certo? Porque, se algo der errado,

12:04 geralmente não é tão simples quanto clicar em um botão para reverter, certo? Isso derruba todo o seu aplicativo, e todos os usuários percebem. Então, queremos fazer isso de forma eficaz e segura. Vou retomar alguns dos conceitos de que falei antes e pensar em como usar agents para resolver isso. Voltando ao sharding, vou falar mais especificamente sobre o Vitess, um projeto open source. Operamos bancos de dados Vitess para nossos clientes, e ele funciona com MySQL para fazer sharding. Então

12:34 o que vocês podem ver aqui é que todos aqueles shards lá embaixo seriam bancos de dados MySQL, e o VTGate é o proxy: um proxy inteligente que recebe as consultas MySQL, analisa-as, identifica a qual shard elas devem ser encaminhadas e direciona todas essas solicitações de forma bastante sofisticada. O software é relativamente complexo, mas a interface que apresentamos para especificar como você quer distribuir seus dados e consultas entre os shards é, na verdade, bem simples. É o que chamamos de vSchema e consiste literalmente em um arquivo JSON no qual você diz: “Esta é a coluna pela qual quero fazer o sharding” e

13:05 “esta é a maneira como quero fazer o sharding”. Você pode especificar que determinadas tabelas fiquem em determinados shards e ter bastante controle sobre onde e como as coisas são configuradas. E o ótimo é que, como todos sabemos, agents de IA são excelentes para trabalhar com coisas como arquivos de texto e arquivos JSON. Então, você pode dizer ao seu agent: “Ei, estou tendo dificuldades com a escalabilidade do meu banco de dados. Aqui está meu schema. Quero que você proponha e me ajude a criar um protótipo de um bom vSchema.” Certo? E, depois de desenvolver e projetar algo que ele tenha analisado e para o qual tenha tomado decisões sobre as maneiras mais eficientes de fazer sharding, quando você estiver em

13:36 uma plataforma como a PlanetScale, literalmente vai conectar isso e fazer um deploy. Nós oferecemos uma interface para criar novos sistemas com sharding e escalar seu banco de dados, e muita coisa pode acontecer com a ajuda da IA ou permitindo que a IA assuma parte do controle desses processos, usando nossa API e nossa interface de linha de comando. Esse é um daqueles casos em que há uma infraestrutura muito complexa por baixo, que escala seus sistemas, mas, quando você oferece as interfaces certas — como arquivos de configuração simples —, essas coisas ficam muito mais acessíveis a qualquer

14:07 empresa que está tentando escalar. Outra coisa: isso nos leva ao conceito de contrapressão, que mencionamos antes, certo? Quando um banco de dados fica sobrecarregado — e, como você pode imaginar, isso provavelmente acontece o tempo todo em algumas dessas empresas —, certo? Acho que, há alguns meses, houve um tweet do GitHub dizendo basicamente que o tráfego deles tinha aumentado para duas, três ou quatro vezes o que já era uma carga extremamente alta. E praticamente todo esse aumento foi atribuído a AI agents, certo? Então, eles já tinham uma infraestrutura gigantesca, porque são o lugar mais popular do mundo para desenvolver.

14:39 E depois tiveram vários aumentos de tráfego, especialmente durante as festas de fim de ano, certo, devido a esses sistemas sobrecarregados. Como lidamos com isso? Uma das nossas soluções, e a forma como gostamos de pensar sobre o assunto, é oferecer aos usuários um sistema chamado traffic control, que permite categorizar e marcar todo o tráfego que chega ao banco de dados. Depois, você define orçamentos de recursos para dizer: “Este segmento do meu tráfego não pode ultrapassar esta quantidade de recursos de uso de CPU ou de processos de backend”. E, de novo, nós fazemos

15:09 uma degradação gradual quando isso acontece. O que estou mostrando aqui é um gráfico: tenho um orçamento configurado para dizer “não ultrapasse esta quantidade de recursos” e “me avise se eu começar a ultrapassar esses recursos”. Ele mostra a quantidade de consultas que ultrapassam o orçamento ao longo do tempo. E estamos enviando avisos de volta ao cliente, como: “Ei, estou sobrecarregado; você precisa desacelerar”. Também podemos ser ainda mais rigorosos e realmente encerrar as consultas que estão sendo executadas, certo? E essa é uma daquelas coisas em que pensamos: “Tudo bem, não é o ideal ter que negar solicitações, mas é muito melhor do que deixar o aplicativo inteiro

15:41 fora do ar e indisponível para todos os seus usuários”. E, por fim, quero falar de mais uma coisa. Sei que estou mostrando aqui a interface do PlanetScale, mas isso não diz respeito tanto especificamente ao PlanetScale; trata-se da filosofia de como fazemos essas coisas com agents. A maioria dos desenvolvedores está acostumada a usar um fluxo semelhante ao Git durante o desenvolvimento. E isso também se aplica aos seus agents, certo? Você tem uma branch principal, cria uma branch, faz alterações no código, integra essas alterações e faz o deploy delas dinamicamente

16:11 onde quer que seu aplicativo esteja em deploy. O que fizemos — muito antes mesmo de existirem agents — foi tentar pegar essa mesma experiência de usuário e replicá-la para o banco de dados, porque muitas vezes, quando você cria novos recursos para o aplicativo, também faz alterações no esquema. Você adiciona tabelas, adiciona colunas, exclui coisas, adiciona índices e faz tudo isso no banco de dados para mantê-lo em sincronia com o codebase. Então, o que oferecemos, com a tecnologia do mesmo Vitess mencionado antes, é a possibilidade de criar uma branch do esquema do banco de dados e fazer alterações nesse esquema em um ambiente isolado

16:41 e depois integrar essas alterações de volta à produção por meio do que chamamos de solicitação de deploy. Tudo isso sem downtime. E não é só isso: você pode ver aqui embaixo que também é possível, se fizer o deploy de uma alteração no esquema e notar um problema, revertê-la com um clique e voltar ao estado anterior do banco de dados sem perda de dados. Isso era ótimo para as pessoas, mas também temos as APIs e a CLI para permitir que agents automatizem esse processo. Assim, quando eles fazem coisas, automatizam código e criam branches

17:12 e fazem pull requests e revisão de código, pode haver um estado espelhado do banco de dados funcionando em sincronia com tudo isso, certo? Isso pode ser totalmente automatizado ou semiautomatizado. Obviamente, muitos de nós trabalhamos com humanos no ciclo, em que as pessoas ainda revisam todas essas alterações feitas por AI agents, o que é bom. Mas já temos os elementos fundamentais para criar esses sistemas. Há várias outras coisas que não consegui abordar, mas o ponto final que quero destacar é

17:43 que somos uma empresa — e sei que muitas empresas por aí gostam de se concentrar na experiência do desenvolvedor. E, quando digo experiência do desenvolvedor, não me refiro apenas a opções para alternar entre modo claro e escuro, bons atalhos de teclado e coisas do tipo. Refiro-me à experiência propriamente dita: se você é um desenvolvedor responsável pelo banco de dados da sua empresa ou por alguma parte da infraestrutura, nós oferecemos as ferramentas necessárias para evitar erros, fazer deploys com segurança, deixar o banco de dados mais rápido e obter melhor desempenho? Temos desenvolvido essas coisas há anos. E acontece que, quando você realmente se concentra nessa essência da

18:14 experiência do desenvolvedor, o resultado também são elementos fundamentais muito bons para que a IA trabalhe com um banco de dados de forma segura e confiável e ajude a escalá-lo. Como expomos muitos desses recursos pelo nosso servidor MCP e por interfaces de linha de comando, há bastante debate sobre qual dessas opções é melhor para trabalhar com seus AI agents. Mas, como disponibilizamos esses recursos para os dois lados, a experiência de operar seu banco de dados e trabalhar bem com AI agents acaba sendo ótima. Era isso que eu

18:45 tinha a dizer. Obrigado por virem. Sou Ben. Aproveitem o restante da conferência. >> [música]

Transcrição original

[00:12] Hey everybody, how’s it going? Hope you’re having a good last day of AI Engineer. Uh what I’m going to talk about today is how to move fast and not break things. So the the phrase move fast and break things. You’ve probably heard this before and what this uh refers to is it’s a phrase from early Facebook engineering culture days, right? And the idea was we want to be able to move fast and ship fast and not be constrained by, you know, databases going down or breaking certain features because the priority is there’s so much value in shipping fast. And this was 20

[00:44] years ago, right, before we had AI agents writing code for us and shipping things and deploying things on our behalf. So, if anything, the idea of doing this is more true than ever. But in my opinion, we can actually achieve both, right? I want to be able to ship fast, build great features, get things out to my customers, but also not break the databases, the infrastructure, the application servers that are powering what I’m doing. And we’ve probably all seen something that looks approximately like this. And I’m not calling out any particular company. There’s a number of companies right that due to the kind of

[01:16] insane scale that we’ve seen over the past even 6 months year two years right where we’ve had like daily active users double triple 10x 100x a lot of that powered by like the demand of AI agents um where the infrastructure struggles to keep up and some of this is simply because it’s a very hard problem right this is not meant to call anybody in particular out it’s hard to scale things to tens of millions or hundreds of millions of users but what we’d like to have is great products that scale well for lots of users and have our status

[01:47] pages look a little bit more like this one, right? Three or four nines of availability uh maybe five of availability where our databases are healthy, our applications are healthy and ultimately our users are happy, right? So this is kind of the idea behind what I want to talk about which is a little different than probably most of the talks you’ve been at. A lot of the talks are probably talking about inference or specifically how to do things with agents or different kinds of automations. This is more of an infrastructure talk, but how you can do that and ship fast both with the demand of AI agents as well as the you being

[02:21] able to use AI agents to make all of these processes more optimized and smoother. So, there’s three parts to this that I want to talk about. The first one is how do you even build systems regardless of the number of users you have that aren’t going down all the time? and then tying that into well okay if you’re going to build the next hit application that’s going to scale to millions of people using it how do we scale that using these same principles and then finally how can we take these two things and let AI agents do them for us or at least in part work

[02:51] with them in doing this so I should probably introduce myself a little bit too why I’m talking about this is I’m Ben and I’m from planet scale and we do databases this is our whole thing and we work with a lot of these AI companies that are scaling extremely fast. We work with companies like cursor for example and power databases for them. And so this is something that we as a company take very seriously. How do we scale and support companies that have millions of users uh on their platforms and some of what I’m talking about comes from a article that

[03:23] we published last year about kind of our philosophy of how we operate databases. I would encourage you to go Google that and read that. Um but a couple of these principles let’s go over some of these. So the the first and one of the most important is isolation. Right? When you are running infrastructure, one of the things you want to make sure you do is have a setup where if something fails, it doesn’t take down the whole system, but every component is very isolated. So what I’m showing here is data plane. That basically means where are your databases? Where does your most critical

[03:53] data live that you need to be using for your users to log in and interact with your application? But there’s lots of other components, right? There’s your control planes, there’s your observability pipelines, there might be your analytics frameworks, there’s your apps, there’s your MCPs, and there’s all these different components that can potentially fail. And in fact, assuming you’re using a good database platform, the database is hopefully low likely to fail, but these other things you’re shipping and deploying to more frequently, so are more likely to fail. So we want to make sure that we’ve designed things where if I deploy a bad ship to the control plane and take it

[04:25] down, nothing else is impacted and can still access the database, right? And anything in my data plane. So this is one of these kind of core principles that we take very seriously. And another thing is redundancy. And if any of you have worked with databases before in the past, you’ve probably seen a diagram that looks something like this. And similar things apply to your app infrastructure and your other infrastructure. Although in the case of application servers, usually redundancy is a little bit easier to solve because

[04:55] it’s a stateless workload, right? There’s lots of sort of autoscaling cloudflare workers and versell functions and AWS Lambda that can scale and have redundancy very easily because it’s not storing state. But in the database world, you have to store state reliably. You can’t lose a single bite of data. And so how do you do this? Um, a very common approach which costs more money and is more complex but it’s the way that you scale reliably is by having a primary node. So this is where most of your traffic goes to. But you always have replica servers or follower servers

[05:25] standing by in different data centers or different availability zones ready to take over because the fact is servers do fail sometimes. Uh, and on a small scale when you’ve got an app that has a hundred users and you have one database server, you might only experience a failure once every couple of years. But at a large scale when you have thousands of servers a once or twice a year failure becomes a weekly or monthly failure. And so you need to have systems in place to deal with this very well. Okay. So we’ve talked about uh what the

[05:56] principles of of scaling reliably are or of um having reliable systems are. But then the question is what I’ve just told you here we could write a whole book on. Right? So there’s lots more that you know there’s people who spend their entire careers focused on this. So, we’re going a little bit quickly through it, but these principles apply no matter what point of this user growth chart you’re at, right? You could be at 100 users and in this case, uh, it’s still good to have redundancies, to have isolation, to have failure even for that

[06:27] smaller set of users. And you want to apply those same principles when you are all the way up here. I don’t know if you can see that line very well, but at millions of daily active users. But there is a point where you actually have to incorporate different technologies to scale efficiently and effectively. So, uh, let’s talk about how we scale those systems for a few minutes. And probably the part you’re most excited about is the AI agents part, which we’ll get to at the end. Um, so one of the key things, and this is what we do a lot of at Planet Scale, is sharding. Um, I just

[06:58] realized my mouse is on the screen, so let me get that off the screen here. See if that will go away eventually. Um, so database sharding. What is this? What you do is instead of relying on that single node, which works fine when you have 10 gigabytes of data, it doesn’t work so well when you have 10 terabytes of data or 100 terabytes of data or a pabyte of data. So what do you have to start doing? Well, what you need to do is spread your data and your queries out across many servers. And so that’s what all of these shards down here below are. And typically you put

[07:30] some kind of proxy and we’ll talk more about what VTGate means later in between that intelligently handles distributing all of the user requests or the query requests across all of these servers. Uh and this is exactly what we do a lot of for some large customers at planet scale. We do sharding through vitess for my SQL and niki for postgress. Um and so this is a very fundamental way of doing sharding. But the other thing is you don’t just use sharding by itself. If we look at this and we see for example shard A, within that box, you actually

[08:00] would want a redundant system. So you’d have a primary and several replicas in there. So if one of those servers fails, that single shard can do self-healing and get back online very quickly if there’s a problem. So this is one of the ways that we see and is probably the most common and performant way to scale databases. But really the same principle of hey let’s take queries and data and spread them out across many servers, many nodes, many drives uh applies to lots of other areas of the stack that you’re building. Back pressure. So this is another one

[08:31] that is sort of a mix of being a part of scalability but also a part of reliability. And what we mean here is there’s a lot of systems like MySQL and Postgress and SQLite, these very popular databases that people run that don’t do a good job at handling being overloaded. The moment that they have too many queries or using too much CPU or they run out of RAM for the cache in many cases, if not taken a lot of care for, they’ll just crash and now your server is down and now all of your users are impacted and they can’t use your service

[09:01] that the database is powering. What back pressure is is it’s designing a system to be able to push back and say when I detect that I’m above a certain threshold of resources I can actually say I want to push back and start failing requests denying query uh denying connections right so that I can keep the existing users or some of the traffic healthy while gracefully degrading some of the other traffic and then the rest of your stack has to be built to support that. So, this is a principle that applies in lots of areas of the stack, but in the database, it’s

[09:32] arguably the most important. Uh, let’s see here. The clicker. There we go. And then the last component of this that I want to talk about before we move into how to do this all with AI is decoupling. Uh, there’s a lot of people that you’ll talk to and when it comes to databases will argue that you should probably have all of your services combined into one because there’s some convenience to that. your Postgress database, your OOLTP workloads combined with what you’re doing for analytics combined with your your queuing and your job system, your caching. There is

[10:03] convenience and some technologies try to do this where we put this all in one. But that does one add a lot of complexity, but it also breaks some of the fundamental principles from earlier like failure isolation, right? If one service goes down, that actually means everything is going down. And then you also have to deal with contention of resources. So if you suddenly have a burst of Q jobs and you need to scale up your cues, but maybe nothing else really needs to scale, it would be nice if we can independently scale the amount of compute resources that we’ve given to each of these parts of our backend

[10:33] service powering your favorite application. Right? So this is not a complete list. What did we go through so far? We went through sharding. We went through back pressure. And now we’re talking about decoupling. There’s many other aspects to scalability. And again, you could spend your entire career becoming an expert in scalability. Uh, but this is a lot of what we think about a lot at planet scale because our customers rely on us to be reliable and to scale. So, finally, let’s go to the last part

[11:03] of this. We let’s say we have all of these principles in place. We are doing things reliably where we have fault tolerance. We’re doing things that are very scalable. But these days in a lot of organizations and we talk to a lot of people that feel this both at the small scale and at very large organizations. How can we allow agents to whether in part or in full have control over what is arguably the most important infrastructure of your company, right? The databases, the cues, the things that are powering every other layer of your

[11:34] stack. Um, and this is something that can be a little bit intimidating because it’s pretty much the standard these days, right, to write code with AI. In some cases, people are not even writing any lines of code anymore, right? AI is actually writing all of your code, reviewing all of your code. Um, and you’re just sort of guiding these agents to doing that. But it is quite different to say, I’m going to now also give my agents the ability to deploy changes to the database or make changes to how things are configured there or to shard my database, right? because that’s

[12:04] something if it gets wrong, it’s generally not as simple as clicking a button to roll it back, right? It’s taking down your entire application and every user notices. So, we want to do this effectively and safely. So, I’m going to revisit a couple of the concepts that I previously talked about and think about how do we use agents to solve this. So, going back to sharding, what I’m going to talk a little more specifically about is Vitess and this is an open- source project. uh we operate the test databases for our customers and it works with my SQL to do sharding. So

[12:34] what you can see here is like all of those shards down there those would be my SQL databases and the VT gate that’s the proxy that is basically an intelligent proxy that takes my SQL queries parses them figures out which shard they need to go to and routes all of those requests in a very sophisticated way. So the software is fairly complicated, but the interface that we present for specifying how do you want all of your queries and your data sharded is actually quite simple. It’s what we call a v schema and it’s literally a JSON file where you say here’s the column I want to shard on and

[13:05] here’s the way I want to do sharding and you can specify certain tables to go on certain shards and have lots of control over where and how things are configured. And the great thing is, as we all know, AI agents are excellent at working with things like text files and JSON files. So you can give your agent and say, “Hey, I’m struggling with scalability of my database. Here’s my schema. I want you to come up and help me prototype a good v schema.” Right? And once you’ve developed and designed something that it has thought through and made decisions about the most efficient ways to shard when you are on

[13:36] a platform like planet scale you literally will plug this in and you make a deploy and you you can we give you an interface for creating new sharded systems and scaling up your database and a lot of this can happen with either the help of AI or letting AI take some control over these processes uh given our API and our command line interface that we run. So this is one of those things right very complex infrastructure in reality under the hood that is scaling your systems but you provide the right interfaces for it like simple configuration files and those things become much more accessible to any

[14:07] company trying to scale. Um, another thing, so this is getting into the uh concept of back pressure that we talked about earlier, right? So when a database is overloaded, and this, as you might imagine, probably happens all the time at some of these companies, right? I think there was a a tweet a couple of months ago from GitHub that basically said like their traffic had like two or three or 4x from what already was an extremely high load. And pretty much all of that was attributed to AI agents, right? So they already had gigantic infrastructure because they’re the most popular place in the world to develop.

[14:39] and then they had multiple uh uh traffic increases especially over like the holidays right due to these uh overloaded systems. So how do we deal with this? One of our solutions and the way that we like to think about it is we give users a system called traffic control which allows you to essentially categorize and tag all of the traffic coming into your database and then you create resource budgets to say hey this segment of my traffic cannot exceed this amount resources of CPU usage or of backend processes and again we do

[15:09] graceful degradation when that happens. So what I’m showing here is this is a graph of I have a budget set up um to say don’t exceed these amount of resources and warn if I do start exceeding these resources. So it’s showing me uh this is the amount of queries that are exceeding your budget over time and we’re we’re we’re sending warnings back to the client like hey I’m overloaded you need to slow down and we can even make it more strict where we actually kill those queries that are executing. Right? And this is one of those things that like, okay, it’s not ideal to have to deny requests, but it’s much better than your whole application

[15:41] going down and being offline for all of your users. Uh, and then finally, one other thing I I want to talk about, and I know I’m showing this is the planet scale UI here, but this is not even so much specifically about planet scale, but it’s about the philosophy of how we do these things with agents, which is most developers are used to using a gitlike flow when you’re building. And this applies to your agents as well, right? You have a main, you create a branch, you make code changes, you do merge that in, and you deploy that dynamically to

[16:11] wherever your application is deployed. What we have done, and this was long before agents even existed, is we wanted to take that same UX and mirror that for your database because a lot of the times when you’re building new application features, you’re also making changes to your schema. You’re adding tables, you’re adding columns, you’re deleting things, you’re you’re adding indexes, you’re doing all of this stuff to your database to keep it in sync with your codebase. So what we give you powered by that same vitess earlier is the ability to branch your database schema, make changes to that schema in an isolated

[16:41] environment and then merge that back into production with what we call a deploy request. All with no downtime. And not only that, but actually the ability, you might see here at the bottom, the ability to, if you deploy a schema change and you see a problem, we give you the ability to oneclick revert that go back to the old state of your database without data loss. Uh, and so this is something that was great for humans, but we also have the APIs and the CLI to be able to let agents automate this. So when they are doing things and automating code and branching

[17:12] and making pull requests and doing code review, there can actually be a mirror database state that is working in sync with all of those things, right? And that can either be fully automated, it can be semi-automated. Obviously, many of us are working in a human in the loop fashion where humans are still reviewing all of these changes that AI agents are making, which is a good thing. Um, but we have the primitives in place for building these uh systems. And there’s a number of other things that I didn’t get to to talk about this, but kind of the the ending point that I want to make is

[17:43] we’re a company and I know a lot of companies out there like to focus on the developer experience. And when I say developer experience, I don’t just mean like light and dark mode switches and good keyboard shortcuts and all of this, but I mean the actual experience of, hey, if you’re a developer that’s responsible for your company’s database or responsible for some piece of infrastructure, do we give you the tools that you need to not mess up to do deploys safely to make your database faster to get better performance? Uh, and we’ve been building these things for years. And it does kind of turn out that when you really focus on that core of

[18:14] the developer experience, what you actually end up with is also very good primitives for AI being able to work with a database safely and reliably and helping it scale. Uh, and so because we expose a lot of these things through our MCP server, through command line interfaces, obviously there’s plenty of debate on which of those is better when working with your AI agents, but because we expose those things to both parties, it’s actually a great experience for operating your database and working well with AI agents. So that is all that I

[18:45] have to say. Thank you guys for coming. I’m Ben and have a great rest of the conference. >> [music]