Przejście z centralnych hurtowni danych na architekturę dedykowanych baz danych dla każdego lokatora (tenant) oraz agenta AI staje się nowym standardem w inżynierii oprogramowania. Platforma Supabase przekroczyła pułap 13 milionów użytkowników i zakłada obecnie ponad 1 milion baz danych tygodniowo, z czego aż 70% ruchu generują autonomiczne agenty AI. Przejście na dedykowane pliki bazy danych SQLite i Turso pozwala firmom technologicznym zredukować miesięczne koszty infrastruktury z poziomu 3000–5000 USD do niskich setek dolarów przy dziesiątkach tysięcy równoległych baz danych.
Architektura baza-na-tenanta a izolacja danych
Tradycyjne architektury SaaS opierają się na współdzielonym schemacie bazy danych, gdzie izolacja lokatorów zależy wyłącznie od logiki aplikacji i polityk RLS. Wadliwa logika połączeń lub przeoczony filtr w zapytaniu grozi wyciekiem danych między firmami, a powolne zapytanie jednego klienta obciąża cały system.
W modelu shared schema tabela zawiera kolumnę tenant_id, a bezpieczeństwo opiera się na politykach Row-Level Security (RLS). Audyt bezpieczeństwa w takim modelu wymaga weryfikacji każdego zapytania SQL, testów regresyjnych i dowodów, że żaden kod nie omija kontekstu sesji. Z kolei usunięcie danych klienta w celu spełnienia wymogów RODO wymusza czyszczenie rekordów we wszystkich tabelach systemu.
Rozwiązaniem tego problemu jest architektura database-per-tenant, w której każdy klient lub agent otrzymuje dedykowaną bazę danych. Przejście na fizyczną izolację danych skraca audyt bezpieczeństwa do jednego zdania: dane klienta znajdują się w odrębnej bazie i są dostępne wyłącznie poprzez token wygenerowany dla tego konkretnego zasobu. Prace konserwacyjne, tworzenie kopii zapasowych oraz całkowite usunięcie konta sprowadzają się do operacji na jednym pliku lub dedykowanym zasobie.
Ile kosztuje baza danych dla każdego użytkownika?
Uruchomienie dedykowanej instancji Postgres dla każdego klienta jest finansowo nieopłacalne dla szybko skalujących się aplikacji SaaS lub agentów AI. Model bazy danych per tenant wymaga struktury, w której bezczynna baza danych generuje wyłącznie minimalny koszt przechowywania pliku danych na dysku.
Wielotenantowość oparta na tradycyjnym silniku Postgres generuje wysokie koszty stałe — płatne instancje zarządzane w chmurze kosztują zazwyczaj od 10 do 25 USD miesięcznie za instancję. Zastosowanie silnika SQLite diametralnie zmienia tę kalkulację, ponieważ baza danych jest plikiem na dysku. Bezczynny tenant płaci wyłącznie za przestrzeń dyskową, co umożliwia bezpłatne utrzymywanie setek tysięcy nieaktywnych kont.
Przykłady wdrożeń produkcyjnych potwierdzają opłacalność tego podejścia: CTO.new (Engine Labs) utrzymuje dziesiątki tysięcy odizolowanych baz danych (1 baza na agenta AI) i zredukowało koszty z 3000–5000 USD miesięcznie na zarządzanym Postgresie do niskich setek dolarów na platformie Turso. Adaptive zarządza ponad 2 milionami baz danych na Turso Cloud (1 baza na prompt i wersję). * Supabase przejęło Turso, aby zaoferować poziom Supabase Spark połączenie ekosystemu Postgres i SQLite dla masowych obciążeń prototypowych i agentowych, skalowalnych od prototypu do petabajtów.
Dla aplikacji o intensywnym odczycie SQLite działające w trybie WAL (Write-Ahead Logging) z poleceniem PRAGMA journal_mode=WAL; eliminuje blokowanie odczytów przez zapytania zapisujące, osiągając czas odpowiedzi rzędu mikrosekund dzięki braku opóźnień gniazda sieciowego TCP.
Model local-first i synchroniczne usuwanie opóźnień
Ruch local-first zmienia priorytet przechowywania danych, przenosząc główną kopię dokumentu lub aplikacji na dysk lokalny urządzenia użytkownika. Ograniczenia fizyczne prędkości światła w sieci WAN generują opóźnienia rzędu stu milisekund, co uniemożliwia uzyskanie natychmiastowej reakcji interfejsu użytkownika.
Tradycyjne aplikacje chmurowe traktują dane na urządzeniu klienckim wyłącznie jako pamięć podręczną. Przesyłanie każdego kliknięcia do serwera w chmurze tworzy opóźnienia rzędu 50–500 ms, podczas gdy odczyt z lokalnego dysku NVMe trwa zazwyczaj 1–20 ms. Siedem zasad oprogramowania local-first, sformułowanych przez Ink & Switch, zakłada brak wskaźników ładowania (spinners), pracę wielourządzeniową, opcjonalność sieci, płynną współpracę, długowieczność danych (The Long Now), domyślną prywatność oraz pełną kontrolę użytkownika.
Kluczową technologią umożliwiającą bezkonfliktową synchronizację danych w środowisku rozproszonym są struktury CRDT (Conflict-free Replicated Data Types), takie jak Automerge czy Yjs. Algorytmy te automatycznie scalają równoległe edycje wykonywane na różnych urządzeniach bez potrzeby udziału centralnego serwera rozstrzygającego konflikty.
Pamięć wektorowa i integracja agentów w lokalnym staku
Rozwój autonomicznych agentów AI wymaga trwałej pamięci sekwencyjnej i wektorowej bez polegania na zewnętrznych interfejsach API embeddingów. Aplikacje lokalne potrzebują jednolitego systemu przechowywania sesji, transkryptów oraz wyszukiwania semantycznego lokalnie lub w bezpiecznej chmurze.
Projekt PicoOraClaw (rozwijany w oparciu o lekki runtime w języku Go oraz Ollama) wykorzystuje bazy danych Oracle AI Database Free jako trwały magazyn pamięci. Wyszukiwanie semantyczne realizowane jest bezpośrednio w bazie za pomocą modeli ONNX (np. ALL_MINILM_L12_V2) i funkcji VECTOR_EMBEDDING() oraz VECTOR_DISTANCE(), eliminując potrzebę wysyłania danych do zewnętrznych dostawców API.
Wybór silnika wektorowego zależy od skali przetwarzanych danych: pgvector: rozszerzenie dla Postgres, optymalne dla zbiorów do 10 milionów wektorów. Qdrant / Milvus: dedykowane bazy indeksujące oparte na grafie HNSW (Hierarchical Navigable Small World), obsługujące dziesiątki i setki milionów wektorów przy niskich opóźnieniach. * SQLite / DuckDB: lokalne plikowe bazy danych do przechowywania struktury i wektorów bezpośrednio na urządzeniu końcowym.
Wnioski praktyczne i rekomendacje
Zweryfikuj obecny model izolacji danych pod kątem wymagań prawnych oraz kosztów utrzymania infrastruktury w chmurze.
Zmierz udział zapytania o dane jednego lokatora w całkowitym obciążeniu bazy oraz przeanalizuj koszty pojedynczej instancji Postgres w porównaniu z rozwiązaniami opartymi na plikach SQLite lub Turso.
Skonfiguruj nagłówek PRAGMA journal_mode=WAL; w lokalnych bazach danych SQLite, aby umożliwić bezblokowe odczyty współbieżne i wyeliminować opóźnienia sieciowe gniazd TCP.
Wdróż warstwę trasowania połączeń (routing) opartą na zweryfikowanym tokenie JWT lub subdomenie, mapującą zapytania aplikacji bezpośrednio do dedykowanego pliku bazy danych danego lokatora.
Źródła
- A Critical Look at Decentralized Personal Data Architectures – cs.Princeton
- Build an Ultra-Lightweight, Local-First AI Assistant with Persistent Memory | developers
- Local-First Software:You Own Your Data, in spite of the Cloud – Martin Kleppmann
- Local-first software: You own your data, in spite of the cloud – InkAndSwitch
- The Many-Database Architecture: Should You Give Every Tenant Their Own Database?
- The Ultimate Guide to Local-First Software – Dench
- Vector Database System Design: Architecture for AI Applications | InfraSketch Blog
- Why Everyone Is About To Have Their Own Database
Dodaj komentarz