22 kwi 2025·8 min
Jak LLM wybierają bazy danych na podstawie potrzeb produktu — i gdzie zawodzą
Jak LLM mapują potrzeby produktu na wybór bazy danych, co pomijają i praktyczna lista kontrolna, by zweryfikować rekomendacje zanim wybierzesz stack.
Jak LLM mapują potrzeby produktu na wybór bazy danych, co pomijają i praktyczna lista kontrolna, by zweryfikować rekomendacje zanim wybierzesz stack.
Zespoły proszą LLM o rekomendację bazy danych z tego samego powodu, dla którego proszą je o napisanie maila lub streszczenie specyfikacji: szybciej niż zaczynać od zera. Gdy stoisz przed tuzinem opcji — PostgreSQL, DynamoDB, MongoDB, Elasticsearch, Redis, ClickHouse i inne — LLM może szybko przygotować shortlistę, opisać kompromisy i dać „wystarczająco dobry” punkt wyjścia do dyskusji zespołowej.
Wykorzystany rozsądnie, wymusza też sformułowanie wymagań, które inaczej pozostałyby nieostre.
Mówiąc prosto: opisujesz produkt („marketplace z listingami i czatem”), dane („użytkownicy, zamówienia, wiadomości”) i ograniczenia („musi skalować do 1M użytkowników, potrzebne szybkie wyszukiwanie, niskie koszty operacyjne”). LLM następnie mapuje te potrzeby na powszechne wzorce architektoniczne:
Ta mapa może być naprawdę przydatna na wczesnym etapie, zwłaszcza gdy alternatywą jest pusty ekran.
Rekomendację LLM najlepiej traktować jak hipotezę, a nie werdykt architektoniczny. Może pomóc w:
Ale nie zna prawdziwego kształtu ruchu, wzrostu danych, umiejętności zespołu, ograniczeń dostawców ani tolerancji operacyjnej bez dokładnych danych wejściowych — i nawet wtedy nie wykona testów produkcyjnych.
LLM-y mają tendencję do zawodzenia w przewidywalny sposób: polegają na popularnych regułkach, zgadują brakujące szczegóły, pomijają potrzeby transakcyjne i spójności, zakładają wydajność bez benchmarków i bagatelizują koszty oraz obciążenie operacyjne.
Reszta tego artykułu rozbiera te tryby awarii i kończy praktyczną listą kontrolną, która pozwoli zweryfikować każdą poradę LLM zanim zaangażujesz się w konkretny stack.
Gdy prosisz LLM o „rekomendację bazy”, nie ocenia baz tak jak inżynier. Konwertuje Twój prompt na wywnioskowane wymagania, dopasowuje je do wzorców, które widział wcześniej, a potem tworzy odpowiedź, która czyta się jak decyzja.
Wejścia to nie tylko jawne szczegóły, które podajesz (ruch, rozmiar danych, potrzeby spójności). Model wykorzystuje też:
Ponieważ wiele promptów jest niekompletnych, model często wypełnia luki implicitnymi założeniami — czasem trafnie, czasem nie.
Większość odpowiedzi pojawia się na trzech poziomach:
Efekt może brzmieć jak jasna rekomendacja, ale często jest to uporządkowane streszczenie konwencjonalnych opcji.
LLM-y generalizują z przykładów; nie uruchamiają Twojego obciążenia, nie sprawdzają schematu ani nie benchmarkują zapytań. Jeśli dane treningowe silnie kojarzą „dużą skalę” z „NoSQL”, możesz otrzymać taką odpowiedź nawet gdy dobrze dostrojony system SQL wystarczyłby.
Pewny styl wypowiedzi to styl, nie pomiar. Jeżeli model nie precyzuje założeń ("zakładam głównie zapisy append-only i akceptowalna jest spójność eventualna"), pewność może ukrywać rzeczywistą niepewność: brak danych wejściowych i nieprzetestowane twierdzenia o wydajności.
Kiedy ludzie mówią „wybierz bazę na podstawie potrzeb produktu”, często mają na myśli znacznie więcej niż „przechowujemy użytkowników i zamówienia”. Dobry wybór bazy odzwierciedla, co produkt robi, jak musi się zachowywać pod obciążeniem oraz co zespół realistycznie potrafi obsługiwać.
Zacznij od kształtu produktu: główne encje, jak się ze sobą łączą i które zapytania napędzają rzeczywiste workflowy.
Czy potrzebujesz elastycznego filtrowania i raportowania po wielu atrybutach? Polegasz na łączeniach? Czy głównie czytasz pojedynczy rekord po ID, czy skanujesz zakresy czasowe? Te szczegóły decydują, czy lepiej pasują tabele SQL, modele dokumentowe, wzorce wide-column czy indeksy wyszukiwarki.
Wybór bazy jest często determinowany ograniczeniami, a nie tylko funkcjami:
System, który toleruje kilka sekund opóźnienia, różni się od tego, który musi potwierdzić płatność w <200 ms.
Nawet „idealny” model danych zawiedzie, jeśli operacje nie pasują:
Wymogi zgodności mogą szybko zawęzić wybór:
LLM-y często wnioskują takie potrzeby z mglistych promptów — więc jawność w tej kwestii rozróżnia pomocną poradę od pewnego błędu.
LLM-y często mapują kilka podanych potrzeb („real-time”, „skalowalność”, „elastyczne schematy”) na znajomy etykietę kategorii („użyj NoSQL”, „użyj Postgresa”). To może być przydatne w burzy mózgów, ale rozumowanie odpływa, gdy model traktuje funkcje bazy jak równoważne wymaganiom produktu.
Lista funkcji (transakcje, wsparcie JSON, pełnotekstowe wyszukiwanie, sharding) brzmi namacalnie, ale potrzeby produktu zwykle opisują rezultaty: akceptowalna latencja, reguły poprawności, możliwość audytu, umiejętności zespołu, ograniczenia migracji i budżet.
LLM może „odhaczyć” funkcje i mimo to pominąć, że produkt potrzebuje przewidywalnych procesów wsparcia, dojrzałego ekosystemu lub hostingu, którego firma może używać.
Wiele rekomendacji zakłada, że jeśli baza potrafi przechować typ danych, to będzie odpowiednia. Trudniejsza część to relacja między danymi a zapytaniami: jak będziesz filtrować, łączyć, sortować i agregować — przy jakich wolumenach i wzorcach aktualizacji.
Dwa systemy, które „przechowują zdarzenia użytkownika”, mogą zachowywać się diametralnie inaczej w zależności od tego, czy potrzebujesz:
LLM może stwierdzić „Baza X jest szybka”, ale wydajność zależy od wyborów schematu, indeksów, partycjonowania, kształtu zapytań i współbieżności. Małe zmiany — np. dodanie złożonego indeksu czy unikanie nieograniczonych skanów — mogą odwrócić wynik. Bez reprezentatywnych danych i zapytań „szybko” to tylko zgadywanie.
Nawet jeśli dwie bazy technicznie spełniają wymagania, lepszym wyborem może być ta, którą zespół potrafi obsłużyć: backupy i czas przywracania, monitorowanie, obciążenie on-call, uzależnienie od dostawcy i przewidywalność kosztów.
LLM-y zwykle nie ważą tych realiów, jeśli ich nie wymienisz jawnie.
LLM-y często odpowiadają regułami powtarzanymi w sieci, jak „NoSQL lepiej skaluje” czy „Postgres poradzi sobie ze wszystkim”. Te skróty brzmią pewnie, ale spłaszczają złożoną rzeczywistość produktu: co przechowujesz, jak to zapytujesz i co się dzieje, gdy coś pójdzie nie tak.
Powszechny wzorzec to założenie, że jeśli wspomnisz wzrost, duży ruch lub „big data”, najbezpieczniejszy wybór to NoSQL. Problem w tym, że „skala” rzadko jest pierwszym nierozwiązanym problemem. Wiele aplikacji osiąga limity z powodu:
W takich przypadkach zmiana bazy nie naprawi przyczyny — zmieni jedynie narzędzia.
Regułki także zamazują wymagania, które silnie wpływają na dopasowanie bazy. LLM może polecić magazyn dokumentów, pomijając, że potrzebujesz:
Te potrzeby nie wykluczają automatycznie NoSQL, ale podnoszą poprzeczkę: może być konieczne ostrożne projektowanie schematu, dodatkowa logika aplikacji lub inne kompromisy niż sugerował LLM.
Gdy rekomendacja opiera się na sloganie zamiast na rzeczywistych wzorcach dostępu, ryzyko to nie tylko suboptymalny wybór — to kosztowna replatformizacja później. Migracja danych, przepisywanie zapytań i przeszkolenie zespołu zwykle zdarzają się właśnie wtedy, gdy najmniej potrzebujesz przestojów.
Traktuj „reguły” jako punkty wyjścia do pytań, nie jako odpowiedzi. Zapytaj, co dokładnie skalujesz (odczyty, zapisy, analityka), co musi być poprawne i jakich zapytań nie da się uniknąć.
LLM świetnie przekształca krótki opis w pewny wybór bazy — ale nie wymyśli brakujących ograniczeń, które faktycznie decydują o właściwej opcji. Gdy wejścia są niejasne, rekomendacja staje się zgadywanką przebranej za odpowiedź.
Słowa takie jak „real-time”, „duży ruch”, „skalowalny” czy „enterprise-grade” nie mapują się jednoznacznie na konkretną bazę. „Real-time” może oznaczać „odświeżenie w ciągu 5 sekund” w dashboardzie — albo „end-to-end <50 ms” dla alertów tradingowych. „Duży ruch” to może być 200 RPS albo 200 000 RPS.
Bez twardych liczb LLM może domyślnie iść za heurystyką (np. „NoSQL dla skali”, „Postgres do wszystkiego”), nawet jeśli rzeczywiste potrzeby wskazują inaczej.
Jeśli ich nie podasz, model będzie je domyślał:
Najbardziej szkodliwe pominięcia to często kształt zapytań:
Baza świetna w dostępie klucz-wartość może mieć problemy, gdy produkt nagle potrzebuje elastycznego filtrowania i niezawodnego raportowania.
Traktuj „wybór bazy” jako interakcję dwuetapową: najpierw zbierz ograniczenia, potem rekomenduj. Dobry prompt (lub wewnętrzna lista kontrolna) powinien wymagać liczb i przykładowych zapytań zanim wskaże jakikolwiek silnik.
Częsty błąd LLM to polecanie kategorii bazy (SQL, dokument, graf, wide-column) bez weryfikacji, czy dane produktu faktycznie pasują do tego modelu. Efekt to wybór magazynu, który brzmi dobrze, ale walczy ze strukturą informacji, które musisz reprezentować.
LLM często pomija głębokość i krotność relacji: one-to-many vs many-to-many, zagnieżdżone własności, współdzielone encje i jak często użytkownicy przemieszczają się między nimi.
Baza dokumentowa może wydawać się naturalna dla „profilów użytkownika”, ale jeśli produkt często odpowiada na zapytania przekrojowe — „wszystkie projekty, gdzie zmieniła się rola dowolnego członka w ciągu ostatnich 7 dni” albo „top 20 tagów we wszystkich zespołach filtrowane po statusie zgodności” — przestajesz pobierać pojedynczy dokument; zaczynasz potrzebować łączeń.
Gdy takie łączenia są częste, musisz albo:
Duplikacja nie jest darmowa. Zwiększa amplifikację zapisów, utrudnia utrzymanie spójności przy aktualizacjach, komplikuje audyty i może tworzyć subtelne błędy („który skopiowany rekord jest źródłem prawdy?”). LLM-y czasem polecają denormalizację jak jednorazowy wybór modelowy, a nie jako ciągłe obciążenie operacyjne.
Zanim zaakceptujesz rekomendację LLM, wymuś szybki test realności:
Jeśli model i zapytania się nie zgadzają, rekomendacja to szum — nawet jeśli brzmi pewnie.
LLM-y często traktują „spójność” jak preferencję, a nie jako wymaganie produktu. To prowadzi do rekomendacji, które wyglądają rozsądnie na papierze („użyj skalowalnego NoSQL”), ale zawodzą, gdy prawdziwe akcje użytkowników wymagają atomowych, wieloetapowych aktualizacji.
Wiele przepływów produktowych to nie pojedynczy zapis — to wiele zapisów, które muszą albo wszystkie się powieść, albo żaden. Płatności to klasyczny przykład: utwórz opłatę, oznacz fakturę jako opłaconą, zmniejsz saldo konta i dołącz zapis audytu. Jeśli któryś krok nie powiedzie się po wcześniejszym sukcesie, powstaje niespójność, którą zauważy CS i finanse.
Podobnie zapasy: rezerwuj towar, twórz zamówienie i aktualizuj dostępność. Bez transakcji możesz sprzedawać więcej, niż jest w magazynie w trakcie szczytów.
LLM czasami utożsamia spójność eventualną z „UI może się później odświeżyć”. Pytanie brzmi, czy czynność biznesowa może tolerować rozbieżność.
Konflikty rezerwacji pokazują, dlaczego to ma znaczenie: dwóch użytkowników próbuje zarezerwować ten sam termin. Jeśli system zaakceptuje obie operacje i „rozwiąże to później”, nie poprawiasz UX — tworzysz zgłoszenia do supportu i refundacje.
Nawet z bazą wspierającą transakcje, otoczenie workflow musi mieć jasne semantyki:
Jeżeli LLM to ignoruje, może polecić architekturę wymagającą eksperckiej pracy rozproszonych systemów, by osiągnąć „normalną” poprawność produktu.
LLM-y często rekomendują „szybką” bazę, jakby szybkość była właściwością wewnętrzną silnika. W praktyce wydajność to interakcja między Twoim obciążeniem, schematem, kształtem zapytań, indeksami, sprzętem i ustawieniami operacyjnymi.
Jeśli nie określisz, co ma być szybkie — latencja p99 dla pojedynczych odczytów, analityka batchowa, przepustowość ingestu czy time-to-first-byte — LLM może domyślnie iść za popularnymi wyborami.
Dwa produkty mogą obydwa deklarować „niską latencję”, a mieć przeciwne wzorce dostępu: jeden to lookup klucz-wartość; drugi to wyszukiwanie + filtrowanie + sortowanie po wielu polach.
Porady wydajnościowe błądzą też, gdy modele ignorują:
LLM może założyć, że cache rozwiąże problem, ale cache pomaga jedynie przy przewidywalnych wzorcach dostępu. Zapytania skanujące duże zakresy, sortujące po nieindeksowanych polach lub używające ad-hoc filtrów rzadko trafiają w cache i obciążają dysk/CPU.
Małe zmiany w kształcie zapytania (np. stronicowanie OFFSET vs keyset) mogą odwrócić wynik wydajnościowy.
Zamiast ufać ogólnym „X jest szybsze niż Y”, wykonaj lekki test odwzorowany na produkcie:
Benchmarki nie przewidzą wszystkiego, ale szybko pokażą, czy założenia LLM co do wydajności mają odzwierciedlenie w rzeczywistości.
LLM-y często optymalizują dopasowanie na papierze — model danych, zapytania, słowa kluczowe o skalowalności — jednocześnie pomijając to, co czyni bazę przetrwalną w produkcji: operacje, odzyskiwanie po awarii i rzeczywisty rachunek, który miesięcznie przyjdzie zapłacić.
Rekomendacja bazy nie jest kompletna, jeśli nie odpowiada na podstawowe pytania: jak robić spójne backupy? Jak szybko możesz przywrócić? Jaki jest plan odtwarzania po awarii między regionami?
Porady LLM często pomijają te szczegóły albo zakładają, że są „wbudowane”, nie sprawdzając drobnego druku.
Migracja to kolejna ślepa strefa. Zmiana bazy później może być droga i ryzykowna (zmiany schematu, dual writes, backfille, przepisywanie zapytań). Jeśli produkt będzie ewoluował, „łatwo zacząć” to za mało — potrzebujesz realistycznej ścieżki migracji.
Zespoły nie potrzebują tylko bazy — muszą ją obsługiwać.
Jeśli rekomendacja pomija slow query logs, metryki, dashboardy, hooki do trace'owania i alertowanie, możesz nie zauważyć problemów, dopóki użytkownicy nie zaczną narzekać. Narzędzia operacyjne bardzo różnią się między managed a self-hosted oraz między dostawcami.
LLM-y mają tendencję do zaniżania kosztów, koncentrując się na wielkości instancji i zapominając o mnożnikach:
„Najlepsza” baza, której zespół nie potrafi obsłużyć, rzadko jest najlepsza. Rekomendacje powinny zgadzać się z umiejętnościami zespołu, oczekiwaniami wsparcia i potrzebami zgodności — inaczej ryzyko operacyjne staje się dominującym kosztem.
LLM-y czasem próbują „rozwiązać wszystko naraz”, proponując stack typu: Postgres do transakcji, Redis do cache, Elasticsearch do wyszukiwania, Kafka + ClickHouse do analityki, plus baza grafowa „na wszelki wypadek”. Brzmi to imponująco, ale często to przedwczesny projekt, który tworzy więcej pracy niż wartości — szczególnie na początku produktu.
Projekty wielobazowe wyglądają jak bezpieczne zabezpieczenie: każdy tool jest „najlepszy” w jednej rzeczy. Ukryty koszt jest taki, że każdy dodatkowy magazyn dodaje wdrożenia, monitorowanie, backupy, migracje, kontrolę dostępu, reakcje na incydenty i nowe tryby awarii.
Zespoły spędzają wtedy czas na utrzymaniu spójników zamiast na dostarczaniu funkcji produktu.
Druga (lub trzecia) baza zwykle ma sens, gdy istnieje jasna, zmierzona potrzeba, której baza podstawowa nie spełnia bez niedopuszczalnego bólu, na przykład:
Jeśli nie potrafisz wskazać konkretnego zapytania, celu latencji, ograniczenia kosztowego lub ryzyka operacyjnego, to prawdopodobnie przedwczesne.
Gdy dane żyją w wielu miejscach, pojawiają się trudne pytania: Który sklep jest źródłem prawdy? Jak utrzymać spójność podczas ponowień, częściowych awarii i backfilli?
Duplikacja danych to także duplikacja błędów — przestarzałe wyniki wyszukiwania, niezgodne liczby użytkowników i spotkania “zależy, którego dashboardu użyjesz”.
Zacznij od jednej uniwersalnej bazy, która obsłuży rdzeń transakcyjny i raportowy. Dodaj dedykowany sklep tylko wtedy, gdy możesz: (1) pokazać, że obecny system zawodzi względem wymogu, i (2) zdefiniować model odpowiedzialności za synchronizację, spójność i odzyskiwanie.
Zachowaj możliwość ucieczki, nie złożoność.
LLM-y mogą być pomocne w wygenerowaniu pierwszego szkicu rekomendacji bazy, ale traktuj je jako hipotezę. Użyj poniższej listy, by zweryfikować (lub odrzucić) sugestię zanim zaangażujesz inżynieryjny czas.
Przekształć prompt w jawne wymagania. Jeśli nie potrafisz tego spisać jasno, model prawdopodobnie zgadł.
Szkicuj rzeczywiste encje i relacje (nawet pobieżnie). Potem wypisz top zapytań i wzorców dostępu.
Przetłumacz „ma być szybkie i niezawodne” na mierzalne testy.
Użyj realistycznych kształtów danych i miksów zapytań, nie zabawek. Załaduj reprezentatywny zestaw danych, uruchom zapytania pod obciążeniem i zmierz.
Jeśli LLM zaproponował wiele baz, przetestuj najpierw najprostsze, jednorozwiązaniowe podejście, a potem udowodnij, dlaczego podział jest konieczny.
Jeśli chcesz przyspieszyć ten krok, praktycznym podejściem jest prototypowanie wycinka produktu, który decyduje o wyborze bazy (kilka kluczowych encji + najważniejsze endpointy + najważniejsze zapytania). Platformy takie jak Koder.ai mogą tu pomóc: możesz opisać przepływ w chatcie, wygenerować działającą web/backend app (zwykle React + Go + PostgreSQL) i szybko iterować, dopóki dopracowujesz schemat, indeksy i kształt zapytań. Funkcje takie jak tryb planowania, snapshoty i cofanie są szczególnie użyteczne podczas eksperymentów ze schematami i migracjami.
Napisz krótkie uzasadnienie: dlaczego ta baza pasuje do obciążenia, jakie kompromisy akceptujecie i jakie metryki wymuszą ponowną ocenę w przyszłości (np. utrzymujący się wzrost zapisów, nowe typy zapytań, wymagania multi-region, progi kosztowe).
Traktuj to jako hipotezę i sposób przyspieszenia burzy mózgów. Użyj rekomendacji, aby uwidocznić kompromisy, brakujące wymagania i wstępną listę kandydatów — następnie zweryfikuj je z zespołem, rzeczywistymi ograniczeniami i szybkim proof-of-concept.
Ponieważ w Twoim promptcie zwykle brakuje twardych ograniczeń, model często:
Poproś, aby przed wskazaniem konkretnej bazy model jawnie wymienił swoje założenia.
Podaj liczby i przykłady, nie ogólniki:
Jeśli nie potrafisz tego określić, rekomendacja to w dużej mierze zgadywanka.
Użyj modelu, by wygenerować listę wymagań i kandydatów, a następnie wymuś sprawdzenie schematu i zapytań:
„Skalowalność” to nie typ bazy, lecz to, co skalujesz.
Wiele aplikacji napotyka ograniczenia z powodu:
Dobrze zaprojektowany system relacyjny może skalować bardzo daleko, zanim zmiana bazy będzie właściwym rozwiązaniem.
Często są zbyt słabo zdefiniowane w rekomendacjach.
Jeżeli produkt wymaga wieloetapowych aktualizacji, które muszą się udać albo zrezygnować razem (płatności, zapasy, rezerwacje), potrzebujesz jasnego wsparcia dla:
Jeżeli LLM nie pyta o to, nalegaj na doprecyzowanie przed przyjęciem sugestii.
Relacje danych napędzają złożoność zapytań.
Jeżeli często potrzebujesz zapytań między-encji (filtry, łączenia, agregacje po wielu atrybutach), model dokumentowy może zmusić Cię do:
To zwiększa amplifikację zapisu, ryzyko niespójności i złożoność operacyjną.
Wydajność zależy od Twojego obciążenia, schematu, indeksów i współbieżności — nie od samej nazwy produktu.
Przeprowadź mały test odwzorowany na produkcie:
Każda dodatkowa baza mnoży powierzchnię operacyjną:
Zacznij od jednej uniwersalnej bazy dla rdzenia transakcyjnego i raportowego. Dodaj drugą dopiero, gdy pokażesz mierzalne wymaganie, którego pierwsza nie spełnia.
Poproś o model kosztów uwzględniający realne mnożniki:
Wymagaj także planu operacyjnego: kroki backup/restore, cele RPO/RTO oraz jak wykrywać wolne zapytania i problemy z pojemnością.