Dowiedz się, dlaczego wiele startupów wybiera PostgreSQL jako domyślną bazę: niezawodność, funkcje jak JSONB, mocne narzędzia i jasna ścieżka od MVP do skali.
Kiedy założyciele mówią, że PostgreSQL jest „domyślną bazą danych”, zwykle nie mają na myśli, że to najlepszy wybór dla każdego produktu. Chodzi o to, że możesz go wybrać wcześnie — często bez długiej oceny — i mieć pewność, że nie będzie blokował rozwoju produktu i zespołu.
Dla MVP „domyślne” oznacza obniżenie kosztów podejmowania decyzji. Chcesz bazy, którą wiele osób rozumie, na którą łatwo zatrudnić, którą wspierają providery hostingowi i która jest wyrozumiała, gdy model danych się zmienia. Domyślny wybór pasuje do typowej ścieżki startupu: buduj szybko, ucz się od użytkowników, potem iteruj.
To też powód, dla którego PostgreSQL pojawia się w wielu nowoczesnych „standardowych stackach”. Na przykład platformy takie jak Koder.ai używają Postgresa jako rdzenia do szybkiego dostarczania realnych aplikacji (React na froncie, usługi w Go na backendzie, PostgreSQL dla danych). Chodzi nie o markę — chodzi o wzorzec: wybierz sprawdzone prymitywy, żeby móc skupić się na produkcie, a nie na debatach o infrastrukturze.
Są sytuacje, gdy inna baza będzie lepszym pierwszym posunięciem: ekstremalny przepływ zapisów, obciążenia o charakterze time-series lub bardzo wyspecjalizowane wyszukiwanie. Ale większość wczesnych produktów wygląda jak „użytkownicy + konta + uprawnienia + rozliczenia + aktywność”, a ta struktura dobrze pasuje do bazy relacyjnej.
PostgreSQL to otwartoźródłowa baza relacyjna. „Relacyjna” oznacza, że dane są przechowywane w tabelach (jak arkusze kalkulacyjne) i możesz wiarygodnie łączyć te tabele (użytkownicy ↔ zamówienia ↔ subskrypcje). Posługuje się SQL, standardowym językiem zapytań stosowanym w branży.
Przejdziemy przez powody, dla których PostgreSQL tak często staje się domyślnym wyborem:
Celem nie jest sprzedanie jednej „słusznej odpowiedzi”, lecz pokazanie wzorców, które czynią PostgreSQL bezpiecznym punktem startowym dla wielu startupów.
PostgreSQL buduje zaufanie, bo zaprojektowano go tak, żeby utrzymywał poprawność danych — nawet gdy aplikacja, serwery lub sieci nie zachowują się idealnie. Dla startupów obsługujących zamówienia, płatności, subskrypcje czy profile użytkowników „w większości poprawne” nie wystarcza.
PostgreSQL wspiera transakcje ACID, które można traktować jak „wszystko albo nic” obejmujące zestaw zmian.
Jeśli proces płatności musi (1) utworzyć zamówienie, (2) zarezerwować stan magazynowy i (3) zarejestrować intencję płatności, transakcja zapewnia, że te kroki albo wszystkie zakończą się sukcesem, albo żaden. Jeśli serwer padnie w połowie, PostgreSQL może cofnąć niedokończone operacje zamiast zostawiać częściowe rekordy powodujące zwroty, podwójne obciążenia lub „zaginione zamówienia”.
Funkcje integralności danych pomagają zapobiegać wprowadzaniu złych danych do systemu:
To przesuwa odpowiedzialność za poprawność z „mamy nadzieję, że każdy fragment kodu robi dobrze” na „system nie pozwoli na nieprawidłowe stany”.
Zespoły poruszają się szybko, a struktura bazy będzie się zmieniać. PostgreSQL wspiera bezpieczne migracje i wzorce ewolucji schematu — dodawanie kolumn, backfille, wprowadzanie nowych ograniczeń stopniowo — dzięki czemu możesz wdrażać funkcje bez psucia istniejących danych.
Gdy ruch rośnie lub węzeł się restartuje, gwarancje trwałości PostgreSQL i dojrzała kontrola współbieżności utrzymują stabilne zachowanie. Zamiast cichej utraty danych czy niespójnych odczytów, dostajesz czytelne wyniki i stany możliwe do odzyskania — dokładnie to, czego chcesz, gdy klienci patrzą.
Największą zaletą PostgreSQL dla wielu startupów jest prosta rzecz: SQL ułatwia zadawanie jasnych pytań dotyczących danych, nawet gdy produkt się zmienia. Gdy założyciel chce cotygodniowego raportu przychodów, PM chce raport kohortowy, a support rozumieć, dlaczego zamówienie nie przeszło, SQL jest wspólnym językiem do raportowania, debugowania i szybkich „czy możemy szybko sprawdzić…” zapytań.
Większość produktów naturalnie ma relacje: użytkownicy należą do zespołów, zespoły mają projekty, projekty mają zadania, zadania mają komentarze. Modelowanie relacyjne pozwala wyrazić te powiązania bezpośrednio, a joiny sprawiają, że łączenie ich jest praktyczne.
To nie tylko akademicka struktura — pomaga szybciej wypuszczać funkcje. Przykłady:
Gdy dane są zorganizowane wokół dobrze zdefiniowanych encji, logika aplikacji staje się prostsza, bo baza potrafi wiarygodnie odpowiedzieć „kto jest powiązany z czym”.
Bazy SQL oferują narzędzia, które oszczędzają czas:
SQL jest szeroko nauczany i używany. Ma to znaczenie przy rekrutacji inżynierów, analityków czy PM-ów z zmysłem do danych. Startup może szybciej wdrożyć nowych ludzi, gdy wielu kandydatów już potrafi czytać i pisać SQL — a baza sama w sobie zachęca do czystej, zapytalnej struktury.
Rzadko zdarza się, by modele danych były idealne od pierwszego dnia. JSONB w PostgreSQL daje praktyczny „zawór bezpieczeństwa” dla danych pół-strukturalnych, trzymając wszystko w jednej bazie.
JSONB przechowuje JSON w postaci binarnej, którą PostgreSQL może efektywnie przeszukiwać. Możesz trzymać podstawowe tabele relacyjne (users, accounts, subscriptions) i dodać kolumnę JSONB na pola, które często się zmieniają lub różnią się między klientami.
Typowe, przyjazne startupom zastosowania to:
{'beta': true, 'new_checkout': 'variant_b'}JSONB nie zastępuje modelowania relacyjnego. Trzymaj dane relacyjne tam, gdzie potrzebujesz silnych ograniczeń, joinów i jasnego raportowania (np. status rozliczeń, uprawnienia, sumy zamówień). JSONB stosuj do naprawdę elastycznych atrybutów i traktuj go jak „schemat, który ewoluuje”, a nie składzik na wszystko.
Wydajność zależy od indeksów. PostgreSQL wspiera:
props @> '{"beta":true}')(props->>'plan'))To ma znaczenie, bo bez indeksów filtry JSONB mogą sprowadzić się do skanów tabel, gdy dane rosną — zamieniając wygodny skrót w wolne endpointy.
Jednym z powodów, dla których startupy zostają z PostgreSQL dłużej niż oczekują, są rozszerzenia: opcjonalne „dodatki”, które włączasz na bazie, by rozszerzyć możliwości Postgresa. Zamiast dodawać nową usługę dla każdej potrzeby, często możesz ją zrealizować w tej samej bazie, którą już uruchamiasz, monitorujesz i backupujesz.
Rozszerzenia mogą dodać nowe typy danych, metody indeksowania, możliwości wyszukiwania i funkcje użytkowe. Kilka popularnych przykładów, które warto znać wcześnie:
Są popularne, bo rozwiązują realne problemy produktowe bez potrzeby dokręcania dodatkowej infrastruktury.
Rozszerzenia mogą zmniejszyć potrzebę oddzielnych systemów we wczesnych i średnich etapach:
To nie znaczy, że Postgres ma robić wszystko na zawsze — ale może pomóc wypuścić funkcje szybciej, z mniejszą liczbą elementów ruchomych.
Rozszerzenia wpływają na operacje. Zanim zaczniesz na nich polegać, potwierdź:
Traktuj rozszerzenia jak zależności: wybieraj je świadomie, dokumentuj powód ich użycia i testuj w stagingu przed produkcją.
Wydajność bazy często decyduje o tym, czy aplikacja „wydaje się szybka”, czy „wydaje się zawodna” — nawet jeśli jest technicznie poprawna. Z PostgreSQL dostajesz solidne fundamenty pod szybkość, ale nadal musisz rozumieć dwie kluczowe rzeczy: indeksy i plan zapytań.
Indeks jest jak spis treści dla twoich danych. Bez niego PostgreSQL może musieć przeszukiwać wiele wierszy, by znaleźć odpowiedź — ok przy kilku tysiącach rekordów, bolesne przy kilku milionach.
Objawia się to bezpośrednio w odczuciu użytkownika:
Catch: indeksy nie są za darmo. Zajmują miejsce na dysku, dodają narzut do zapisów (każdy insert/update musi utrzymać indeks) i zbyt wiele indeksów może pogorszyć przepustowość zapisów. Cel nie jest „zindeksować wszystko”, lecz „zindeksować to, czego naprawdę używasz”.
Gdy uruchamiasz zapytanie, PostgreSQL tworzy plan: które indeksy (jeśli w ogóle) użyć, w jakiej kolejności łączyć tabele, czy skanować, czy szukać i więcej. Ten planner jest głównym powodem, dla którego PostgreSQL działa dobrze w wielu obciążeniach — ale też oznacza, że dwa podobne zapytania mogą się zachowywać bardzo różnie.
Gdy coś jest wolne, chcesz zrozumieć plan zanim zaczniesz zgadywać. Dwa narzędzia pomagają:
EXPLAIN: pokazuje plan, którego PostgreSQL by użył.EXPLAIN ANALYZE: uruchamia zapytanie i raportuje, co faktycznie się wydarzyło (czasy, liczby wierszy), zwykle to właśnie potrzebujesz do debugowania.Nie musisz czytać każdego wiersza jak ekspert. Nawet na wysokim poziomie możesz zauważyć czerwone flagi, jak „sequential scan” na ogromnej tabeli lub joiny zwracające znacznie więcej wierszy niż oczekiwano.
Startupy wygrywają, trzymając dyscyplinę:
EXPLAIN (ANALYZE).Takie podejście utrzymuje aplikację szybką bez zamieniania bazy w kupę przedwczesnych optymalizacji.
PostgreSQL dobrze sprawdza się w scrappy MVP, bo możesz zacząć mało, bez wchodzenia w ślepą uliczkę. Kiedy pojawi się wzrost, zwykle nie potrzebujesz dramatycznej przebudowy — tylko sekwencji rozsądnych kroków.
Najprostszym pierwszym ruchem jest skalowanie pionowe: przejście na większy serwer (więcej CPU, RAM, szybszy dysk). Dla wielu startupów to kupuje miesiące (a czasem lata) przestrzeni bez większych zmian w kodzie. Łatwo też wycofać, jeśli przeszacujesz.
Gdy aplikacja ma dużo odczytów — dashboardy, strony analityczne, widoki admina lub raportowanie klienta — read replicas pomagają. Trzymasz jedną bazę główną obsługującą zapisy, a ciężkie zapytania odczytowe kierujesz na repliki.
Ta separacja jest szczególnie użyteczna do raportów: możesz odpalać wolniejsze, bardziej skomplikowane zapytania na replice bez ryzyka dla doświadczenia podstawowego produktu. Wymiana: repliki mogą być nieco opóźnione względem głównej, więc nadają się do widoków „prawie w czasie rzeczywistym”, nie do krytycznych flow wymagających odczytu zaraz po zapisie.
Jeśli pewne tabele osiągną dziesiątki czy setki milionów wierszy, partycjonowanie staje się opcją. Dzieli dużą tabelę na mniejsze części (często według czasu lub tenantów), co ułatwia konserwację i niektóre zapytania.
Nie każdy problem wydajności rozwiąże SQL. Cache'owanie popularnych odczytów i przenoszenie wolnej pracy (e-maile, eksporty, rollupy) do zadań w tle często zmniejsza presję na bazę i utrzymuje produkt responsywnym.
Wybór PostgreSQL to tylko połowa decyzji. Druga połowa to sposób, w jaki będziesz go prowadzić po starcie — gdy deploye są częste, ruch nieprzewidywalny, a nikt nie chce spędzać piątku wieczorem na debugowaniu miejsca na dysku.
Dobry managed PostgreSQL zajmuje się powtarzalną pracą, która cicho powoduje awarie:
To pozwala małemu zespołowi skupić się na produkcie, mając jednocześnie profesjonalne operacje.
Nie wszystkie „zarządzane Postgresy” są równe. Startupy powinny potwierdzić:
Jeśli zespół ma ograniczoną wiedzę o bazach, managed Postgres to wysoki dźwigniowy wybór. Jeśli wymagania dostępności są rygorystyczne (płatne plany, SLA B2B), priorytetyzuj HA, szybkie czasy przywracania i przejrzystość operacyjną. Jeśli budżet jest napięty, porównaj całkowite koszty: instancja + storage + backupy + repliki + egress — i zdecyduj, jaką niezawodność naprawdę potrzebujesz na najbliższe 6–12 miesięcy.
Na koniec: testuj przywracanie regularnie. Backup, którego nigdy nie przywrócono, to nadzieja, nie plan.
Aplikacja startupu rzadko ma „jednego użytkownika na raz”. Masz klientów przeglądających, zadania w tle aktualizujące rekordy, analitykę zapisującą zdarzenia i panel admina wykonujący operacje — wszystko jednocześnie. PostgreSQL jest tu silny, bo zaprojektowano go tak, by baza była responsywna przy mieszanym obciążeniu.
PostgreSQL używa MVCC (Multi-Version Concurrency Control). Prosto: gdy wiersz jest aktualizowany, PostgreSQL zwykle przechowuje starą wersję przez chwilę, tworząc nową. To oznacza, że czytelnicy często mogą dalej czytać starą wersję, podczas gdy pisarze kontynuują aktualizację, zamiast wszystkich zmuszać do czekania.
To redukuje efekt „korka”, który można zobaczyć w systemach, gdzie odczyty blokują zapisy (albo odwrotnie) częściej.
Dla aplikacji z wieloma użytkownikami MVCC pomaga w typowych wzorcach:
PostgreSQL wciąż używa blokad dla niektórych operacji, ale MVCC sprawia, że rutynowe odczyty i zapisy współistnieją bez większych problemów.
Te stare wersje wierszy nie znikają od razu. PostgreSQL odzyskuje przestrzeń przez VACUUM (zwykle obsługiwane automatycznie przez autovacuum). Jeśli sprzątanie nie nadąża, pojawia się „bloat” (zmarnowana przestrzeń) i wolniejsze zapytania.
Praktyczny wniosek: monitoruj bloat tabel i długotrwałe transakcje. Długie transakcje mogą blokować sprzątanie, pogarszając bloat. Kontroluj wolne zapytania, sesje trwające „wieczność” i czy autovacuum radzi sobie z obciążeniem.
Wybór bazy wcześnie to mniej wybór „najlepszej” i więcej dopasowanie do kształtu produktu: model danych, wzorce zapytań, umiejętności zespołu i jak szybko wymagania będą się zmieniać.
PostgreSQL jest częstym domyślnym wyborem, bo radzi sobie dobrze z mieszanką potrzeb: silne transakcje ACID, bogate funkcje SQL, dobre opcje indeksowania i miejsce na ewolucję schematu. Dla wielu startupów to „jedna baza”, która może obsłużyć rozliczenia, konta użytkowników, zapytania zbliżone do analitycznych i nawet dane pół-strukturalne przez JSONB — bez wczesnego rozbijania na wiele systemów.
Gdzie może wymagać więcej pracy: spędzisz więcej czasu na modelowaniu danych i strojenia zapytań w miarę wzrostu, szczególnie jeśli dużo korzystasz ze złożonych joinów i raportów.
MySQL może być świetnym wyborem, szczególnie do konwencjonalnych OLTP (typowe zapisy/odczyty webowe) i dla zespołów, które już go znają. Jest szeroko wspierany, ma dojrzałe managed oferty i bywa łatwiejszy w obsłudze w niektórych środowiskach.
Kompromis: w zależności od potrzeb funkcjonalnych (zaawansowane indeksowanie, złożone zapytania, rygorystyczność ograniczeń), PostgreSQL często daje więcej narzędzi „od ręki”. To nie czyni MySQL „gorszym” — po prostu niektóre zespoły sooner napotkają granice funkcji.
Bazy NoSQL błyszczą, gdy masz:
Kompromis: zwykle tracisz część możliwości zapytań ad-hoc, ograniczeń między encjami lub wielowersyjnych transakcji — więc często odtwarzasz te mechanizmy w kodzie aplikacji.
Wybierz PostgreSQL, jeśli potrzebujesz modelowania relacyjnego, ewoluujących wymagań i elastycznego zapytań.
Wybierz MySQL, jeśli aplikacja jest konwencjonalna, zespół zna MySQL i cenisz sobie operacyjną znajomość.
Wybierz NoSQL, jeśli wzorzec dostępu jest przewidywalny (na klucz) lub optymalizujesz pod bardzo dużą przepustowość zapisów i proste zapytania.
Jeśli nie jesteś pewien, PostgreSQL często jest najbezpieczniejszym domyślnym wyborem, bo zostawia więcej drzwi otwartych bez wczesnego zobowiązania do wyspecjalizowanego systemu.
Wybór bazy to też wybór biznesowej relacji. Nawet jeśli produkt dziś jest świetny, ceny, warunki i priorytety mogą się zmieniać później — często wtedy, gdy startup najmniej jest w stanie wchłonąć niespodzianki.
Z PostgreSQL rdzeń jest otwartoźródłowy na permisywnej licencji. W praktyce oznacza to, że nie płacisz za korzystanie z samego PostgreSQL per-core czy za funkcje, i nie jesteś ograniczony do jednej wersji dostawcy, by być zgodnym.
„Vendor lock-in” zwykle przejawia się dwojako:
PostgreSQL zmniejsza te ryzyka, bo zachowanie bazy jest dobrze znane, szeroko implementowane i wspierane u wielu providerów.
PostgreSQL może działać prawie wszędzie: na laptopie, VM, Kubernetes, czy w managed service. Ta elastyczność to opcjonalność — jeśli provider podniesie ceny, ma wzór awarii, którego nie możesz zaakceptować, lub nie spełnia wymogów compliance, możesz przenieść się z mniejszą ilością przepisywania.
To nie znaczy, że migracje są bezwysiłkowe, ale daje silniejszą pozycję do negocjacji i planowania.
PostgreSQL opiera się na standardowym SQL i ogromnym ekosystemie narzędzi: ORM-y, frameworki migracji, narzędzia backupu i monitoringu. Znajdziesz PostgreSQL u wielu chmur i specjalistów, i większość zespołów potrafi go obsłużyć.
Aby zachować wysoką przenośność, bądź ostrożny przy:
Opcjonalność to nie tylko gdzie hostujesz — to jak jasno zdefiniowany jest twój model danych. Wczesne nawyki procentują później:
Te praktyki ułatwiają audyty, reagowanie na incydenty i przenosiny dostawcy — bez spowalniania MVP.
Nawet zespoły, które wybierają PostgreSQL z dobrych powodów, mogą potknąć się o kilka przewidywalnych problemów. Dobra wiadomość: większość jest do uniknięcia, jeśli je wcześnie zauważysz.
Częsty błąd to przeładowany JSONB: traktowanie JSONB jako zlewni wszystkiego „zmodelujemy później”. JSONB jest świetny dla elastycznych atrybutów, ale duże, głęboko zagnieżdżone dokumenty stają się trudne do walidacji, indeksowania i kosztowne w aktualizacji.
Trzymaj podstawowe encje relacyjne (users, orders, subscriptions), a JSONB używaj do naprawdę zmiennych pól. Jeśli często filtrujesz po kluczach JSONB, czas przenieść te pola do prawdziwych kolumn.
Inny klasyk: brakujące indeksy. Aplikacja działa przy 1 000 wierszy, a potem pada przy 1 000 000. Dodaj indeksy bazując na realnych wzorcach zapytań (WHERE, JOIN, ORDER BY) i sprawdzaj EXPLAIN, gdy coś jest wolne.
Wreszcie, uważaj na tabele o nieograniczonym wzroście: logi zdarzeń, ślady audytu i tabele sesji, które nigdy nie są czyszczone. Dodaj polityki retencji, partycjonowanie gdy trzeba i zaplanowane czyszczenia od początku.
PostgreSQL ma limity połączeń; nagły skok ruchu plus jedno-połączenie-na-żądanie może je wyczerpać. Używaj poolera i utrzymuj krótkie transakcje.
Unikaj N+1 queries przez pobieranie powiązanych danych partiami lub joinami. Planuj też wolne migracje: przepisanie dużej tabeli może blokować zapisy. Preferuj migracje addytywne i backfille.
Włącz logi wolnych zapytań, śledź podstawowe metryki (połączenia, CPU, I/O, hit rate cache) i ustaw proste alerty. Złapiesz regresje zanim zauważą je użytkownicy.
Zaprojektuj minimalny schemat, przetestuj 3–5 kluczowych zapytań pod obciążeniem i wybierz podejście hostingowe (managed PostgreSQL vs self-hosted) bazując na komforcie operacyjnym zespołu — nie tylko koszcie.
Jeśli celem jest szybkie działanie przy zachowaniu konwencjonalnego, skalowalnego stosu, rozważ wdrożenie workflowu, który od pierwszego dnia przewiduje Postgresa. Na przykład Koder.ai pozwala zespołom budować aplikacje web/serwer/mobilne przez czat, generując znajome architektury (React + Go + PostgreSQL) z opcjami trybu planowania, eksportu źródeł, wdrożenia/hostingu i snapshotów/rollbacków — przydatne, jeśli chcesz szybkość bez zamknięcia się w black-boxie no-code.
Oznacza to, że PostgreSQL jest bezpiecznym, szeroko kompatybilnym wyborem startowym, który można wybrać wcześnie bez długiej oceny.
Dla wielu startupów zmniejsza to obciążenie decyzjami, bo jest powszechnie znany, łatwy do rekrutacji, dobrze wspierany przez narzędzia i hosting, i rzadko wymusza wczesne przepisywanie systemu, gdy wymagania się zmieniają.
PostgreSQL to baza relacyjna, która dobrze pasuje do kształtu większości produktów startujących: „użytkownicy + konta + uprawnienia + rozliczenia + aktywność”.
Daje to:
Użyj PostgreSQL, gdy potrzebujesz poprawności przy wielu powiązanych zapisach (np. utworzyć zamówienie + zarezerwować stan magazynowy + zarejestrować intencję płatności).
Opakuj te kroki w transakcję, aby zakończyły się wszystkie razem albo żadna. To zapobiega częściowym stanom (brakujące zamówienia, podwójne obciążenia, osierocone rekordy), gdy coś zawiedzie w trakcie żądania.
Ograniczenia i klucze obce wymuszają reguły na poziomie bazy danych, więc błędne stany nie przedostają się do systemu.
Przykłady:
UNIQUE(email) zapobiega powielonym kontomCHECK(quantity >= 0) blokuje nieprawidłowe wartościTo zmniejsza poleganie na tym, że każdy fragment kodu „pamięta” walidować dane.
Użyj JSONB jako „zaworu bezpieczeństwa” dla pól, które naprawdę są zmienne lub szybko się rozwijają, trzymając jednocześnie podstawowe encje relacyjne.
Dobre zastosowania:
Unikaj trzymania kluczowych pól do raportów/rozliczeń/uprawnień wyłącznie w JSONB, jeśli potrzebujesz silnych ograniczeń, joinów lub przejrzystej analityki.
Indeksuj części, które zapytujesz.
Popularne opcje:
props @> '{"beta":true}')(props->>'plan'))Bez indeksów filtry JSONB często prowadzą do pełnych skanów tabel wraz ze wzrostem liczby wierszy, zmieniając wygodny skrót w wolne endpointy.
Rozszerzenia dodają możliwości bez wdrażania nowej usługi.
Przydatne przykłady:
pg_trgm do fuzzy/odpornego na literówki wyszukiwania tekstuuuid-ossp do generowania UUID w SQLZanim się na nie zdecydujesz, sprawdź, czy twój managed provider wspiera dane rozszerzenie i przetestuj wydajność/aktualizacje na stagingu.
Zacznij od naprawy konkretnego wolnego zapytania, zamiast zgadywać.
Praktyczny workflow:
Typowa ścieżka to kroki inkrementalne:
Uzupełnij to cache'em i pracami w tle, aby zmniejszyć obciążenie bazy przy drogich odczytach i zadaniach wsadowych.
Managed Postgres zwykle oferuje backupy, patchowanie, monitoring i opcje HA — ale sprawdź szczegóły.
Lista kontrolna:
Również planuj limity połączeń: używaj poolera i utrzymuj krótkie transakcje, aby nie wyczerpać bazy podczas skoków ruchu.
EXPLAIN ANALYZE, aby zobaczyć, co faktycznie się wydarzyłoWHERE/JOIN/ORDER BYPamiętaj też, że indeksy kosztują: więcej miejsca na dysku i wolniejsze zapisy, więc dodawaj je wybiórczo.