Plugin Datasette permette di caricare e sostituire database SQLite via API

datasette-upload-dbs 0.5a0 introduce un endpoint stabile per caricare o sostituire database SQLite su un’istanza Datasette. Il rilascio è datato 11 agosto 2026. Lo scambio avviene in modo atomico dopo una verifica del file, così l’URL esposto non cambia e passa a servire la nuova copia solo a controllo concluso¹.

Il percorso è unico: POST a /-/upload-dbs. La richiesta arriva come multipart/form-data con due campi. db contiene il file .db. db_name indica il nome con cui l’istanza esporrà il database. L’esempio mostra anche Accept: application/json e un Bearer token per l’autorizzazione¹.

Comando completo, come pubblicato: curl -X POST -H "Authorization: Bearer $API_TOKEN" -H "Accept: application/json" -F "db=@content.db" -F "db_name=content" https://your-instance.example.com/-/upload-dbs Con la stessa chiamata si aggiunge un nuovo database o si sostituisce quello esistente che ha lo stesso nome. In entrambi i casi, il server salva il file, lo verifica, poi effettua lo scambio. Solo allora l’istanza inizia a servirlo all’URL /name¹.

L’operazione è pensata per l’uso in produzione. Si prepara il file offline. Lo si invia all’endpoint. Se il nome è nuovo, l’istanza aggiunge il database e lo rende disponibile subito dopo la verifica. Se il nome coincide con un database già presente, lo rimpiazza con scambio atomico al termine dei controlli. Questo evita finestre in cui l’URL punterebbe a un database parziale o corrotto¹.

Il flusso riduce i passaggi applicativi al minimo. Una singola richiesta autenticata carica, verifica e pubblica. Nessuna procedura manuale di deploy, nessun riavvio dell’istanza, nessun intervento sui file interni. La semplificazione è chiara nel comando d’esempio: campi espliciti, intestazioni dichiarate, percorso pubblico e stabile. Il plugin documenta ciò che prima era un comportamento possibile ma non formalizzato, e lo espone come API definita¹.

C’è un caso d’uso diretto per le pipeline. La pagina di annuncio propone di costruire i database in strumenti come GitHub Actions e sostituirli in produzione al termine della build. La pipeline crea il file .db e invia la POST all’endpoint. L’istanza adotta la nuova versione appena superata la verifica, senza cambiare l’URL pubblico. La combinazione tra build automatica e scambio atomico consente pubblicazioni periodiche affidabili, con tempi di fermo nulli dal punto di vista dell’utente¹.

Chi mantiene dati aggiornati con cadenze fisse può così standardizzare il rilascio: un task produce il database, un altro invia la richiesta con db e db_name, e la piattaforma gestisce il resto. In sistemi che integrano più fonti, questo consente cicli di refresh prevedibili e isolati, con rollback implicito legato alla verifica: se il file non supera i controlli, lo scambio non parte e l’URL continua a servire la copia precedente¹.