Cos'è SQLite? Il database SQL embedded spiegato

SQLite è un database dentro il tuo programma

La maggior parte dei database di cui hai sentito parlare (MySQL, Postgres, SQL Server) gira come programma separato. Avvii un server, questo resta in ascolto su una porta e la tua applicazione si collega via rete per fargli domande. SQLite butta via tutto questo modello.

SQLite è una libreria. La colleghi al tuo programma e ti dà un database SQL che vive in un unico file su disco. Niente server, niente porta, niente demone, niente pg_ctl start. La tua applicazione apre un file, e quel file è il database.

sqlite3 mydata.db

Quel comando apre (o crea) un file chiamato mydata.db e ti dà un prompt SQL. Tutto quello che fai (tabelle, righe, indici) viene salvato in quell'unico file. Copialo su un'altra macchina e il database viaggia con lui. Eliminalo e il database non c'è più.

Un giro veloce nell'SQL

L'SQL in sé è come l'SQL di qualsiasi altro database. Se ne hai già usato un altro, quasi tutto ti sembrerà familiare:

CREATE TABLE books (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    author TEXT NOT NULL,
    year   INTEGER
);

INSERT INTO books (title, author, year) VALUES
    ('The Left Hand of Darkness', 'Ursula K. Le Guin', 1969),
    ('Project Hail Mary',         'Andy Weir',         2021),
    ('Piranesi',                  'Susanna Clarke',    2020);

SELECT title, year FROM books ORDER BY year DESC;

SQL standard: CREATE TABLE, INSERT, SELECT, ORDER BY. SQLite supporta le parti dello standard SQL che usi davvero ogni giorno, più comodità moderne come le CTE, le funzioni finestra e le funzioni JSON. Le differenze rispetto a Postgres o MySQL riguardano soprattutto i tipi e alcune stranezze di sintassi, che vedremo più avanti.

Cosa significano davvero "embedded" e "serverless"

Con SQLite saltano fuori continuamente due parole. Vale la pena chiarirle.

Embedded significa che SQLite gira nello stesso processo della tua applicazione. Non c'è un processo del database separato. Quando il tuo script Python chiama sqlite3.connect("data.db"), il motore SQL gira dentro il tuo processo Python, leggendo e scrivendo direttamente il file.

Serverless significa che non c'è nessun server da installare, configurare, avviare, proteggere o di cui fare il backup. Confronta i passaggi per iniziare a usare un database:

• Postgres: installa Postgres, avvia il servizio, crea un utente, crea un database, configura pg_hba.conf, collegati via TCP.
• SQLite: apri un file.

Tutta la differenza è qui. Meno potenza, molte meno cerimonie.

L'intero database è un solo file

Questa è la parte che sorprende. Il formato del file è documentato e stabile: un file .db (o .sqlite, o .sqlite3, l'estensione è solo una convenzione) che puoi:

• Mandare per email a un collega.
• Salvare in git (almeno quelli piccoli).
• Copiare con cp per un backup istantaneo.
• Aprire con qualsiasi strumento SQLite su qualsiasi sistema operativo.

ls -lh mydata.db
# -rw-r--r--  1 you  staff   28K  Apr 23 14:02 mydata.db

Quell'unico file contiene le tue tabelle, i tuoi indici, il tuo schema e i tuoi dati. I database SQLite su disco sono identici byte per byte su Windows, macOS, Linux, iOS e Android. Il formato è così stabile che la Library of Congress degli Stati Uniti lo raccomanda per la conservazione dei dati a lungo termine.

Dove stai già usando SQLite

Quasi certamente sul dispositivo da cui stai leggendo ci sono centinaia di database SQLite. Alimenta:

• L'archiviazione di sistema di iOS e Android e molte app su entrambe le piattaforme.
• Firefox, Chrome e Safari (cronologia, segnalibri, cookie).
• macOS (Mail, Foto, il Dock).
• La maggior parte delle app desktop Linux che hanno bisogno di archiviazione locale.
• Skype, WhatsApp, Signal: la cronologia delle chat.
• I cataloghi di Adobe Lightroom, i metadati di Dropbox, le librerie di Steam.

È stato definito il motore di database più diffuso al mondo, ed è probabilmente vero. Il motivo è semplice: quando un'applicazione ha bisogno di archiviazione locale strutturata, SQLite è la strada più facile.

Cosa SQLite non è

Non è un database client server. Due programmi su macchine diverse non possono collegarsi entrambi via rete a un database SQLite: non c'è uno strato di rete a cui collegarsi. Se ti serve questo, ti serve Postgres o MySQL.

Non è fatto per un'alta concorrenza in scrittura. SQLite usa lock a livello di file (con alcune ottimizzazioni intelligenti in modalità WAL), quindi mentre molti lettori possono lavorare in parallelo, solo uno scrittore alla volta può fare il commit. Per un'app con un solo utente o un sito web con poco traffico non è un problema. Per un SaaS multi tenant che riceve migliaia di scritture al secondo è lo strumento sbagliato.

Non gestisce utenti o permessi. L'accesso al database è accesso al file: chi può leggere il file può leggere i dati. Va bene per un'app che possiede il proprio file di database. Non va bene per una configurazione condivisa multi tenant.

Perché sceglierlo

Lo scambio è semplicità in cambio di un margine di crescita che forse non ti servirà mai:

• Zero configurazione. Nessun servizio da far girare. Nessuna differenza di versione tra sviluppo e produzione. Nessun "il database è giù", perché non c'è nessun server di database.
• Veloce. Per la maggior parte dei carichi di lavoro, soprattutto quelli con tante letture, SQLite è più veloce di un database di rete: non c'è un viaggio di andata e ritorno sul socket a ogni query.
• Affidabile. Viene testato in modo ossessivo. Il progetto SQLite ha molto più codice di test che codice sorgente, e il formato è stabile dal 2004.
• Di pubblico dominio. Gratuito per qualsiasi uso, anche commerciale. Nessuna licenza da leggere.
• Portabile. Un solo file, su ogni piattaforma.

Per app locali, prototipi, dispositivi embedded, strumenti da riga di comando, suite di test, script di analisi dei dati e siti web piccoli e medi, SQLite spesso è la scelta predefinita corretta, non un trampolino verso un database "vero".

Prossimo passo: SQLite vs MySQL

Una domanda naturale a questo punto è come se la cava SQLite rispetto ai database server di cui hai probabilmente sentito parlare di più. Iniziamo da MySQL: dove vince ciascuno e come capire quale si adatta al progetto che hai davanti.