Osiem baz danych brzmi jak przerost formy. „Po co osiem oddzielnych baz danych, skoro to jedno życie?” Pada to zawsze, gdy ktoś zobaczy schemat tego, co trzyma pamięć mojego systemu. Odpowiedź jest mniej elegancka, niż wygląda schemat, i składa się z jednego powodu technicznego oraz jednego historycznego.
Stan opisany poniżej to konfiguracja z października 2026, odczytana z ustawień, a nie zmierzona: jeden serwer PostgreSQL, przed nim PgBouncer jako jedyna droga połączeń, osiem baz dziedzinowych – finanse, trening, spiżarnia, zdrowie, cyfrowy bliźniak, nauka, logistyka, kariera.
Powód techniczny: promień rażenia
Izolacja, a nie szybkość
Osiem baz danych nie przyspiesza niczego. Robi jedną rzecz: ogranicza to, co psuje się razem.
Zmiana struktury w finansach – nowa kolumna, zmieniony typ, przebudowany indeks – dotyka wyłącznie finansów. Pętla treningowa w tym samym czasie czyta swoją bazę i nie wie, że cokolwiek się stało. Przy jednej bazie z ośmioma schematami ta sama operacja blokuje połączenia dla wszystkiego, co jest w kolejce, a u mnie w kolejce stoją rzeczy, które mają wykonać się o określonej godzinie.
Druga rzecz, którą to daje, to różne reguły dla różnych danych. Dane zdrowotne mają inny okres przechowywania niż historia cen w spiżarni i inny krąg rzeczy, które mają prawo je czytać. Osiem oddzielnych baz pozwala zapisać tę różnicę w uprawnieniach, a nie w komentarzu w kodzie.
Powód historyczny, którego nie zaplanowałem
Nie zaprojektowałem tego, to narosło
Uczciwie: nie zaprojektowałem ośmiu baz na starcie. Powstawały jedna po drugiej, przez kilka lat, każda razem z pętlą, która jej potrzebowała. Finanse były pierwsze, kariera ostatnia. Gdybym zaczynał dziś od pustej kartki, prawdopodobnie zrobiłbym jedną bazę z ośmioma schematami – to jest rozwiązanie prostsze w utrzymaniu i daje większość tych samych korzyści.
Mówię o tym, bo schemat architektury wygląda jak decyzja, a w połowie jest kroniką. Wart naśladowania jest z tego tylko podział na dziedziny, nie liczba baz.
Jedna droga dostępu, i to jest ważniejsze niż podział
Jedna reguła dostępu
Reguła, która u mnie trzyma to w całości, nie dotyczy liczby baz: żaden skrypt nie łączy się z bazą sam. Wszystkie połączenia idą przez jeden moduł konfiguracyjny – PgBouncer jest tu jedynym miejscem, gdzie znam adres i hasło. Żaden adres hosta, żadna nazwa użytkownika i żadne hasło nie występują w kodzie, który robi cokolwiek innego niż łączenie.
Wartość tego widać dokładnie raz – kiedy coś się zmienia. Przeniesienie bazy, zmiana portu, rotacja hasła to zmiana w jednym pliku. Bez tej reguły to jest przeszukiwanie całego repozytorium i nadzieja, że nic się nie przeoczyło.
Na tej samej zasadzie działa drugie ograniczenie, węższe: wszystkie pytania o finanse przechodzą przez jeden skrypt podsumowujący. Nie dlatego, że zapytania są tajne, ale dlatego, że liczby o pieniądzach muszą wychodzić zawsze tak samo policzone. Dwa miejsca liczące saldo to w praktyce dwa różne salda i pół dnia na ustalenie, które jest prawdziwe.
Czy ten układ kosztuje?
Osiem rzeczy do zabezpieczenia zamiast jednej
Podział na osiem baz danych ma jedną twardą wadę i trafiłem na nią w najgorszym możliwym miejscu. Pytanie, które dotyczy wszystkich ośmiu dziedzin naraz, jest drogie. Nie ma jednego zapytania, które przejdzie przez całość – jest osiem zapytań i składanie wyników poza bazą.
Najważniejsze pytanie, jakie mam do własnego systemu, jest właśnie takie: ile czasu oszczędza, po dziedzinach. Zadanie, które to liczy, musi wejść do wszystkich ośmiu i nie zmieściło się w limicie czasu, jaki sam nałożyłem na pojedyncze uruchomienie. Nie dostałem tej liczby do dziś. Całą tę próbę, z czterema przeszkodami po kolei, opisałem w tekście nie wiem, ile czasu oszczędza mój system.
To jest realna cena tego podziału i nie było jej na żadnym schemacie. Architektura, która dobrze izoluje awarie, równie dobrze izoluje pomiar.
Czego ten podział nie rozwiązuje
- Osiem baz danych nie zastępuje kopii zapasowych. Osiem baz to osiem rzeczy do zabezpieczenia, nie mniej. Izolacja chroni przed błędem w strukturze, nie przed utratą dysku.
- Nie jest szybszy. Nie zmierzyłem różnicy w wydajności między tym układem a jedną bazą ze schematami i nie będę jej zgadywał. Powód podziału jest operacyjny, nie wydajnościowy.
- Nie porządkuje danych sam z siebie. Osiem czystych granic na zewnątrz nie oznacza porządku w środku żadnej z nich.
- Nie jest to zalecenie. To układ jednej osoby, który narósł przez kilka lat. Jeden serwer PostgreSQL z ośmioma schematami i tą samą jedną drogą dostępu da ci większość tego efektu przy mniejszej pracy.
Z czterech warstw mojego systemu to pamięć jest tą, którą zmieniałem najrzadziej i której zmiana boli najbardziej. Cały układ – co jest mózgiem, co ciałem i co pamięcią – opisałem w tekście mój cyfrowy bliźniak: dlaczego to nie jest agent AI. A czym różni się automatyzacja, która wykonuje, od systemu, który decyduje, rozpisałem osobno: od automatyzacji do autonomii, pięć poziomów.
