O datasette-upload-dbs 0.5a0 ganha API para trocar bancos SQLite em produção
O plugin de Simon Willison agora tem endpoint HTTP para subir e substituir arquivos SQLite num Datasette hospedado, o que abre caminho para deploy de dados via CI.
Se você já precisou compartilhar um dataset e caiu na armadilha de montar um backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → 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↳SQL64 conteúdosSQL Server – Como evitar SQL Injection?Data · mai 2019Azure SQL DB Managed InstanceData · abr 2019SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query)Data · abr 2019Ver tudo em Data → 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:
- Um job agendado (ou disparado por commit) roda seu script que gera o
content.dba partir das fontes (scraping, dump de outro banco, API externa, etc.). - No final do job, um
curlcomo o de cima envia o arquivo para a instância. - 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
Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial do iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Diego Lima. Saiba como produzimos no expediente.
Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.
Comentários
Ninguém comentou ainda. Começa a conversa?