Bintrail añade consultas de viaje temporal a MySQL

Bintrail habilita SQL de viaje temporal en MySQL — la única base de datos OLTP principal sin soporte nativo — usando binary logs indexados enrutados vía un shim ProxySQL. Sin cambios en el código de la aplicación. Sin migración de esquema.

MySQL se queda significativamente atrás de sus pares. Oracle lanzó AS OF TIMESTAMP hace 25 años. SQL Server añadió FOR SYSTEM_TIME AS OF hace una década. MariaDB construyó system-versioned tables. CockroachDB incluyó viaje temporal desde el primer día. PostgreSQL tiene tres extensiones comunitarias. MySQL, el motor OLTP más ampliamente implantado, no tiene ninguna. Recuperación y auditoría en MySQL históricamente exigieron procedimientos de point-in-time restore — levantando una réplica, reenviando binlogs de backup, y esperando — en lugar de una única consulta SQL.

Arquitectura de Bintrail: binary logs ROW-format de MySQL alimentan una capa de indexación personalizada que analiza cada evento de fila con imágenes antes/después. ProxySQL actúa como el plano de enrutamiento. Cuando Bintrail detecta una consulta contra esquemas virtuales _flashback o _diff, ProxySQL la enruta a Bintrail; todo el resto del tráfico pasa a través de MySQL sin cambios. Bintrail mantiene historial indexado independiente de la ventana de retención de binlog de MySQL, permitiendo consultas históricas abarcar períodos más largos. El historial se extiende hacia archivos Parquet archivados en S3 para casos de uso de auditoría de retención larga. Sin ALTER TABLE. Sin nuevo storage engine. Único cambio: apuntar la cadena de conexión a ProxySQL en lugar del puerto MySQL.

Una consulta _flashback retorna el estado completo de una tabla o una fila específica en un momento pasado: SELECT * FROM _flashback.orders AS OF '2026-04-15 09:30:00' WHERE id = 42. Una consulta _diff retorna la secuencia de cambio completa para una fila o tabla dentro de una ventana de tiempo, incluyendo tipo de evento, GTID, y valores de columna antes/después. Las reglas de enrutamiento ProxySQL para estos patrones pueden ser auto-generadas sin tocar la capa de aplicación. SQL de reversión para recuperación point-in-time se genera de eventos indexados, no de reenviamiento del binlog original.

Ninguna métrica de producción fue divulgada en el lanzamiento — ninguna latencia, throughput, overhead de almacenamiento, o costo por consulta. El proyecto está en lanzamiento temprano con código en GitHub bajo una licencia BUSL. Peter Zaitsev, fundador de Percona, lo llamó "trabajo asombroso con soluciones eficientes para recuperabilidad de MySQL." Roman Agabekov, fundador de Releem, señaló: "Restaurar un backup completo a menudo es demasiado pesado, demasiado lento, y demasiado arriesgado. Eso importa aún más ahora, cuando SQL generado por IA, scripts automatizados, y cambios operacionales se están moviendo más rápido que antes."

Limitaciones actuales: Bintrail soporta solo consultas de timestamp literal, búsquedas de clave primaria, y restores de tabla completa limitados. Joins y filtrado complejo contra datos históricos requieren reconstrucción manual fuera de la capa del shim. La licencia BUSL es source-available pero no es open-source; los términos de uso comercial importan para equipos con revisión de licenciamiento. ProxySQL añade un salto de red y un nuevo dominio de falla a la ruta MySQL; la documentación de arquitectura no aborda comportamiento de HA o failover.

Para equipos de plataforma de ML, el ángulo es directo: procedencia de datos de entrenamiento y auditoría de inputs de modelo son requisitos comunes. La mayoría de tiendas los manejan con bases de datos temporales separadas (más infraestructura, más costo) o pipelines de snapshot-a-S3 (tiempo de ingeniería, riesgo de schema drift). El patrón proxy-shim de Bintrail — colocando capacidad sobre una base de datos existente vía proxy de enrutamiento, con cero cambios de código de app — es el patrón arquitectónico que vale la pena estudiar. Espere benchmarks de desempeño y claridad de HA antes de desplegar en la ruta crítica.