Tailscale descubre un bug de 16 años en el WAL de SQLite

⏱️ Lectura: 12 min

Diecinueve veces en seis meses, una base de datos SQLite se corrompió dentro de la infraestructura de Tailscale sin que nadie pudiera reproducir el fallo en un laboratorio. La empresa desplegó telemetría forense en producción durante meses hasta rastrear el origen: un bug de SQLite con 16 años de antigüedad, escondido en el mecanismo de Write-Ahead Logging (WAL) que usan miles de aplicaciones.

📑 En este artículo

1. TL;DR
2. Introducción
3. Qué pasó
4. Contexto e historia
5. Detalles técnicos del bug de SQLite
6. Cómo empezar a blindar tu base SQLite
7. Impacto y análisis
8. Qué sigue
9. Preguntas frecuentes
   1. ¿Qué es exactamente el bug de SQLite que encontró Tailscale?
   2. ¿Corro riesgo si uso SQLite en producción?
   3. ¿Qué es el modo WAL y en qué se diferencia del modo por defecto?
   4. ¿Tailscale perdió datos de usuarios?
   5. ¿Cómo detecto si mi propia base SQLite está corrupta?
   6. ¿Dónde puedo leer el reporte técnico completo?
10. Referencias

El caso, publicado el 12 de agosto de 2026 en el blog técnico de Tailscale, es un ejemplo poco común de una empresa que termina ayudando a corregir un fallo en el corazón de uno de los motores de bases de datos más usados del mundo. Para cualquier equipo que corre SQLite en producción, la historia deja lecciones concretas sobre backups, modo WAL y diagnóstico de corrupción.

TL;DR

• Tailscale sufrió 19 incidentes de corrupción en su base SQLite entre agosto de 2025 y principios de 2026.
• El origen fue un bug de SQLite de 16 años, ligado al mecanismo de Write-Ahead Logging (WAL).
• Tailscale usa SQLite como base de datos principal de su control plane desde 2022.
• Cada shard corre un único proceso en Go con acceso exclusivo a su base SQLite (diseño single-writer).
• El bug no se pudo reproducir en laboratorio; el equipo desplegó telemetría forense en producción para atraparlo.
• Durante la corrupción, el control plane del shard se detenía y los dispositivos nuevos no podían unirse.
• Los datos afectados eran solo metadata de configuración, nunca claves privadas ni tráfico de red.
• Tailscale confirma que ya identificó, entendió y corrigió el bug antes de publicar el reporte.

Introducción

Desde finales de 2025, la página de estado de Tailscale mostraba una inestabilidad recurrente y sin patrón aparente. La causa raíz vivía dentro de SQLite, la base de datos embebida que sostiene el control plane detrás de cada conexión WireGuard entre dispositivos de una tailnet. Rastrear un bug de SQLite con 16 años sin detectarse no fue trabajo de una tarde: tomó meses de forense en producción, y la propia empresa reconoce que la inestabilidad repetida erosionó la confianza de parte de sus usuarios, aunque la mayoría de los tailnets nunca se vio afectada de forma directa.

Qué pasó

El control plane de Tailscale no es un servicio monolítico. Detrás del endpoint público controlplane.tailscale.com hay una serie de shards internos de coordinación: cada tailnet vive en un shard a la vez y puede migrar entre shards sin que el usuario lo note. Cada shard corre un único proceso en Go que abre en exclusiva su propia base de datos SQLite, exactamente el patrón single-writer para el que SQLite fue diseñado desde el principio.

El pipeline de respaldo tomaba una copia completa del archivo SQLite cada pocos minutos y la subía a un bucket de S3, un esquema que había corrido sin incidentes desde comienzos de 2023. Todo cambió en agosto de 2025: un pipeline que leía esos backups reportó un error, y correr PRAGMA integrity_check contra el archivo confirmó lo que nadie esperaba: la base de datos estaba corrupta.

La corrupción de una base SQLite es posible, pero infrecuente en operación normal. El equipo reparó la base, investigó la causa y no encontró nada concluyente. Cuando el mismo error volvió a aparecer, y volvió a aparecer, quedó claro que no era un incidente aislado. En total, Tailscale registró 19 incidentes de corrupción en seis meses antes de resolver el bug de raíz, según su propio recuento.

Contexto e historia

Tailscale adoptó SQLite como base de datos principal en 2022 por ser, en sus propias palabras, tecnología aburrida en el buen sentido: conocida, confiable y usada a mayor escala por otras compañías sin sobresaltos. La promesa de SQLite es simple: un único archivo, sin servidor que administrar, con garantías ACID completas mientras haya un solo proceso escribiendo a la vez. Ese último punto resultó ser, indirectamente, el centro del problema.

Cada vez que un shard sufría corrupción, el proceso de control plane debía detenerse por completo mientras el equipo reparaba o restauraba la base de datos. Para los tailnets alojados en ese shard, el control plane desaparecía durante toda la ventana de recuperación. En los primeros incidentes esa ventana superó la hora; con cada repetición, el equipo fue acelerando el proceso de recuperación. Los dispositivos que ya estaban conectados seguían hablando entre sí por WireGuard de forma peer-to-peer, pero no podían enterarse de cambios en la red: un dispositivo nuevo no lograba unirse a la tailnet hasta que el shard volvía en línea, y la consola web y la API de Tailscale quedaban inaccesibles para esos usuarios.

Tailscale publica un incidente global en su status page incluso cuando afecta a una porción pequeña de shards, así que buena parte de los usuarios vio reportes de caídas que nunca los tocaron directamente. Aun así, la repetición del problema (19 veces en medio año) fue suficiente para desgastar la confianza, más allá del alcance real de cada corte.

Detalles técnicos del bug de SQLite

Lo que hizo especialmente difícil este bug de SQLite fue la ausencia de un factor común. El equipo de Tailscale revisó los cambios recientes en su código de bajo nivel y no encontró nada relevante: nadie había tocado esa capa en años. Tampoco encontraron un patrón entre incidentes: no estaba ligado a un shard específico, a un cliente, a una función particular del producto, a una hora del día ni a un nivel de carga. Sin un disparador confiable, no podían reproducir el fallo de forma sintética en un entorno de pruebas.

La única salida fue instrumentar el entorno real con telemetría forense pasiva: diagnósticos vivos, corriendo en producción, a la espera de atrapar la corrupción en el momento exacto en que ocurría. El nombre que terminó recibiendo el hallazgo (WAL-Reset bug) apunta al mecanismo de Write-Ahead Logging de SQLite, el modo en el que las escrituras se acumulan primero en un archivo de log separado (-wal) antes de aplicarse al archivo principal mediante un checkpoint. Un fallo sutil en la lógica que reinicia ese log tras un checkpoint es exactamente el tipo de condición de carrera que solo aparece bajo una combinación puntual de tiempos, y no bajo una carga alta sostenida, lo cual explica por qué resultó invisible durante años de uso normal.

flowchart TD
    A["Dispositivo Tailscale"] --> B["controlplane.tailscale.com"]
    B --> C["Shard de coordinación"]
    C --> D[("Base SQLite del shard")]
    C --> E["Backup cada pocos minutos"]
    E --> F[("Bucket S3")]

Modo	Cuándo usarlo	Ventaja	Limitación
Rollback journal (por defecto)	Apps con pocas escrituras concurrentes	Simplicidad, sin archivos extra persistentes	Lectores y escritores se bloquean entre sí
WAL (Write-Ahead Logging)	Apps con lecturas y escrituras concurrentes, como un control plane	Lectores no bloquean al escritor y viceversa	Requiere checkpoints periódicos y gestión del archivo -wal

Cómo empezar a blindar tu base SQLite

No hace falta operar a la escala de Tailscale para toparte con corrupción silenciosa. Estos son los pasos mínimos para blindar cualquier base SQLite en producción, sea un backend propio o una app de escritorio.

# Windows (PowerShell, via winget)
winget install SQLite.SQLite

# macOS (Homebrew)
brew install sqlite

# Linux (Debian/Ubuntu)
sudo apt install sqlite3

# Verificar integridad de una base existente
sqlite3 tailnet.db "PRAGMA integrity_check;"

Una base sana responde ok. Cualquier otro texto lista las páginas o índices dañados y es la señal para restaurar desde el último backup verificado.

💡 Tip: Corré PRAGMA integrity_check; como parte de tu pipeline de backups, no solo cuando algo ya se ve mal: es la única forma de detectar corrupción silenciosa antes de que se propague.

-- Activar WAL en una base SQLite
PRAGMA journal_mode=WAL;

-- Confirmar que quedó activo (debe devolver "wal")
PRAGMA journal_mode;

-- Forzar un checkpoint y ver cuántas páginas se movieron
PRAGMA wal_checkpoint(TRUNCATE);

Si PRAGMA journal_mode; no devuelve wal, el modo no quedó activo (por ejemplo, por una conexión abierta en modo memoria) y hay que revisar cómo se abre la conexión.

db, err := sql.Open("sqlite3", "file:shard.db?_journal_mode=WAL&_busy_timeout=5000")
if err != nil {
    log.Fatalf("no se pudo abrir shard.db: %v", err)
}
defer db.Close()

// Single-writer: un único *sql.DB por shard, sin pool de escritores
db.SetMaxOpenConns(1)

El _busy_timeout evita errores de database is locked cuando un checkpoint compite brevemente con una escritura, y limitar las conexiones a una sola respeta el patrón single-writer que espera SQLite.

⚠️ Ojo: Antes de asumir que la corrupción es un bug propio, aislá primero el patrón de acceso: SQLite exige un único escritor por archivo, y compartir la conexión entre procesos sin coordinarla es la causa más común de corrupción, aunque en este caso el origen estaba en SQLite mismo.

Impacto y análisis

El caso importa más allá de Tailscale porque SQLite es, según sus propios mantenedores, probablemente la base de datos más desplegada del mundo: vive dentro de navegadores, sistemas operativos móviles, aplicaciones de escritorio y, cada vez más, backends de producción que antes hubieran usado Postgres o MySQL por defecto. Un bug de SQLite con 16 años de antigüedad no afecta solo a Tailscale: afecta, en teoría, a cualquier proyecto que use el mismo mecanismo de WAL bajo condiciones similares de escritura. Que una sola empresa, con suficiente escala y suficiente disciplina de telemetría, haya podido aislarlo es en sí mismo un servicio al resto del ecosistema.

También deja una lección sobre observabilidad: cuando un bug no se puede reproducir en un entorno controlado, la única alternativa real es instrumentar la producción con cuidado y paciencia, sin comprometer la disponibilidad del propio sistema que se está depurando. Tailscale documenta ese proceso completo, no solo el resultado final, algo poco común en reportes públicos de este tipo.

Qué sigue

Tailscale afirma en su publicación que ya identificó el bug, lo entendió a fondo y lo corrigió, y que confía en la estabilidad de su plataforma de cara a lo que resta de 2026. Lo que todavía no está claro es si el equipo central de SQLite integrará el fix directamente en una futura versión oficial del proyecto o si Tailscale mantiene un parche propio mientras tanto. Cualquier equipo que dependa de SQLite en un patrón de escritura similar (procesos de larga duración, alto volumen de transacciones pequeñas, backups frecuentes del archivo completo) debería revisar el changelog oficial de SQLite en las próximas versiones para confirmar si el fix ya está incluido.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré sqlite3 tu_base.db "PRAGMA integrity_check;" contra tu base de producción hoy mismo, antes de necesitarlo en medio de un incidente.

Preguntas frecuentes

¿Qué es exactamente el bug de SQLite que encontró Tailscale?

Es un fallo con 16 años de antigüedad ligado al mecanismo de Write-Ahead Logging (WAL) de SQLite, que en circunstancias muy específicas podía corromper el archivo de base de datos. Tailscale lo documentó públicamente el 12 de agosto de 2026 después de investigarlo durante meses.

¿Corro riesgo si uso SQLite en producción?

El riesgo es bajo: Tailscale necesitó su propia escala, decenas de shards con escrituras constantes durante meses, para siquiera detectar el patrón. Aun así, correr PRAGMA integrity_check periódicamente y mantener backups verificados es una práctica recomendable para cualquier despliegue serio.

¿Qué es el modo WAL y en qué se diferencia del modo por defecto?

WAL (Write-Ahead Logging) escribe primero los cambios en un archivo de log separado y los aplica al archivo principal mediante checkpoints periódicos, lo que permite que lectores y el escritor no se bloqueen entre sí. El modo por defecto (rollback journal) es más simple pero bloquea lecturas durante una escritura.

¿Tailscale perdió datos de usuarios?

Según la empresa, las bases afectadas contienen solo metadata de configuración, como dispositivos y ajustes de red, nunca claves privadas de cifrado ni tráfico de red. En los incidentes más tempranos, algunos cambios recientes no persistieron y debieron reingresarse manualmente.

¿Cómo detecto si mi propia base SQLite está corrupta?

Corré PRAGMA integrity_check; contra el archivo: una base sana devuelve la palabra ok; cualquier otra respuesta lista los problemas encontrados.

¿Dónde puedo leer el reporte técnico completo?

El relato original, con la cronología completa de los 19 incidentes, está publicado en el blog oficial de Tailscale.

Referencias

• Tailscale Blog: publicación original sobre el hallazgo del bug de WAL-Reset en SQLite, con la cronología completa de los 19 incidentes.
• SQLite.org: documentación oficial del modo Write-Ahead Logging (WAL).
• SQLite.org: referencia del comando PRAGMA integrity_check para detectar corrupción.
• GitHub: Litestream: herramienta open source de replicación continua para backups de SQLite en producción.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Markus Spiske en Unsplash