SQLite vs MySQL: którą bazę danych wybrać?

Dwa różne kształty bazy danych

SQLite i MySQL mówią w SQL i obie przechowują wiersze w tabelach, ale sposób, w jaki wpasowują się w system, jest zupełnie inny. SQLite to biblioteka: aplikacja linkuje się z nią i czyta z pliku na dysku. MySQL to serwer: osobny proces, z którym łączysz się przez gniazdo lub sieć.

To jedno rozróżnienie kształtuje całą resztę: jak je instalujesz, ilu piszących może pracować naraz, jak robisz kopie zapasowe, jak wdrażasz. Większość pytań o SQLite vs MySQL to w gruncie rzeczy pytania o bazę wbudowaną kontra klient-serwer.

-- SQLite: otwierasz plik i masz bazę danych.
sqlite3 app.db

-- MySQL: łączysz się z działającym serwerem.
mysql -h localhost -u root -p

Polecenie SQLite otwiera (lub tworzy) plik. Polecenie MySQL otwiera połączenie z procesem, który musi już działać, być skonfigurowany i przyjmować logowania.

Architektura: baza wbudowana kontra klient-serwer

W aplikacji z SQLite silnik bazy działa wewnątrz twojego programu. Nie ma portu, demona ani systemctl start. Wywołanie biblioteki sqlite3 czyta i zapisuje strony bezpośrednio z pliku na dysku.

MySQL działa odwrotnie. Serwer mysqld przechowuje dane, zarządza połączeniami, egzekwuje uprawnienia, uruchamia planer zapytań i obsługuje blokady. Twoja aplikacja to klient, który wysyła teksty SQL przez sieć i odbiera wiersze wyników.

Praktyczne konsekwencje:

• Wdrożenie. SQLite przychodzi razem z aplikacją: jeden plik wykonywalny, jeden plik bazy. MySQL wymaga osobnego serwera, który trzeba zainstalować, zabezpieczyć, monitorować i archiwizować.
• Dostęp sieciowy. MySQL wystawia port, więc wiele serwerów aplikacji może łączyć się z tą samą bazą. SQLite zakłada jeden proces (albo kilka współpracujących procesów) na tej samej maszynie.
• Uprawnienia. MySQL ma użytkowników, role i instrukcje GRANT. Jedyny system uprawnień w SQLite to uprawnienia systemu plików do pliku bazy.

Żaden z tych kształtów nie jest "lepszy". Rozwiązują różne problemy.

Współbieżność i zapisy

Tu obie bazy naprawdę się rozchodzą. Silnik InnoDB w MySQL blokuje na poziomie wierszy: wiele połączeń może jednocześnie zapisywać różne wiersze, nie blokując się nawzajem.

SQLite szereguje zapisy na poziomie całej bazy. Jeden piszący naraz i koniec. Czytający mogą działać równolegle z piszącym (zwłaszcza w trybie WAL), ale drugi piszący czeka na swoją kolej.

-- SQLite: to dobrze działa dla wielu czytających i jednego piszącego naraz.
PRAGMA journal_mode = WAL;

-- MySQL: wielu piszących, precyzyjne blokady.
-- (Bez specjalnej konfiguracji: InnoDB robi to domyślnie.)

W aplikacji z jednym lub dwoma procesami i umiarkowaną liczbą zapisów (narzędzie desktopowe, aplikacja mobilna, mały CMS) szeregowane zapisy SQLite są zwykle na tyle szybkie, że nigdy tego nie zauważysz. W obciążonej usłudze webowej z setkami połączeń, które jednocześnie wstawiają zamówienia lub aktualizują sesje, blokowanie na poziomie wierszy w MySQL to różnica między "w porządku" a "wszystko stoi w kolejce za jedną blokadą".

Typy danych

MySQL ma długą, ścisłą listę typów: TINYINT, INT, BIGINT, VARCHAR(n), DATETIME, DECIMAL(p,s), BLOB, JSON i wiele innych. Zadeklaruj kolumnę jako INT, a MySQL odrzuci tekst.

SQLite zamiast tego używa powinowactwa typów (type affinity). Typy kolumn to wskazówki, a nie egzekwowane reguły. Możesz wstawić tekst do kolumny INTEGER, a SQLite go zapisze (chyba że użyjesz tabel STRICT, dodanych w wersji 3.37).

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL
);

INSERT INTO products (name, price) VALUES ('Kawa', 3.50);
INSERT INTO products (name, price) VALUES ('Herbata', '2.75');  -- tekst w kolumnie REAL

SELECT id, name, price, typeof(price) FROM products;

Oba wiersze wstawiają się bez błędu. Ta elastyczność jest wygodna przy prototypowaniu i zaskakująca, gdy oczekujesz bezpieczeństwa typów na poziomie bazy. Używaj tabel STRICT, gdy chcesz w SQLite egzekwowania typów w stylu MySQL.

Różnice w składni, na które faktycznie trafisz

Większość podstawowego SQL (SELECT, JOIN, WHERE, GROUP BY) jest identyczna. Różnice skupiają się w kilku obszarach:

• Automatycznie rosnące klucze główne. SQLite używa INTEGER PRIMARY KEY (który domyślnie rośnie automatycznie). MySQL używa INT AUTO_INCREMENT PRIMARY KEY.
• Cytowanie identyfikatorów. MySQL pozwala na grawisy wokół identyfikatorów (`table`). SQLite używa cudzysłowów ("table") zgodnie ze standardem SQL.
• Funkcje dat. MySQL ma NOW(), CURDATE(), DATE_ADD(). SQLite ma datetime('now'), date('now'), datetime('now', '+1 day').
• Składnia LIMIT. Obie obsługują LIMIT n OFFSET m, więc tu wszystko jest zgodne.
• Wartości logiczne. MySQL ma BOOLEAN (alias TINYINT(1)). SQLite przechowuje wartości logiczne jako 0 i 1 w kolumnach INTEGER.

-- MySQL
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    created_at DATETIME DEFAULT NOW()
);

-- SQLite
CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    created_at TEXT DEFAULT (datetime('now'))
);

Ta sama intencja, inne słowa kluczowe. Model myślowy się przenosi, a składnia wymaga drobnej korekty.

Wydajność: to zależy od pytania

Na pytanie "czy SQLite jest szybszy niż MySQL?" nie ma jednej odpowiedzi.

Dla jednego procesu wykonującego lokalne odczyty i zapisy SQLite jest często szybszy: nie ma przejścia przez sieć, komunikacji między procesami ani parsera zapytań działającego w osobnej przestrzeni adresowej. SELECT w SQLite to w zasadzie wywołanie funkcji.

Przy wielu współbieżnych połączeniach zapisujących do tej samej bazy MySQL wychodzi na prowadzenie dzięki blokowaniu na poziomie wierszy. Model z jednym piszącym w SQLite sprawia, że przy takim obciążeniu szybko pojawia się rywalizacja o blokadę.

Przy obciążeniach z przewagą odczytów i włączonym trybem WAL SQLite skaluje się zaskakująco dobrze: czytający nie blokują ani siebie nawzajem, ani jedynego piszącego. Wiele produkcyjnych stron obsługuje prawdziwy ruch z SQLite.

Nie wybieraj na podstawie benchmarków przeczytanych w internecie. Wybieraj na podstawie tego, jak faktycznie korzystasz z danych.

Kiedy która jest właściwym wyborem

Sięgnij po SQLite, gdy:

• Baza działa obok jednej aplikacji (aplikacja mobilna, narzędzie desktopowe, CLI, mała strona).
• Chcesz wdrożenia bez konfiguracji: po prostu dostarczasz plik.
• Odczytów jest znacznie więcej niż zapisów albo zapisy są rzadkie.
• Potrzebujesz wbudowanej bazy testowej, która odzwierciedla produkcyjny SQL.
• Prototypujesz i nie chcesz jeszcze myśleć o serwerze.

Sięgnij po MySQL, gdy:

• Wiele serwerów aplikacji musi dzielić jedną bazę.
• Masz wielu współbieżnych piszących.
• Potrzebujesz precyzyjnych uprawnień użytkowników i zarządzania rolami.
• Budujesz na stosie (LAMP, typowe zarządzane usługi w chmurze), który zakłada MySQL.
• Narzędzia operacyjne (replikacja, odtwarzanie do punktu w czasie, monitoring) są twardym wymaganiem.

Z grubsza: jeśli swoje potrzeby opisujesz jako "jedna aplikacja, jeden dysk", SQLite prawdopodobnie wystarczy. Jeśli mówisz "usługa, z zespołem utrzymania", sięgnij po MySQL (albo PostgreSQL).

Migracja między nimi

Start z SQLite i przejście później na MySQL to dobrze przetarta ścieżka i całkiem rozsądny plan. Schematy przenoszą się z drobnymi poprawkami, a dane czysto eksportuje się przez .dump z SQLite CLI. Głównie poprawiasz składnię automatycznie rosnących kluczy, funkcje dat i funkcje specyficzne dla SQLite (indeksy częściowe o nietypowych kształtach, WITHOUT ROWID, tabele STRICT), które nie mają bezpośrednich odpowiedników w MySQL.

Kierunek odwrotny, z MySQL do SQLite, jest rzadszy, ale też wykonalny, zwykle na potrzeby analiz offline, wbudowanych kopii części danych albo danych testowych.

Sedno: wybór SQLite dziś nie zamyka ci drogi. SQL, który piszesz, przenosi się dalej, podobnie jak twoje zrozumienie.

Dalej: SQLite vs PostgreSQL

MySQL to najczęstsze porównanie, ale PostgreSQL to druga baza, z którą zestawia się SQLite, a tamte różnice znów są inne. O nich jest następna strona.