Kiedy używać SQLite: zastosowania, ograniczenia i kiedy odpuścić

Kluczowe pytanie

SQLite nie jest mniejszą wersją Postgresa. To narzędzie o innym kształcie. Cała baza to plik na dysku, a twoja aplikacja komunikuje się z nią przez bibliotekę dołączoną do tego samego procesu: bez serwera, bez sieci, bez użytkowników. Ta konstrukcja sprawia, że SQLite jest genialny do jednych zadań i słabo pasuje do innych.

Rozstrzygające pytanie prawie nigdy nie brzmi „czy SQLite jest wystarczająco szybki?” (zwykle jest). Brzmi: „czy kształt mojej aplikacji pasuje do tego, w czym SQLite jest dobry?”. Decydują o tym głównie dwie rzeczy: gdzie są dane i ile rzeczy zapisuje do nich jednocześnie.

Używaj SQLite, gdy dane są przy aplikacji

SQLite błyszczy, gdy baza należy do jednej aplikacji na jednej maszynie. Plik leży obok twojego kodu, aplikacja otwiera go bezpośrednio i to cała architektura.

-- Typowy schemat, w którym „dane są przy aplikacji”:
-- lokalny magazyn desktopowej aplikacji do notatek.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Groceries', 'milk, bread, coffee'),
    ('Ideas',     'sqlite tutorial outline');

SELECT id, title, created FROM notes;

Ten maleńki schemat mógłby być całym backendem prawdziwej aplikacji. Kilka przypadków, w których ten wzorzec pasuje naturalnie:

• Aplikacje desktopowe i mobilne. Każda aplikacja na iOS i Androida, która potrzebuje ustrukturyzowanego lokalnego magazynu, używa pod spodem SQLite. Podobnie Firefox, Chrome i większość przeglądarek.
• Narzędzia CLI. git, menedżery pakietów i menedżery plików konfiguracyjnych używają wbudowanych baz danych.
• Urządzenia wbudowane. Routery, samochody, samoloty: wszystko, co potrzebuje bazy danych zajmującej kilkaset kilobajtów.
• Zestawy testów. Świeży plik SQLite (albo baza :memory:) dla każdego testu jest szybszy i lepiej izolowany niż uruchamianie Postgresa.

Jeśli twoje dane nie muszą być współdzielone między wieloma maszynami, SQLite to prawdopodobnie właściwa odpowiedź.

Używaj SQLite na stronach, które głównie czytają

SQLite świetnie radzi sobie z odczytami. Wielu współbieżnych czytelników, zero rywalizacji, zapytania przez indeks w mikrosekundach. Jeśli na twojej stronie ludzie głównie czytają treści (blogi, dokumentacja, strony marketingowe, małe panele SaaS), SQLite da radę bez problemu, często lepiej niż Postgres podłączony przez sieć, bo nie ma podróży tam i z powrotem.

-- Tabela wpisów bloga.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hello-world', 'Hello, World', 'First post.', '2024-01-01'),
    ('sqlite-rocks', 'Why SQLite',  'Single-file DB.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

Haczyk tkwi w zapisach. SQLite wykonuje zapisy po kolei: blokadę może trzymać tylko jeden piszący naraz. Na blogu z kilkoma autorami tego nie widać. W aplikacji czatu, w której tysiące użytkowników wysyła wiadomości co sekundę, to problem.

Tryb WAL (write-ahead logging, omawiany później) znacznie podnosi ten sufit, bo pozwala czytelnikom i piszącemu działać równolegle. Mnóstwo produkcyjnych stron obsługuje miliony żądań dziennie na SQLite + WAL.

Używaj SQLite do lokalnych cache i danych roboczych

Zawsze gdy potrzebujesz ustrukturyzowanego lokalnego magazynu, czyli czegoś więcej niż plik JSON, ale mniej niż pełny serwer bazy danych, trudno pobić SQLite.

-- Tabela cache dla klienta HTTP.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

Logi, bufory analityczne, etapy pośrednie ETL, magazyny cech dla uczenia maszynowego, indeksy IDE: to wszystko naturalne miejsca dla SQLite. Plik jest przenośny, język zapytań to pełny SQL i nie ma serwera, którego trzeba pilnować.

Nie używaj SQLite przy wielu współbieżnych piszących

To ograniczenie, na którym ludzie się łapią. SQLite używa blokady zapisu na poziomie całej bazy: jeden piszący i koniec. Dwa procesy próbujące wstawiać dane w tej samej chwili oznaczają, że jeden czeka.

W większości aplikacji to nie ma znaczenia: zapisy są rzadkie i szybkie. Ale jeśli twoje obciążenie wygląda tak:

• wielodostępny SaaS z tysiącami użytkowników zapisujących jednocześnie,
• wysokowydajna kolejka wiadomości albo dziennik zdarzeń,
• backend gry czasu rzeczywistego albo czatu ze stałymi zmianami stanu,

to SQLite stanie się wąskim gardłem. Postgres i MySQL używają blokad na poziomie wierszy i zostały zbudowane dokładnie do tego. Sięgnij po nie.

-- Błąd, który zobaczysz, gdy piszący się spiętrzą:
Error: database is locked

Jeśli widzisz to przy normalnym obciążeniu, SQLite to złe narzędzie, a nie błąd do obejścia.

Nie używaj SQLite na wielu maszynach

SQLite to biblioteka działająca w procesie. Aplikacja czyta i zapisuje plik bezpośrednio, co oznacza, że plik musi być na dysku, do którego aplikacja może robić read() i write() zwykłymi wywołaniami systemu plików.

To wyklucza:

• Wiele serwerów aplikacji za load balancerem, które chcą współdzielić jedną bazę. (Sieciowe systemy plików, takie jak NFS, technicznie działają, ale pod obciążeniem uszkadzają plik. Nie rób tego.)
• Funkcje serverless, w których każde wywołanie działa na innej maszynie.
• Pody Kubernetesa, które potrzebują współdzielonej bazy, chyba że używasz wdrożenia z jednym podem i trwałym woluminem.

Jeśli w twojej architekturze do bazy zapisuje więcej niż jeden proces na więcej niż jednej maszynie, potrzebujesz bazy klient-serwer. Tu przebiega granica.

Nie używaj SQLite, gdy potrzebujesz użytkowników bazy danych

SQLite nie zna pojęcia użytkowników, ról ani uprawnień. Baza to plik: kto może go odczytać, może odczytać wszystko; kto może go zapisać, może zapisać wszystko. Kontrola dostępu to zadanie systemu operacyjnego.

W jednoosobowej aplikacji desktopowej to w porządku. W systemie wielodostępnym, w którym różne osoby potrzebują różnych uprawnień wewnątrz bazy, wybierz Postgresa albo MySQL.

Szybka lista kontrolna

Przejdź przez tę listę. Jeśli na wszystkie punkty odpowiesz „tak”, SQLite to prawdopodobnie świetny wybór:

• Baza jest na tej samej maszynie co aplikacja.
• Komunikuje się z nią jeden proces (albo kilka, głównie czytających).
• Wszystkie dane swobodnie mieszczą się na jednym dysku: terabajty są w porządku, ale to wciąż jeden dysk.
• Nie potrzebujesz uprawnień użytkowników na poziomie bazy.
• Współbieżne zapisy zdarzają się okazjonalnie i nie dominują w obciążeniu.

Jeśli którakolwiek odpowiedź brzmi „nie”, przyjrzyj się Postgresowi albo MySQL. Dwie kolejne strony porównują je bezpośrednio.

Co warto zapamiętać

• SQLite to właściwy wybór, gdy baza jest lokalna dla aplikacji: desktop, mobile, urządzenia wbudowane, narzędzia CLI, zestawy testów, strony głównie do czytania, lokalne cache.
• Nadaje się do produkcji: działa na miliardach urządzeń. Ograniczenia wynikają z architektury, a nie z jakości.
• Odpuść ją, gdy potrzebujesz wielu współbieżnych piszących, dostępu z wielu maszyn albo uprawnień dla poszczególnych użytkowników bazy.

Dalej: instalacja SQLite

Dość teorii. Następna strona pokazuje, jak zainstalować SQLite na swoim komputerze (na macOS i w większości dystrybucji Linuksa już jest, a na Windowsie wystarczy jedno pobranie) i sprawdzić instalację z wiersza poleceń.