Bintrail adiciona consultas de viagem no tempo ao MySQL

Bintrail habilita SQL de viagem no tempo no MySQL — o único banco OLTP principal sem suporte nativo — usando binary logs indexados roteados via um shim ProxySQL. Sem alterações no código da aplicação. Sem migração de schema.

MySQL fica para trás de seus pares significativamente. Oracle lançou AS OF TIMESTAMP há 25 anos. SQL Server adicionou FOR SYSTEM_TIME AS OF uma década atrás. MariaDB construiu system-versioned tables. CockroachDB incluiu viagem no tempo desde o primeiro dia. PostgreSQL tem três extensões comunitárias. MySQL, o motor OLTP mais amplamente implantado, não tem nenhuma. Recuperação e auditoria no MySQL historicamente exigiam procedimentos de point-in-time restore — colocando uma réplica em funcionamento, reenviando binlogs de backup, e esperando — em vez de uma única consulta SQL.

Arquitetura do Bintrail: binary logs ROW-format do MySQL alimentam uma camada de indexação customizada que analisa cada evento de linha com imagens antes/depois. ProxySQL funciona como o plano de roteamento. Quando Bintrail detecta uma consulta contra schemas virtuais _flashback ou _diff, ProxySQL roteia para Bintrail; todo o outro tráfego passa através do MySQL inalterado. Bintrail mantém histórico indexado independente da janela de retenção de binlog do MySQL, permitindo consultas históricas cobrir períodos mais longos. O histórico se estende para arquivos Parquet arquivados em S3 para casos de uso de auditoria de retenção longa. Sem ALTER TABLE. Sem novo storage engine. Única mudança: apontar a string de conexão ao ProxySQL em vez da porta MySQL.

Uma consulta _flashback retorna o estado completo de uma tabela ou de uma linha específica em um momento passado: SELECT * FROM _flashback.orders AS OF '2026-04-15 09:30:00' WHERE id = 42. Uma consulta _diff retorna a sequência de mudança completa para uma linha ou tabela dentro de uma janela de tempo, incluindo tipo de evento, GTID, e valores de coluna antes/depois. Regras de roteamento ProxySQL para esses padrões podem ser auto-geradas sem tocar a camada de aplicação. SQL de reversão para recuperação point-in-time é gerado de eventos indexados, não de reenviamento do binlog original.

Nenhuma métrica de produção foi divulgada no lançamento — nenhuma latência, throughput, overhead de armazenamento, ou custo por consulta. O projeto está em lançamento inicial com código no GitHub sob uma licença BUSL. Peter Zaitsev, fundador da Percona, chamou de "trabalho incrível com soluções eficientes para recuperabilidade do MySQL." Roman Agabekov, fundador da Releem, notou: "Restaurar um backup completo é frequentemente muito pesado, muito lento, e muito arriscado. Isso importa ainda mais agora, quando SQL gerado por IA, scripts automatizados, e mudanças operacionais estão se movendo mais rápido que antes."

Limitações atuais: Bintrail suporta apenas consultas com timestamps literais, lookups de chave primária, e restores de tabela completa limitados. Joins e filtragem complexa contra dados históricos exigem reconstrução manual fora da camada do shim. A licença BUSL é source-available mas não é open-source; termos de uso comercial importam para equipes com revisão de licenciamento. ProxySQL adiciona um salto de rede e um novo domínio de falha ao caminho MySQL; a documentação de arquitetura não aborda comportamento de HA ou failover.

Para equipes de plataforma de ML, o ângulo é direto: proveniência de dados de treinamento e auditoria de input de modelo são requisitos comuns. A maioria das lojas as trata com bancos temporais separados (mais infraestrutura, mais custo) ou pipelines de snapshot-para-S3 (tempo de engenharia, risco de schema drift). O padrão do proxy-shim do Bintrail — colocando capacidade sobre um banco existente via proxy de roteamento, com zero mudanças de código de app — é o padrão arquitetural que vale estudar. Aguarde benchmarks de performance e clareza de HA antes de implantar no caminho crítico.