Wbudowane bazy danych (SQLite i Turso / libSQL)

1. Przegląd koncepcji i problem systemowy

Przemysłowy odruch wdrażania dedykowanego klastra klient-serwer baz danych (PostgreSQL, MySQL) dla każdego nowego projektu często prowadzi do przedwczesnego skomplikowania architektury:

• Opóźnienie sieciowe (Network Hop Overhead): każde zapytanie SQL musi zostać opakowane w pakiet TCP, przejść przez stos sieciowy, zostać autoryzowane na serwerze bazy danych i wrócić. Dodaje to od 5 do 20 ms sztucznego opóźnienia do każdej operacji.
• Wyczerpanie puli połączeń (Connection Exhaustion): w środowiskach bezserwerowych (Serverless / Edge) setki równoległych funkcji lambda szybko przekraczają limity połączeń PostgreSQL (max_connections), wymuszając instalację kosztownych pulerów ruchu (PgBouncer).
• Koszty operacyjne: utrzymanie, monitorowanie i aktualizacja osobnego serwera bazy danych generuje wydatki rzędu 25–100 USD miesięcznie, nawet dla projektów o umiarkowanym ruchu.

SQLite oraz Turso (libSQL) odwracają tę perspektywę. Zamiast wysyłać zapytania przez sieć, silnik bazy danych jest kompilowany bezpośrednio do kodu binarnego aplikacji (In-Process Engine). Zapytania do bazy stają się szybkimi wywołaniami funkcji w pamięci: czas odpowiedzi rzędu submilisekund (50–200 mikrosekund), zerowy narzut sieciowy oraz przechowywanie całego systemu w jednym zwartym pliku.

2. Taksonomia architektoniczna i model mentalny

Cechy architektoniczne wbudowanych i rozproszonych baz danych:

┌─────────────────────────────────────────────────────────────┐
│                 ARCHITEKTURA BAZ DANYCH IN-PROCESS & EDGE    │
├─────────────────────────────────────────────────────────────┤
│ 1. Wykonanie w procesie (Zero Network Overhead):            │
│    Pamięć aplikacji (V8 / Go / Rust) ➔ Bezpośrednie wywołania systemowe ➔ Dysk     │
├─────────────────────────────────────────────────────────────┤
│ 2. Model współbieżności: WAL (Write-Ahead Logging)             │
│    • Wielu równoległych czytelników (Równoległe odczyty bez blokowania) │
│    • Dokładnie jeden aktywny zapisujący (Szybki, sekwencyjny zapis)    │
├─────────────────────────────────────────────────────────────┤
│ 3. Rozproszona warstwa Edge (Turso / libSQL):                  │
│    • Lokalizacja główna (Przyjmowanie operacji zapisu)              │
│    • Repliki brzegowe (Odczyty z pamięci w ponad 30 centrach danych)   │
│    • Wbudowane repliki (Lokalna kopia z synchronizacją w tle)    │
├─────────────────────────────────────────────────────────────┤
│ 4. Integracja AI i wektorów: sqlite-vec (Wyszukiwanie wektorowe)    │
└─────────────────────────────────────────────────────────────┘

1. Wykonanie in-process (In-Process Engine):
   • Baza danych nie jest oddzielnym procesem systemu operacyjnego. Biblioteka better-sqlite3 lub sterownik libSQL wykonują przeszukiwanie drzew B bezpośrednio w pamięci RAM hosta.
2. Logowanie z zapisem wyprzedzającym (Tryb WAL):
   • Rewolucyjny tryb współbieżności. Zmiany są zapisywane w osobnym pliku logu (app.db-wal). Pozwala to setkom wątków czytać główny plik bazy danych bez blokowania, podczas gdy jeden wątek wykonuje zapis.
3. Ewolucja chmurowa libSQL (Architektura Turso):
   • Otwarty fork SQLite stworzony przez firmę ChiselStrike. Dodaje obsługę zdalnych połączeń przez HTTP/WebSockets, integrację z WASM oraz koncepcję Embedded Replicas – aplikacja utrzymuje lokalną kopię bazy na dysku serwera i w tle synchronizuje ją z chmurą Turso.
4. Rozszerzenia wektorowe (sqlite-vec):
   • Lekka biblioteka open-source dodająca do SQLite typy danych dla osadzeń wektorowych (embeddings) oraz algorytmy wyszukiwania najbliższych sąsiadów (KNN/HNSW), przekształcając SQLite w pełnoprawną bazę wiedzy wektorowej dla agentów AI.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia transakcji w zoptymalizowanym środowisku SQLite:

1. Obowiązkowa konfiguracja pragmatów inżynierskich (Pragmas Setup): Podczas otwierania połączenia aplikacja musi wykonać podstawowe ustawienia systemowe:

   PRAGMA journal_mode = WAL;
   PRAGMA synchronous = NORMAL;
   PRAGMA foreign_keys = ON;
   PRAGMA busy_timeout = 5000;
   PRAGMA cache_size = -20000; -- 20MB оперативної пам'яті під кеш
   

2. Bezpośredni odczyt z cache stron (Page Cache Hit): Zapytanie SQL jest parsowane przez wbudowany parser w ciągu kilku mikrosekund. Jeśli strony indeksu znajdują się już w cache pamięci procesu, wynik jest zwracany klientowi w mniej niż 0,1 ms.
3. Atomowy zapis do logu WAL: Operacja mutacji danych jest dopisywana na koniec pliku WAL bez nadpisywania ciężkich, głównych drzew B.
4. Fiksacja w tle (Checkpointing): Okresowo (lub po osiągnięciu progu 1000 stron) wątek w tle zrzuca zgromadzone zmiany z logu WAL do głównego pliku bazy danych (app.db).
5. Replikacja (w przypadku użycia Litestream lub Turso): Wątki robocze w tle przechwytują zamknięte ramki WAL i transmitują je do magazynu chmurowego Cloudflare R2 lub do replik geograficznych.

4. Praktyczne scenariusze inżynierskie w produkcji

01. Wysokowydajny backend na jednym VPS (Next.js + Drizzle + SQLite)

Wdrożenie w pełni funkcjonalnej usługi na serwerze za 5 USD:

• Baza danych jest przechowywana jako plik /var/data/production.db.
• ORM Drizzle komunikuje się z bazą poprzez better-sqlite3.
• Usługa obsługuje 10 000 000 odsłon stron miesięcznie przy zerowych kolejkach do bazy, zużywając jedynie 150 MB pamięci RAM.

02. Globalne aplikacje Edge z ultra-niskim TTFB dzięki Turso

Usługa autoryzacji lub weryfikacji kluczy licencyjnych z klientami na całym świecie:

• Główna baza Turso znajduje się we Frankfurcie.
• Repliki są wdrożone w Singapurze, São Paulo i Kalifornii.
• Zapytanie weryfikujące token sesji użytkownika z Tokio jest obsługiwane przez lokalną azjatycką replikę w 12 ms zamiast 250 ms pingowania transkontynentalnego.

03. Lokalna pamięć i magazyn wektorowy dla autonomicznego agenta AI

Opracowanie agenta terminalowego lub asystenta desktopowego:

• Cała historia dialogów, zapisane artefakty oraz osadzenia wektorowe bazy kodu (sqlite-vec) są przechowywane w jednym pliku memory.db.
• Użytkownik może łatwo skopiować swój plik wiedzy, przesłać go koledze lub wykonać kopię zapasową poprzez zwykłe skopiowanie pojedynczego pliku.

5. Pułapki, typowe błędy i bezpieczeństwo

• Zapomniany tryb WAL (Pułapka SQLITE_BUSY): Domyślnie SQLite działa w przestarzałym trybie dziennika cofania (Rollback Journal). Każda operacja zapisu blokuje całą bazę dla odczytu. Zawsze jawnie aktywuj PRAGMA journal_mode = WAL;.
• Umieszczanie SQLite na dyskach sieciowych (NFS / SMB / CIFS): Kategorycznie zabrania się przechowywania plików SQLite na systemach plików sieciowych ze względu na kruchą implementację protokołów blokowania plików (POSIX File Locks). Prowadzi to do nieodwracalnego uszkodzenia bazy (Database Corruption).
• Niepoprawne tworzenie kopii „gorącej” bazy przez zwykłe kopiowanie: Komenda cp app.db backup.db podczas aktywnego zapisu utworzy uszkodzony plik z powodu braku niezafiksowanych zmian z pliku WAL. Używaj VACUUM INTO 'backup.db' lub Litestream.
• Długotrwałe blokujące transakcje zapisu: Jeśli jeden wątek otwiera transakcję BEGIN TRANSACTION i czeka na odpowiedź od wolnego zewnętrznego API przez 10 sekund, wszystkie inne operacje zapisu zakończą się błędem timeoutu blokady (busy_timeout). Trzymaj transakcje zapisu jak najkrótsze.