O disco não era o vilão. O LIST era.

01 O que estava acontecendo

Em 29 de setembro de 2026 nasceu o bucket cleat-litestream-840298254452, região us-east-1, com versioning ligado no create. No mesmo dia o Cost Explorer deixa de ser US$ 0,09 (só storage) e vira tempestade de ListBucket.

O processo cleat-litestream (Litestream 0.5.17) replica 27 arquivos SQLite de apps no cx33 para S3, sync-interval: 1s. Cada ciclo lista gerações e WAL. No S3, LIST custa o mesmo que PUT: US$ 0,005 por mil. Disco quase não pesava. API, sim.

Fatura diária de S3

Escala relativa a 30/set = US$ 9,19. *3/out ainda parcial no Cost Explorer, cutover ~19:00 UTC.

Outubro 1–3 por operação

360 mil LIST/dia × US$ 0,005 / mil = US$ 1,80/dia. Em 30 dias, US$ 54 só para o sidecar perguntar “tem arquivo aí?”.

02 O que foi feito

Decisão: o workload é LIST-pesado. No Backblaze B2, desde 1º de maio de 2026, Class A/B/C (PUT/LIST/GET) é grátis no pay-as-you-go. Storage US$ 6,95/TB, 10 GB free. A conta B2 da casa já existia (OpenDrive / rclone b2stash). Bucket próprio — não misturar réplica de SQLite com arquivo de cliente.

• 29 set 11:22 · us-east-1
  Cria cleat-litestream-840298254452 com versioning. 130 mil LIST no mesmo dia.
• 30 set
  Pico: 341 mil LIST + 81,5 GB de GET. Dia inteiro US$ 9,19.
• 1–2 out
  Platô: 360–366 mil LIST/dia, ~US$ 1,89/dia. Ritmo de US$ 54/mês só de listagem.
• 3 out ~19:00 UTC
  Cutover. Bucket B2 cleat-litestream-phoenix (us-east-005, endpoint S3-compatible). 27 réplicas no litestream.yml. Credenciais no litestream.env. Unidade reiniciada.
• 3 out 19:04 UTC
  Dez DBs com LTX local podre (cleat, cardápio, OpenDrive, PratoAI, Purple Stock, NFe, Markdown, Igreja, Pay Core) receberam litestream reset. Snapshot fresco no B2. Zero ERROR depois.
• 3 out 19:00:45Z
  Último write no S3 antigo. Bucket congelado. B2 com 26 prefixos, ~53 MB, WAL do cleat.db fluindo.
• 3 out, em seguida
  Esvaziamento do S3: 96.946 versões e delete markers apagados. 0 objeto, 0 versão, 0 marker. Bucket vazio, ainda existe.

Estado depois

Rollback no host: /etc/cleat_deploy/litestream.yml.bak-s3-* e litestream.env.bak-s3-*. O exemplo em cleat-web/deploy/litestream.yml.example agora documenta B2 e o custo de LIST no S3.

03 Post-mortem

Causa raiz

Um sidecar único replicando 27 SQLite para S3 com sync de 1 segundo, num bucket versionado. A API ListBucket é Tier-1. Retention do Litestream apaga WAL; o versioning do S3 transforma isso em dezenas de milhares de versões e delete markers. A fatura cobra a pergunta, não o arquivo.

Cinco porquês

1. Por que a fatura S3 subiu? Porque ListBucket foi a ~360 mil/dia a partir de 29/set.
2. Por que tantos LIST? Porque o Litestream 0.5 lista gerações/WAL a cada sync, em 27 bancos.
3. Por que no S3? Porque o replica remoto foi apontado para um bucket AWS no cutover de 29/set, sem modelo de custo de request.
4. Por que o storage também inchou? Porque versioning foi ligado no create; delete de WAL virou versão morta.
5. Por que ninguém viu no dia 1? Não havia alarme de Requests-Tier1 / ListBucket. O sinal foi a fatura humana.

O que não fazer de novo

• Não ligar versioning em bucket de Litestream. WAL é imutável; versão só atrapalha.
• Não mandar LIST de 1s × N bancos para um object store que cobra LIST = PUT.
• Não misturar réplica SQLite em open-drive-phoenix.
• Não apontar cardápio/catálogo para B2 sem S3_ENDPOINT — outro problema, outro adapter.
• R2 não resolve este formato: Class A ainda custa ~US$ 4,50/milhão (~US$ 49/mês neste ritmo).

Ações

Lição numa linha: backup contínuo de SQLite é um gerador de LIST. Escolha um store que não cobre pergunta — ou pergunte bem menos.