O datasette-upload-dbs 0.5a0 ganha API para trocar bancos SQLite em produção

Se você já precisou compartilhar um dataset e caiu na armadilha de montar um backend inteiro só pra servir umas tabelas, o Datasette é um velho conhecido: ele pega um arquivo SQLite e expõe uma interface web navegável, com filtros, JSON API e SQL sob demanda. O plugin datasette-upload-dbs sempre resolveu a ponta que faltava (colocar dados lá dentro sem SSH). A versão 0.5a0, anunciada por Simon Willison, formaliza isso numa API HTTP, e essa é a mudança que interessa pra quem constrói pipeline.

O que o plugin faz

A ideia é simples: você tem uma instância do Datasette hospedada e quer subir um banco SQLite novo, ou trocar um existente por uma versão mais recente, sem redeploy da aplicação. O plugin recebe o arquivo, salva em disco, verifica e só então faz o swap atômico, de forma que /nome-do-banco passa a servir a versão nova sem servir um arquivo corrompido no meio do caminho.

Esse detalhe do swap atômico é o que separa "gambiarra de scp" de algo confiável em produção: o banco antigo continua respondendo até o novo estar validado.

A novidade: uma API formalizada

Até agora o upload era essencialmente uma ação de interface. A 0.5a0 expõe um endpoint que você chama por HTTP, com autenticação via bearer token:

curl -X POST \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Accept: application/json" \
  -F "db=@content.db" \
  -F "db_name=content" \
  https://sua-instancia.example.com/-/upload-dbs

É um multipart/form-data: db é o arquivo SQLite e db_name é o nome sob o qual ele será servido. Se content já existir, ele é substituído; se não, é criado.

Por que isso muda o fluxo

O ganho prático está em fechar o ciclo com CI. Como o próprio Willison aponta, dá pra construir o banco num ambiente como GitHub Actions e fazer o swap em produção assim que o build terminar. O padrão fica assim:

1. Um job agendado (ou disparado por commit) roda seu script que gera o content.db a partir das fontes (scraping, dump de outro banco, API externa, etc.).
2. No final do job, um curl como o de cima envia o arquivo para a instância.
3. O Datasette valida e troca. Os visitantes veem os dados atualizados sem nenhum downtime perceptível.

Para quem trabalha com dados no Brasil, isso é especialmente útil naquele cenário de dataset público derivado: você agrega dados abertos (transparência, IBGE, câmaras municipais), gera um SQLite e quer publicar uma versão navegável atualizada toda semana. Em vez de reprocessar num servidor caro, você joga o trabalho pesado no CI (que roda de graça em repositório público) e mantém a instância do Datasette enxuta, só servindo.

Para quem é (e para quem não é)

Vale para: quem publica ou explora datasets de leitura, precisa de uma UI decente sem escrever frontend, e já pensa em automação. O SQLite brilha em cenário read-heavy, então blogs de dados, catálogos e dashboards de consulta são o encaixe natural.

Não é para: aplicação transacional com escrita concorrente pesada. O modelo aqui é "gerar o banco fora, servir dentro", não "escrever ao vivo na produção". E vale lembrar que 0.5a0 é um alpha, o a0 no fim do número não é decoração. A API é nova e formalizada, mas trate como algo a validar em staging antes de apoiar um pipeline crítico em cima dela, principalmente na gestão dos tokens de autenticação.

Onde começar

Se você nunca usou o Datasette, o caminho mais curto é instalar localmente, apontar para um .sqlite qualquer e ver a interface subir. Depois instala o plugin no ambiente hospedado (datasette install datasette-upload-dbs), configura o token e testa o curl acima contra staging. O ecossistema de plugins do Datasette é um dos pontos fortes do projeto, e essa API abre espaço pra automações que antes exigiam acesso direto ao servidor.

É uma ferramenta de nicho, mas resolve bem um problema real: publicar dados sem carregar o peso de um backend completo.

Fonte: Simon Willison