SQLite ya basta para flujos de trabajo duraderos

La tesis de Obelisk es incómoda para cualquiera que haya montado una pila de orquestación por inercia: si ya confías en tu base de datos, quizá no necesites una capa aparte para coordinar trabajos, reintentos y estado persistente.

El argumento no va de nostalgia

No es un homenaje a SQLite por ser pequeño o por funcionar en local. El punto es más práctico: guardar el progreso del workflow en un log de ejecución, poder reproducirlo, reintentar actividades y mantener el historial en un formato que se inspecciona sin pelearse con una infraestructura adicional.

En ese esquema, SQLite no actúa como una base “de juguete”, sino como el sitio donde vive la verdad operativa. Eso simplifica despliegues, facilita el debugging y reduce el número de piezas que pueden fallar a la vez.

Litestream cambia la conversación

La pieza que hace creíble la apuesta es Litestream. El binomio SQLite + réplicas/backups continuos permite llevar la base a S3 sin convertir el sistema en una arquitectura pesada. El resultado es un modelo más portátil: servidor, base local, copia persistente y observabilidad razonable.

La misma base puede servir para replay local, depuración y auditoría de lo que hizo realmente un agente.

Para equipos que trabajan con agentes o automatizaciones largas, eso importa más que el brillo de una solución más grande. No todo problema necesita Postgres con una capa de workflow encima.

Cuándo deja de ser buena idea

El límite también está claro: si necesitas concurrencia a gran escala, consultas complejas sobre el estado operativo o una topología distribuida de verdad, la simplicidad de SQLite se queda corta. Obelisk no borra ese trade-off; solo lo hace visible.

La noticia importante, en realidad, es otra: vuelve a abrir la puerta a construir sistemas duraderos con menos piezas, menos despliegue y menos coste mental. Y eso, en automatización seria, vale casi tanto como la velocidad.