Cloudflare D1 Time Travel restaura una base a cualquier minuto dentro de la retención mediante replay del write-ahead log. La función está activa por defecto, por lo que el historial existe aunque nadie haya creado un snapshot antes de una migración arriesgada.
El plan gratuito conserva siete días y los planes de pago 30. Cloudflare no añade una tarifa separada por restore o retención; D1 cobra reads, writes y storage. Restaurar un punto tampoco elimina bookmarks anteriores, así que el equipo puede repetir el restore si el primer corte fue demasiado reciente.
Esto elimina configuración, no decisiones de incidente. Alguien debe identificar el último momento correcto, preservar evidencia, decidir si restaura en otra base, validar el resultado y redirigir tráfico. La ventaja es que el historial ya existe cuando empieza el problema.
Alguien todavía elige el minuto de corte
Time Travel graba el WAL y permite volver a cualquier minuto de la ventana. El producto no elige el minuto. En un incidente la pregunta sigue siendo humana: ¿cuál fue el último estado conocido como bueno? ¿Fue el DELETE sin WHERE de las 14:12, la migration de las 18:03, o el job que corrió a las 18:40 encima del daño?
Sin ese recorte, restaurar "un poco antes" puede reaplicar el error o tirar writes legítimos. El bookmark es ordenable lexicográficamente y se deriva de un timestamp Unix; eso ayuda a ser preciso. No sustituye el rastro de deploy, el log de la migration y un canal donde alguien diga "dejen de escribir".
Preserva evidencia antes del restore. Dump, export, o al menos el bookmark actual que devuelve wrangler d1 time-travel info. Si el restore sale mal, vas a querer el punto de ahora y el anterior. La operación devuelve un bookmark para deshacer. Anótalo. Los incidentes en los que nadie copió el ID se vuelven adivinanza.
La ganancia automática es que el historial existe aunque el equipo olvidara el snapshot del viernes. El costo que permanece es decisión, comunicación y validación. PITR barato sin runbook es solo un botón peligroso más en el CLI.
Restore in situ cancela lo que está en el aire
La documentación es directa: restaurar a un punto en el tiempo sobrescribe la base en el lugar. Las queries en vuelo se cancelan. No hay fork a una copia nueva, al menos en este diseño. "Restaurar en otra base y redirigir tráfico" es el hábito de quien viene de RDS. En el D1 actual, el hábito tiene que cambiar: el restore es destructivo en el identificador que la aplicación ya usa.
Por eso importa el ensayo. Ejecuta el comando en una base de staging, mira el tiempo, mira qué hace la aplicación cuando las queries vuelven error, mira cómo se comporta el Worker con una conexión rechazada a mitad del request. En producción, el mismo gesto pega al usuario en el acto.
Hay un tope de 10 restores cada 10 minutos por base. El retry ansioso en medio del incidente encuentra el límite. El undo usa el bookmark anterior que devolvió el propio restore. Si restauraste demasiado atrás, todavía puedes ir a un punto entre los dos, porque los bookmarks viejos no desaparecen. Lo que desaparece es el estado que estaba en el aire, salvo que alguien lo haya exportado.
El export a R2 vía Workflows existe para quien necesita retención más allá de la ventana. Eso es backup de archivo, no PITR. Distinguir los dos en el runbook evita la reunión en la que alguien pide "la base de hace 45 días" y descubre que la ventana era 30.
Retención de siete o treinta días cambia el runbook
Workers Free guarda 7 días. Paid, 30. La función está siempre encendida; la ventana no. Un bug silencioso que solo aparece el día 12, en una cuenta free, ya salió de la historia. Los equipos que usan D1 en preview en el plan free necesitan saber que el ensayo de restore de una migration de la semana pasada puede ser imposible.
El runbook, entonces, cita la ventana del entorno. Producción de pago: 30 días, aun así finita. Staging free: 7. Los datos que auditoría pide durante un año no caben en Time Travel. Caben en un export, en otra base, o en no usar D1 como sistema de registro eterno.
La facturación no gana una línea extra por restore ni por retención de historial. Sigue siendo rows read, rows written y storage. El restore en sí no es el ítem de la factura que asusta. El storage de la base, sí, si el WAL y los datos crecen. El punto operativo es otro: como el restore es in situ, el riesgo es perder writes recientes, no la nota fiscal.
Marca en el calendario de incidentes el día en que vence la ventana para el evento. Si la migration mala fue el día 1 y hoy es el día 28 en el plan de pago, el margen es pequeño. El PITR "siempre on" anestesia al equipo hasta que la ventana se cierra.
Ensayo de restore fuera del incidente
La comparación con RDS del texto de apertura vale por el ritual, no por paridad de producto. En una crisis nadie quiere descubrir el flag de Wrangler, la versión del storage (production versus alpha legado, que todavía usa snapshot) y el hecho de que el comando pide confirmación y/N mientras Slack explota.
Una vez por trimestre, en staging: anota un bookmark, haz una escritura conocida, restaura al bookmark, comprueba que la escritura desapareció, deshaz al bookmark posterior, comprueba que volvió. Mide el tiempo. Guarda la salida. Pon el comando en el runbook con el nombre real de la base, no con YOUR_DATABASE.
Confirma que la base está en el subsystem de producción (wrangler d1 info, campo version). El alpha legado no tiene Time Travel. Descubrirlo en el incidente es el tipo de detalle que convierte el PITR teórico en "no lo teníamos".
Wrangler 3.4.0 o superior es un requisito documentado. La imagen de CI y el portátil de on-call necesitan esa versión. Sin pin, el comando desaparece del path a destiempo.
El techo de SQLite en el edge sigue valiendo
PITR no aumenta el tamaño máximo de la base, no convierte D1 en Postgres con réplica multi-región, no cambia el hecho de que cada database es single-threaded. 10 GB en el plan de pago, 500 MB en el free, query de hasta 30 s, restore con límite de tasa. Time Travel resuelve una clase de error (escribiste mal, quieres volver). No resuelve un modelo de datos que ya pasó el techo, ni un hot shard, ni un informe analítico.
Si la aplicación ya está en el límite de tamaño, el WAL histórico no es el problema principal. Si la aplicación necesita un clone para blue/green, el producto todavía no ofrece fork. El workaround es export/import, con el costo y la ventana que eso tiene. Planear la migración peligrosa en un horario en el que el restore in situ es aceptable sigue siendo trabajo de operación.
Para quien ya está en Workers, la cuenta cierra así: historial de minutos sin tarifa extra, restore destructivo, ventana corta, ensayo obligatorio. Eso es barato en dinero y caro en disciplina. El equipo que solo celebra "es gratis y viene encendido" va a usar el comando por primera vez contra la base equivocada.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
