SQLite만으로 내구성 있는 워크플로를 구현할 수 있음

• 내구 실행의 핵심은 인프라 자체가 아니라 워크플로 상태 보존이며, 진행 상태가 남아 있으면 재실행과 복구가 가능함
• Obelisk는 워크플로 진행을 실행 로그에 저장하고 지속된 이력에서 재생하며, 활동 재시도에 맞춘 구조를 가짐
• SQLite는 별도 데이터베이스 서비스, 네트워크 홉, 추가 제어 평면 없이 로컬 파일로 트랜잭션 기반 내구 상태를 제공함
• Litestream은 SQLite 변경 사항을 S3 호환 객체 스토리지로 비동기 스트리밍하지만, 복사 전 볼륨이 사라지면 최신 쓰기를 잃을 수 있음
• Obelisk는 Postgres도 지원하며, 더 높은 가용성·공유 확장성·네트워크 데이터베이스 특성이 필요할 때 더 적합함

SQLite와 Litestream 운영 모델

• Litestream은 SQLite 변경 사항을 S3 호환 객체 스토리지로 비동기 스트리밍할 수 있음
• 실행 환경 가까이에 작업 상태를 두면서도, 백업·마이그레이션·검사용으로 데이터베이스를 외부에 복사할 수 있음
• 비동기 복제 특성상 SQLite 볼륨이 복사 전에 사라지면 복원 시 최신 로컬 쓰기를 잃을 수 있음
• Obelisk 서버를 SQLite 데이터베이스와 함께 실행하고 Litestream으로 백업하며, 필요할 때 관찰자가 필요한 데이터베이스를 가져오는 구조임
• 같은 SQLite 파일은 로컬 재생, 디버깅, 에이전트가 실제로 수행한 작업 이해에 사용할 수 있음

적합한 사용 범위와 Postgres 선택 기준

• AI 에이전트와 AI 생성 워크플로는 버스트성이 있고 실험적인 경우가 많아, 에이전트나 테넌트마다 작은 자체 상태 단위를 갖는 구성이 이해하기 쉬움
• 마이크로 VM이나 컨테이너 안의 작은 서버 여러 개가 각각 SQLite 데이터베이스와 객체 스토리지 백업을 갖는 방식은, 하나의 큰 상시 실행 공유 시스템보다 단순하고 저렴하며 장애 격리가 좋을 수 있음
• 객체 스토리지로의 비동기 복제가 원하는 내구성 모델이 아니거나, 더 높은 가용성·더 넓은 공유 확장성·네트워크 데이터베이스 특성이 필요하면 Postgres가 더 적합함
• 많은 워크플로 시스템은 첫날부터 그런 수준의 인프라가 필요하지 않으며, 상태 요구보다 더 큰 인프라로 시작할 필요가 없음
• 로컬 SQLite 데이터베이스, S3로의 Litestream 백업, 저렴한 워커 조합만으로도 적은 인프라의 내구 시스템을 만들 수 있으며, AI 에이전트 영역에서는 합리적인 기본값이 될 수 있음