A discussão sobre a infraestrutura ideal para fluxos de trabalho duráveis ganhou um novo capítulo. Recentemente, a DBOS argumentou que o Postgres é, por si só, suficiente para a execução durável: se você confia no seu banco de dados, não precisaria de uma camada de orquestração separada. Uma ideia que faz sentido e, para alguns, pode ser levada ainda mais longe.
E a verdade é que, para uma vasta categoria de sistemas duráveis, o SQLite pode ser tudo o que você precisa.
A parte durável da equação
A execução durável é frequentemente vista como algo que exige uma infraestrutura igualmente durável. No entanto, em muitos cenários, isso não é uma regra. O que realmente precisa ser durável é o estado do fluxo de trabalho. A capacidade computacional, por outro lado, pode ser mais barata e descartável.
Isso se encaixa perfeitamente com a proposta do Obelisk: o progresso do fluxo de trabalho reside em um log de execução, os fluxos se reproduzem a partir do histórico persistido e as atividades podem ser retentadas. O mais importante é manter o estado do fluxo de trabalho acessível e fácil de inspecionar.
Por que o SQLite se encaixa tão bem?
O SQLite é atraente porque oferece um estado transacional durável sem a necessidade de introduzir um serviço de banco de dados separado. Não há saltos de rede, nem um plano de controle adicional, nem uma nova área de superfície operacional apenas para manter o progresso do fluxo de trabalho seguro. Para muitos sistemas, um arquivo de banco de dados local é exatamente o nível de maquinário adequado.
Litestream: portabilidade para seus dados
A preocupação mais óbvia é o que fazer com esses arquivos SQLite à medida que os experimentos se acumulam. É aí que o Litestream entra em cena. Ele consegue transmitir as alterações do SQLite de forma assíncrona para um armazenamento de objetos compatível com S3. Isso oferece uma maneira simples de manter o estado de trabalho próximo ao tempo de execução, enquanto copia os bancos de dados para backup, migração e inspeção.
Um detalhe importante é que a replicação do Litestream é assíncrona. Uma restauração pode perder as gravações locais mais recentes se o volume SQLite desaparecer antes que elas sejam copiadas. Isso é aceitável para muitos fluxos de trabalho de IA e experimentação, mas não se compara a um banco de dados compartilhado de alta disponibilidade.
Ainda assim, isso leva a um modelo operacional bastante útil: você executa um servidor Obelisk com um banco de dados SQLite, o faz backup com Litestream e permite que um observador extraia os bancos de dados de interesse quando necessário. O mesmo arquivo pode ser usado para reprodução local, depuração e para entender o que um agente realmente fez.
Vantagens para agentes de IA
Este modelo é particularmente interessante para agentes de inteligência artificial e fluxos de trabalho gerados por IA. Esses sistemas frequentemente apresentam características de intermitência, são experimentais e mais fáceis de analisar quando cada agente ou inquilino possui uma unidade de estado pequena e autocontida. Uma frota de pequenos servidores em micro VMs ou contêineres, cada um com seu próprio banco de dados SQLite e backup em armazenamento de objetos, muitas vezes se mostra um ajuste melhor do que um sistema compartilhado grande e sempre ativo. É mais simples, mais barato e proporciona um melhor isolamento de falhas.
Quando o Postgres ainda é a melhor escolha?
O SQLite não é a resposta para todas as formas de implantação. O Obelisk também oferece suporte ao Postgres, e essa é a escolha certa quando você precisa de maior disponibilidade, escalabilidade compartilhada mais ampla ou outras propriedades de implantação que são melhor atendidas por um banco de dados em rede. É também a opção mais adequada quando a replicação assíncrona para armazenamento de objetos não é o modelo de durabilidade desejado.