Napisz do nas

Backend i baza z AI. Postgres, Supabase czy coś innego

AI i Automatyzacje • Łukasz Ślusarski Łukasz Ślusarski • • 16 min czytania
Backend i baza z AI. Postgres, Supabase czy coś innego

Do większości aplikacji budowanych z agentem AI wystarczy PostgreSQL: własny, zarządzany (na przykład Neon) albo w pakiecie z Supabase. To najczęściej używana baza w ankiecie Stack Overflow 2025, 55,6% respondentów. SQLite starcza przy jednym serwerze i małej liczbie zapisów, a Firebase przy danych w dokumentach i aplikacjach mobilnych. Język backendu dobierz do frontendu.

Łukasz Ślusarski, important.is. Stan na 11 listopada 2026. Opracowane na podstawie Stack Overflow Developer Survey 2025, dokumentacji PostgreSQL, SQLite, Supabase i Firebase oraz cenników producentów pobranych 11 listopada 2026.

Agent AI napisze ci backend w godzinę. Za pół roku ktoś musi go utrzymać, zmienić w nim tabelę i przenieść dane, gdy skończy się darmowy plan. Dlatego wybór bazy i miejsca, w którym ona stoi, jest decyzją, której agent za ciebie nie podejmie. Podpowie, ale pójdzie za tym, co mu każesz, albo za tym, co sam uzna za domyślne.

Ten tekst jest dla osób i firm, które budują aplikacje z agentami (Claude Code, Codex, Cursor) i trzymają kod na GitHubie. To nie jest wpis o treściach na stronie. Jeśli chodzi ci o WordPressa albo system zarządzania treścią, zajrzyj do artykułu WordPress vs headless CMS. Tutaj mówimy o danych aplikacji: użytkownikach, zamówieniach, płatnościach, uprawnieniach. U nas portal klienta działa na Next.js, Drizzle i Postgresie, a sesje trzymamy w bazie jako skrót SHA-256 (opis na końcu).

W skrócie: jaką bazę i jaki backend wybrać

Twoja sytuacjaRekomendacjaDlaczego
Aplikacja z użytkownikami, relacjami i płatnościami, nie chcesz prowadzić serweraSupabase albo zarządzany PostgresZwykły Postgres pod spodem, dane możesz wynieść gdzie indziej
Narzędzie wewnętrzne, jeden serwer, mało równoczesnych zapisówSQLiteJeden plik, zero administracji, dokumentacja sama podaje granice
Aplikacja mobilna z danymi w dokumentach, mocno osadzona w usługach GoogleFirebase (Firestore)Model dokumentowy i SDK, ale bez tabel i relacji jak w SQL
Masz serwer i ktoś pilnuje kopii zapasowychPostgres w Dockerze na własnym serwerzeNajniższy koszt stały, całą opiekę bierzesz na siebie
Język backenduTypeScript, jeśli frontend też jest w TypeScripcie. Python, gdy aplikacja kręci się wokół danych i modeliJeden język w repozytorium to mniej kontekstu dla agenta (opinia)
Pogadajmy

Zrobić to razem?

Wdrażam takie rzeczy w firmach na co dzień. Umów 30 minut, pogadamy konkretnie o Twoim przypadku. Bez prezentacji sprzedażowej.

Umów bezpłatną rozmowę →
Łukasz Ślusarski
Łukasz ŚlusarskiTwórca important.is

Czym backend aplikacji różni się od CMS?

Backend aplikacji to serwer, baza danych i logika, które przechowują i zmieniają dane twoich użytkowników: konta, zamówienia, uprawnienia, wpisy w historii. System zarządzania treścią, taki jak WordPress, przechowuje teksty i obrazy, które redakcja publikuje na stronie. Różnica wygląda na kosmetyczną, ale zmienia wszystko: w CMS ważne są edytor, role redaktorów i szybkie wyświetlanie stron, a w aplikacji transakcje, spójność danych i zapytania łączące wiele tabel. Edytor, role redaktorów i szablony stron to zupełnie inna potrzeba niż system rezerwacji czy panel klienta. Blog firmowy nie potrzebuje bazy zaprojektowanej pod płatności, a panel klienta nie potrzebuje edytora treści. Jeśli nie masz użytkowników, którzy się logują i zmieniają dane, ten artykuł prawdopodobnie cię nie dotyczy. Jeśli masz i jedno, i drugie, trzymaj te światy osobno: treści w CMS, dane aplikacji w bazie aplikacji, a połączenie między nimi niech będzie jedno i opisane.

Granice dobrze opisuje nasz wcześniejszy wpis o WordPressie i headless CMS. Reszta tego artykułu zakłada, że budujesz aplikację, nie stronę.

Jaka baza danych jest najpopularniejsza?

PostgreSQL. W ankiecie Stack Overflow Developer Survey 2025 wskazało go 55,6% wszystkich respondentów i 58,2% zawodowych programistów. Na drugim miejscu jest MySQL (40,5%), na trzecim SQLite (37,5%), dalej Redis (28%) i MongoDB (24%). Usługi, które opakowują Postgresa w gotowy backend, zaczynają od niższego poziomu: Supabase wskazało 6% respondentów, a Firebase Realtime Database 5% (osobno ankieta wymienia Cloud Firestore, 5,7% wszystkich respondentów). To popularność, nie jakość: ankieta mówi, czego ludzie używają, nie co jest dla ciebie najlepsze. Ma jednak praktyczny sens przy projekcie utrzymywanym latami. Łatwiej znaleźć kogoś, kto zna Postgresa, niż kogoś, kto zna mniej popularne rozwiązanie. Postgres nie jest przy tym modą: strona projektu wymienia ponad 35 lat rozwoju i podaje, że technologia sięga 1986 roku. Liczby z ankiety mówią tylko tyle, że Postgresa używa najwięcej respondentów, a SQLite jest 3 punkty procentowe za MySQL.

Wykres poniżej zestawia bazy i języki programowania z tej samej ankiety, tak by dało się porównać wybór bazy z wyborem języka.

Wykres słupkowy z ankiety Stack Overflow 2025: PostgreSQL 55,6%, MySQL 40,5%, SQLite 37,5%, oraz JavaScript 66%, Python 57,9%, TypeScript 43,6%

Uwaga na próbę: to ankieta, nie spis powszechny, więc opisuje respondentów, a nie cały rynek ani firmy z własnymi wewnętrznymi standardami. Metodologię opisuje strona ankiety i jej nie analizowałem. Sekcji o tym, co programiści chcą dalej używać, nie udało mi się odczytać, więc jej nie cytuję.

Wolisz to zlecić? 30 minut, bez zobowiązań. Sprawdzimy czy to ma sens.
Zarezerwuj termin →

Czy zaczynać od PostgreSQL?

Moim zdaniem tak, jeśli aplikacja ma użytkowników i dane w relacjach. To rekomendacja, nie wynik badania: nie znalazłem niezależnych pomiarów, które pokazywałyby, że agenci AI piszą lepszy kod dla Postgresa niż dla innych baz. Argumenty są zwyczajne i sprawdzalne. Postgres jest wolnym oprogramowaniem, ma typy JSON i JSONB, więc część danych bez sztywnej struktury też w nim zmieścisz, i da się go rozszerzać, co dokumentacja podaje na pierwszej stronie. Wersje są przewidywalne: każda wersja główna dostaje wsparcie przez 5 lat od premiery, a poprawki bezpieczeństwa wychodzą co najmniej raz na trzy miesiące. Obecnie wspierane są wersje od 14 do 18. Wersja 14 kończy wsparcie 12 listopada 2026, czyli jutro względem daty tego wpisu, więc jeśli dostawca albo agent zaproponuje ci właśnie ją, wybierz nowszą. Aktualizacja wersji głównej wymaga zrzutu i odtworzenia danych albo narzędzia pg_upgrade, więc nie jest to zmiana na jedno kliknięcie. Dla aplikacji, którą ktoś będzie rozwijał za rok, brak niespodzianek jest ważniejszy niż nowinka.

Kiedy SQLite wystarczy?

SQLite wystarczy, gdy aplikacja działa na jednym serwerze, zapisów jest niewiele naraz, a dane mieszczą się poniżej około terabajta. Dokumentacja SQLite stawia sprawę jasno: baza obsługuje dowolną liczbę równoczesnych odczytów, ale w danej chwili tylko jeden zapis. Zapis zwykle trwa milisekundy, więc zapisujący po prostu czekają w kolejce. Strony, które mają mniej niż 100 tysięcy odwiedzin dziennie, zdaniem autorów powinny działać z SQLite bez kłopotu, choć podkreślają, że to ostrożne oszacowanie, nie twarda granica. Nie nadaje się do sytuacji, gdy wiele komputerów korzysta z tego samego pliku przez sieć, bo blokady plików w sieciowych systemach plików bywają zawodne i grozi to uszkodzeniem bazy. Nie nadaje się też do serwisu, który intensywnie zapisuje albo potrzebuje wielu serwerów naraz. Zasada z dokumentacji: wielu piszących, duże dane albo baza oddzielona od aplikacji siecią, to powód, by wybrać serwer bazodanowy. Dla narzędzia wewnętrznego, prototypu i aplikacji jednej firmy SQLite jest często najtańszą decyzją.

Jest też wariant w chmurze: Cloudflare D1 to baza oparta na SQLite. Dokumentacja podaje limit 10 GB na bazę w planie płatnym, 500 MB w darmowym, i zaznacza, że limitu 10 GB nie da się zwiększyć. Każda baza D1 przetwarza zapytania po kolei, więc skalowanie polega na wielu mniejszych bazach, nie na jednej dużej.

Supabase czy Firebase?

Różnica leży w modelu danych. Supabase daje każdemu projektowi pełną bazę Postgres, a nie warstwę abstrakcji, i buduje na niej logowanie, pliki, aktualizacje na żywo i funkcje serwerowe. Firebase to rodzina usług Google, której baza Cloud Firestore jest dokumentowa: według dokumentacji nie ma w niej tabel ani wierszy, nie wymaga schematu, a dane układa się w dokumentach i podkolekcjach zamiast w relacjach. Dla danych, które naturalnie łączą się ze sobą (klient, zamówienia, pozycje, płatności), model SQL jest zwykle prostszy do opisania i do sprawdzenia. Firestore sprawdza się tam, gdzie dokument jest jednostką pracy, a aplikacja mobilna korzysta z pakietu usług Google. Dane z Supabase da się przenieść do zwykłego Postgresa, bo to on jest pod spodem. Jak wyglądałoby przeniesienie danych z Firestore, nie sprawdzałem, więc przed wyborem sprawdź to w dokumentacji Firebase. Supabase można też uruchomić u siebie w Dockerze, ale dokumentacja ostrzega: wtedy odpowiadasz za serwer, zabezpieczenia, kopie, wysoką dostępność i monitoring, a wsparcie jest społecznościowe.

Narzędzia, w których AI generuje aplikację z opisu, często sięgają po gotowy backend. Lovable w swojej dokumentacji opisuje integrację, w której Supabase jest backendem aplikacji: bazą, logowaniem, plikami i funkcjami serwerowymi. Kwestie uprawnień na poziomie wierszy i sekretów opisujemy w artykule o bezpieczeństwie kodu z AI.

Czy zamiast Supabase wystarczy zarządzany Postgres?

Tak, jeśli sam napiszesz logowanie i resztę backendu albo agent je napisze, a ty to zrecenzujesz. Zarządzany Postgres, na przykład Neon, to sama baza bez dodatków: ustawiasz połączenie, resztą zajmuje się twój kod. Z danych z cennika Neon (pobrano 11.11.2026): plan darmowy daje 100 CU godzin obliczeń i 1 GB na projekt, a baza usypia się po 5 minutach bez ruchu i budzi przy kolejnym zapytaniu, według producenta zwykle w kilkaset milisekund. Plan Launch rozlicza się według zużycia, bez miesięcznego minimum; producent podaje przykład około 15 USD dla małej, nieregularnie używanej bazy. Supabase kosztuje od 25 USD miesięcznie w planie Pro (8 GB bazy na projekt, 100 tysięcy aktywnych użytkowników miesięcznie, kopie przez 7 dni), a w planie darmowym projekt pauzuje się po tygodniu bez ruchu. Neon w planie darmowym, według cennika, nie pauzuje projektów z powodu bezczynności. Pakiet Supabase oszczędza pisania, zarządzany Postgres daje mniej do utrzymania po stronie dostawcy, ale więcej kodu po twojej.

Tabela zbiera limity z cenników czterech usług, żeby przed wyborem planu nie trzeba było otwierać czterech stron.

Tabela limitów planów baz danych: Supabase Free i Pro, Neon Free i Launch, Firestore Spark, Cloudflare D1 Free i Paid, z ceną, rozmiarem bazy i ograniczeniami

Ta sama informacja w formie tekstowej, razem z limitem ruchu i rozliczeniem:

Usługa i planCenaCo wchodzi w cenęCo trzeba wiedzieć
Supabase Free0 USD500 MB bazy, 1 GB plików, 5 GB ruchu wychodzącego, 50 tys. aktywnych użytkownikówPauza po 1 tygodniu bez ruchu, 2 aktywne projekty, brak kopii zapasowych
Supabase Prood 25 USD miesięcznie8 GB bazy na projekt, 100 GB plików, 250 GB ruchu, 10 USD kredytu na obliczeniaKopie przez 7 dni, limit wydatków domyślnie włączony, odtwarzanie do punktu w czasie za 100 USD miesięcznie za każde 7 dni
Neon Free0 USD100 CU godzin na projekt, 1 GB na projekt, 5 GB transferuUśpienie po 5 minutach, po przekroczeniu 1 GB zapisy są blokowane, historia 6 godzin
Neon Launchwedług zużycia0,106 USD za CU godzinę, 0,35 USD za GB miesięcznieHistoria do 7 dni, uśpienie można wyłączyć
Firestore (Spark)0 USD1 GiB danych, 10 GiB ruchu miesięcznie50 tys. odczytów i 20 tys. zapisów dziennie. Usługi takie jak Cloud Functions czy Cloud Storage wymagają planu Blaze
Cloudflare D1Free albo Workers PaidFree: 500 MB, do 10 baz. Paid: 10 GB na bazęBaza przetwarza zapytania po kolei, limitu 10 GB nie można zwiększyć

Ceny i limity zmieniają się. Traktuj tabelę jako stan z 11 listopada 2026 i przed decyzją otwórz cennik producenta. Koszty serwerów i wdrożeń opisujemy w artykule o hostingu.

Jaki język wybrać na backend?

Ten, w którym napisany jest frontend, jeśli nie masz powodu, by zrobić inaczej. W ankiecie Stack Overflow 2025 najczęściej wskazywano JavaScript (66%), Python (57,9%) i TypeScript (43,6%), dalej Java (29,4%) i Go (16,4%). W raporcie GitHub Octoverse 2025 TypeScript w sierpniu 2025 wyprzedził Python i JavaScript pod względem liczby miesięcznych współtwórców: 2 636 006, o 66,6% więcej niż rok wcześniej. Raport tłumaczy to przejściem na języki z typami, bo kod pisany z agentem jest w produkcji niezawodniejszy, i cytuje badanie z 2025 roku: 94% błędów kompilacji w kodzie generowanym przez modele to błędy typów. Raport zastrzega, że inne rankingi mogą wciąż stawiać wyżej JavaScript albo Python. Z liczb nie wynika, że TypeScript jest najlepszy do backendu. Moja opinia: TypeScript na backend, gdy frontend jest w TypeScripcie, bo agent widzi ten sam kod i te same typy po obu stronach. Python ma sens, gdy sercem aplikacji są dane, skrypty i modele. Go i Rust zostaw na przypadki, w których masz konkretny powód.

Jak to wybrać krok po kroku?

Zacznij od trzech pytań: czy dane tworzą relacje, czy aplikacja to jeden serwer z niewielkim ruchem i czy chcesz gotowe logowanie oraz pliki bez własnego serwera bazy. Z odpowiedzi wychodzi jeden z pięciu wyników: Firestore, SQLite, Supabase, zarządzany Postgres albo Postgres u siebie. Schemat poniżej zbiera to w jedno drzewo. To moja rekomendacja oparta na dokumentacji SQLite, Supabase i Firebase, nie reguła, więc traktuj ją jako punkt wyjścia do rozmowy z zespołem. Przy aplikacji z użytkownikami, płatnościami i planami na lata wynik prawie zawsze kończy się na Postgresie, a pytanie dotyczy tylko tego, kto go prowadzi: ty, dostawca z gotowym pakietem czy dostawca samej bazy. Jeśli odpowiedź brzmi SQLite albo Firestore, zapisz w repozytorium, dlaczego, żeby osoba, która przejmie projekt, nie musiała zgadywać, czy to świadoma decyzja, czy przypadek. Ten jeden akapit oszczędza później godziny.

Schemat decyzyjny wyboru bazy danych: Firestore dla dokumentów, SQLite dla jednego serwera, Supabase, zarządzany Postgres lub własny Postgres dla pozostałych przypadków

W praktyce zrób trzy rzeczy, zanim pozwolisz agentowi pisać backend. Po pierwsze, napisz w pliku z instrukcjami dla agenta, jaka baza i jaki język zostały wybrane oraz że zmiany struktury danych mają trafiać do repozytorium jako pliki migracji, nie jako ręczne zmiany w panelu. To rekomendacja, a nie wynik badania. Po drugie, sprawdź, jak wyeksportować dane z wybranej usługi, zanim wpiszesz tam pierwszego użytkownika. Po trzecie, sprawdź datę końca wsparcia wersji bazy, którą dostawca ci przydzielił. Organizację samego kodu, czyli podział na moduły i usługi, opisujemy w artykule monolit czy mikroserwisy.

Czego to nie rozwiąże i kiedy to zły pomysł?

Wybór bazy nie naprawi złego modelu danych, braku kopii zapasowych ani niesprawdzonego kodu. Agent może założyć tabele, które działają w demonstracji, a rozsypują się przy pierwszej zmianie wymagań. Dlatego przeczytaj schemat, który wygenerował, tak samo jak czytasz kod. Wybór usługi zarządzanej nie zdejmuje też z ciebie odpowiedzialności za dane: darmowy plan Supabase nie ma kopii zapasowych, a w Neon historia w planie darmowym to 6 godzin. Zły pomysł to Firestore do danych, które są z natury relacyjne, SQLite przy wielu równoczesnych zapisach z różnych komputerów i darmowy plan do aplikacji, na której polega firma. Zły pomysł to też samodzielne prowadzenie bazy bez nikogo, kto zna kopie zapasowe i aktualizacje. Nie znalazłem niezależnego badania, które porównywałoby jakość kodu generowanego przez agentów dla różnych baz, więc każde twierdzenie w stylu „agenci lepiej znają X” traktuj jako opinię.

Co trzymamy w bazie portalu klienta, a czego nie?

Portal klienta działa na Next.js, Drizzle i Postgresie. Zadania, statusy i załączniki mają źródło prawdy w ClickUpie, a nasza baza trzyma ich lustro pod historię i wyszukiwarkę. Powód zapisany w dokumentacji: ClickUp nie zwraca komentarzy razem z listą zadań, tylko osobnym zapytaniem na każde zadanie, więc szukanie po komentarzach na żywo oznaczałoby setki wywołań na jedno wciśnięcie klawisza. Na własność bierzemy to, czego ClickUp nie zna: konta, sesje, powiadomienia i informację, kto z ludzi klienta co zgłosił.

Sesje trzymamy w bazie, nie w tokenie JWT. W tabeli leży skrót SHA-256 tokenu z ciasteczka, a sam token nie istnieje nigdzie u nas, ważność to 7 dni. Dzięki temu wyciek bazy nie daje gotowych sesji. Testy integracyjne uruchamiamy na prawdziwym Postgresie, nie na atrapie. Wniosek, to opinia: gdy zewnętrzne API ma ograniczenie, które boli, lustro w własnej bazie bywa prostsze niż obejścia po stronie zapytań.

Najczęstsze pytania

Czy Supabase nadaje się do produkcji?

Plan Pro (od 25 USD miesięcznie) nie jest pauzowany z powodu bezczynności i ma kopie zapasowe przez 7 dni. Projekty w planie darmowym są pauzowane po tygodniu bez ruchu i nie mają kopii. Do aplikacji, na której polega firma, wybierz płatny plan i sprawdź uprawnienia danych zgodnie z artykułem o bezpieczeństwie.

Supabase czy Firebase, co wybrać?

Supabase, jeśli dane mają relacje i chcesz zachować możliwość przeniesienia ich do zwykłego Postgresa. Firebase, jeśli budujesz aplikację mobilną na usługach Google i dane naturalnie układają się w dokumenty. Decyduje model danych, nie moda.

Czy SQLite nadaje się na produkcję?

Tak, przy jednym serwerze, małej liczbie równoczesnych zapisów i danych poniżej około terabajta. Dokumentacja SQLite mówi, że strony poniżej 100 tysięcy odwiedzin dziennie powinny działać dobrze, ale to ostrożne oszacowanie. Przy wielu piszących wybierz serwer bazy.

Czy zaczynać od TypeScriptu?

Jeśli frontend jest w TypeScripcie, to naturalny wybór: ten sam język i te same typy po obu stronach. Octoverse 2025 pokazuje, że TypeScript stał się najczęściej używanym językiem na GitHubie, ale to nie dowód, że jest najlepszy do backendu.

Czy do aplikacji z AI potrzebna jest baza wektorowa?

Nie musi być osobna. Dokumentacja Supabase wymienia rozszerzenie pgvector do przechowywania wektorów w zwykłym Postgresie. Nie sprawdzałem, od jakiej skali osobna baza wektorowa zaczyna się opłacać, więc tego progu nie podaję.

Czy mogę przenieść dane z darmowego planu na własny serwer?

W przypadku Postgresa tak: dokumentacja Supabase opisuje import z zrzutu pg_dump i z innej bazy Postgres, a Supabase można uruchomić u siebie w Dockerze. Zrób próbny eksport, zanim aplikacja trafi do użytkowników.

Którą wersję Postgresa wybrać?

Najnowszą wspieraną przez dostawcę. Stan na 11 listopada 2026: wspierane są wersje od 14 do 18, a wersja 14 kończy wsparcie 12 listopada 2026. Wersja 18 ma wsparcie do 14 listopada 2030.

Źródła

Czytaj również

Stan na 11 listopada 2026. Ceny, limity i wersje zmieniają się, przed decyzją sprawdź je u producenta.

raz na jakiś czas

Zostań w pętli

Nowe artykuły, narzędzia i case study prosto na maila. Bez spamu, bez sprzedaży.

To pole jest używane do walidacji i powinno pozostać niezmienione.
Zgodawymagane

Czytaj również