03.10.2026 · Signal Titans Editorial
Como a Plaud escalou a arquitetura de dados de seu hardware de IA além de 300 milhões de linhas
A Plaud reestruturou sua infraestrutura de banco de dados, migrando metadados para o TiDB para resolver bloqueios de schema e melhorar a vazão de consultas em escala.

A fabricante de hardware de IA Plaud reestruturou sua arquitetura de dados de backend após sua configuração relacional inicial encontrar gargalos de escala em torno de 300 milhões de linhas. Ao migrar sua camada de metadados estruturados para o TiDB, a equipe resolveu limitações nas alterações de schema e ampliou a margem de desempenho para consultas, mantendo a latência P95 abaixo de 10 milissegundos.
O gargalo do armazenamento secundário de transcrições
A Plaud implementou originalmente um padrão comum de armazenamento em duas camadas, alocando metadados estruturados no MySQL e arquivos brutos de áudio ou transcrições no Amazon S3. Embora eficaz para as operações iniciais, a separação dos metadados em relação ao conteúdo gerou desafios arquiteturais. Sem um limite transacional compartilhado entre os dois locais de armazenamento, a consistência dos dados passou a depender de lógicas de reconciliação na camada da aplicação.
Com o aumento no acesso simultâneo de usuários, a dependência do armazenamento de objetos como caminho principal para volumes de dados de múltiplos megabytes introduziu variação na latência de recuperação. Além disso, picos de latência e atrasos de replicação arriscavam criar lacunas temporárias de consistência, nas quais os metadados sinalizavam que uma transcrição estava pronta antes que o objeto correspondente no S3 estivesse acessível.
Limitações de schema com 300 milhões de linhas
Conforme o repositório de metadados em instância única do MySQL atingiu aproximadamente 300 milhões de linhas, as modificações de schema tornaram-se cada vez mais arriscadas. Operações de linguagem de definição de dados (DDL) exigiam bloqueios de tabelas e geravam sobrecarga de replicação, forçando a equipe de engenharia a agendar atualizações exclusivamente dentro de janelas de manutenção dedicadas.
Esse limite do banco de dados afetou o ritmo de entrega do produto, uma vez que modificações rotineiras, como a inclusão de colunas ou a alteração de índices, passaram a depender de ciclos operacionais de manutenção em vez de cronogramas flexíveis de lançamento.
Migração de metadados para SQL distribuído
Para remover o teto de escala, a Plaud migrou sua camada de metadados estruturados para o TiDB, um banco de dados SQL distribuído, mantendo os grandes volumes de áudio no armazenamento de objetos. A nova arquitetura viabilizou a execução de DDL online, permitindo atualizações de schema sem necessidade de janelas de inatividade.
A migração ampliou a capacidade de consultas por segundo da Plaud em cerca de dez vezes, mantendo a latência máxima abaixo de 10 milissegundos e evitando que atrasos na recuperação de dados comprometessem a experiência do usuário final.
Ilustração editorial gerada por IA; não é uma fotografia documental.
Fonte: The Database Is the Product: What Breaks When Memory Devices Scale