SQLite e tudo que voce precisa pra workflows duraveis, defende o Obelisk
O time do Obelisk, engine open-source de orquestracao de workflows, publicou em 29 de maio um post que viralizou no Hacker News no mesmo dia. A tese: pra boa parte dos sistemas que precisam de execucao duravel, um arquivo SQLite com backup via Litestream pra S3 ja resolve. Sem Temporal, sem Cadence, sem Postgres dedicado.
O argumento central
A distincao que o post faz e simples e fica perdida em discussoes sobre confiabilidade: execucao duravel nao exige infraestrutura duravel. O estado precisa sobreviver a crash. O compute que processa os passos nao precisa. Voce pode rodar uma frota de containers descartaveis enquanto mantem o log de progresso num arquivo local protegido.
Por que SQLite encaixa
SQLite entrega transacao ACID local sem precisar de servico separado. Sem network hop entre worker e banco. Sem control plane novo. Sem cluster pra cuidar. O custo operacional cai porque some uma camada inteira de infra. O ganho em latencia tambem importa: gravar checkpoint local custa microssegundos contra dezenas de milissegundos pra Postgres remoto.
Litestream resolve o backup
O ponto que parecia frageis era a perda de host. Se o servidor morre, o SQLite morre junto. Litestream resolve isso replicando o WAL do SQLite de forma assincrona pra object storage S3-compatible. Em caso de crash, voce restaura o ultimo snapshot e segue de onde parou. Replicacao multi-regiao tambem fica viavel.
O caso de uso pra agentes IA
O desenho casa especialmente bem com agentes IA. Cada agente roda numa VM pequena com seu proprio SQLite. Workloads de agente sao burstosas, experimentais e mais faceis de raciocinar quando cada tenant tem um pedaco de estado isolado. Esse modelo aparece em fornecedores como Cloudflare Durable Objects e em runtimes proprios de empresas que rodam centenas de milhares de agentes.
Onde o argumento nao se aplica
O proprio post reconhece limites. Volume alto de escrita concorrente entre tenants distintos exige outro modelo. Workflows que precisam de leitura federada cruzando muitos tenants tambem nao se beneficiam. Pra esses casos, Temporal e Cadence ainda fazem sentido. Mas, na leitura do up23labs, o numero de sistemas que realmente precisa dessa complexidade e menor do que a industria pratica hoje.
O criterio pratico
A decisao bate em duas perguntas: a workload e isolada por tenant ou compartilhada? E o estado de cada execucao e pequeno o suficiente pra caber num SQLite por instancia? Se as duas respostas forem sim, vale testar SQLite + Litestream antes de subir Postgres ou um cluster Temporal. Se uma for nao, fica com a opcao maior.
Reportado originalmente por Obelisk em 2026-05-29.
