Twórcy SQLite podają w dokumentacji liczbę, której nie ma w popularnych porównaniach: serwis z ruchem poniżej stu tysięcy odsłon dziennie powinien działać na tej bazie bez problemu. Sami nazywają ten próg ostrożnym szacunkiem i dodają, że silnik obsłużył dziesięciokrotnie większy ruch. Większość projektów, w których ktoś rozważa zestawienie SQLite vs PostgreSQL, nie zbliża się do tej granicy nawet w najlepszym miesiącu. Granica leży gdzie indziej.
Gdzie naprawdę leży próg, przy którym SQLite przestaje wystarczać
Strona Appropriate Uses For SQLite jest w tej sprawie zaskakująco szczera, bo wymienia przypadki, w których sam producent odsyła do bazy z serwerem.
Pierwszy: wiele programów klienckich wysyła zapytania do tej samej bazy przez sieć. Wtedy dokumentacja wprost zaleca silnik klient-serwer.
Drugi: serwis intensywnie zapisujący dane albo tak obciążony, że wymaga kilku serwerów aplikacyjnych. Baza w pliku leży na jednym dysku, więc drugiego serwera nią nie obsłużysz.
Trzeci: bardzo duże zbiory. Pojedyncza baza SQLite jest ograniczona do 281 terabajtów, co dla większości projektów jest liczbą teoretyczną.
Czwarty i najważniejszy: duża współbieżność zapisu. Silnik obsługuje nieograniczoną liczbę jednoczesnych czytających, ale w danej chwili pozwala pisać tylko jednemu.
Zapamiętaj ten ostatni punkt, bo to on decyduje w praktyce. Nie rozmiar pliku ani liczba rekordów.
Jeden zapis naraz, czyli ograniczenie, które faktycznie boli
Wyobraź sobie panel, z którego korzysta dziesięć osób. Każda co kilka minut zapisuje formularz. Zapisy trwają milisekundy i nigdy się nie spotykają, więc SQLite obsłuży to bez drgnienia.
Teraz aplikacja, która przy każdym żądaniu dopisuje wiersz do dziennika zdarzeń, odświeża licznik i aktualizuje sesję. Przy wielu równoczesnych żądaniach zapisu transakcje zaczynają na siebie czekać. Jeśli oczekiwanie przekroczy ustawiony limit, aplikacja dostaje błąd o zajętej bazie, a czasy odpowiedzi rosną, chociaż serwer się nudzi.
Tryb WAL, czyli dziennik zapisów wyprzedzających, przesuwa tę granicę wyraźnie. Dokumentacja opisuje to prosto: czytający nie blokują piszącego, a piszący nie blokuje czytających. Zapis i odczyt mogą iść równocześnie.
Jeden zapis naraz zostaje jednak dalej, bo plik dziennika jest jeden. Do tego dochodzi ograniczenie, o którym łatwo się przejechać: WAL nie działa na sieciowym systemie plików, więc wszystkie procesy korzystające z bazy muszą siedzieć na tym samym komputerze. Na współdzielonym hostingu z katalogiem montowanym po sieci to bywa niespodzianką.
Co daje PostgreSQL, czego w SQLite nie ma
Lista jest krótsza, niż podpowiada intuicja, ale każda pozycja waży.
Wielu piszących naraz. PostgreSQL obsługuje równoległe zapisy z wielu połączeń i to jest jego główna przewaga w tym zestawieniu.
Dostęp przez sieć. Baza stoi osobno, a aplikacja łączy się z nią po sieci. Dzięki temu możesz mieć dwa serwery aplikacji i jedną bazę.
Kontrola typów. Domyślnie SQLite stosuje elastyczne typowanie i potrafi zachować tekst w kolumnie liczbowej. Tabele oznaczone jako STRICT wymuszają typy, ale trzeba o nie zadbać świadomie. PostgreSQL pilnuje tego standardowo, co przy większym zespole bywa ratunkiem.
Uprawnienia i role. W SQLite dostęp do bazy to dostęp do pliku. W PostgreSQL nadajesz uprawnienia na poziomie tabel i wierszy.
Rozszerzenia. PostGIS do danych przestrzennych, pgvector do wyszukiwania semantycznego, pełnotekstowe wyszukiwanie po polsku. SQLite ma własne odpowiedniki części z tych rzeczy, ale w mniejszej skali.
Na 16 września 2026 aktualne wydanie stabilne PostgreSQL to 18.6 z 13 sierpnia 2026, a każda wersja główna ma pięć lat wsparcia. SQLite wydał wersję 3.53.4 24 lipca 2026.
Kopie zapasowe i wdrożenie, czyli codzienna różnica
Porównania skupiają się na wydajności, a zespół najwięcej czasu traci na obsłudze. Tu różnica jest bardzo wyraźna.
Baza SQLite to jeden plik, więc kopia zapasowa wygląda jak kopia pliku. Pojawia się przy tym pułapka: kopiowanie w trakcie zapisu potrafi dać uszkodzony plik, zwłaszcza w trybie WAL, gdzie obok bazy leżą jeszcze dwa pliki pomocnicze. Spójną kopię działającej bazy robi polecenie VACUUM INTO, które zapisuje jej obraz do nowego pliku.
W PostgreSQL strategia zależy od potrzeb. Prosty zrzut logiczny wykonuje pg_dump i dla wielu projektów to wystarcza. Odtwarzanie do wybranego punktu w czasie wymaga natomiast kopii bazowej oraz ciągłej archiwizacji dziennika. To realna robota do zaplanowania, za to pozwala cofnąć się do stanu sprzed omyłkowego usunięcia danych.
Podobnie z wdrożeniem. SQLite nie ma żadnej usługi do uruchomienia ani portu do otwarcia, bo silnik siedzi w bibliotece razem z aplikacją. PostgreSQL to osobny proces, który trzeba uruchomić, zabezpieczyć, monitorować i aktualizować.
Dla zespołu bez administratora ta różnica bywa ważniejsza od wszystkich funkcji razem wziętych. Alternatywą jest baza zarządzana w chmurze, która zdejmuje obsługę, ale dokłada rachunek co miesiąc.
Kiedy SQLite jest lepszym wyborem niż PostgreSQL
Odwrotna strona tego porównania jest równie konkretna i zwykle pomijana.
Aplikacja desktopowa albo mobilna, która trzyma dane u użytkownika. Tu serwer bazodanowy nie ma czego robić, a SQLite jest wbudowany w telefony i w bibliotekę standardową Pythona.
Narzędzie wewnętrzne dla kilkunastu osób, z ruchem odczytowym i rzadkimi zapisami. Dokładasz wtedy do utrzymania jeden plik zamiast usługi z kopiami zapasowymi, poprawkami i monitoringiem.
Serwis z treścią, w którym zapisuje wyłącznie redakcja. Czytelnicy tylko czytają, a to SQLite obsługuje wprost znakomicie.
Środowisko testowe i lokalne. Uruchomienie testów na bazie w pamięci trwa ułamek tego, co postawienie kontenera z serwerem.
Format pliku dla własnego programu. Producent opisuje to jako jedno z głównych zastosowań, bo baza w pliku zastępuje własny format zapisu.
Pierwsza Misja AI · Kodożercy
Pierwszy raz z AI? Zaczynasz od zera.
Pierwsza Misja AI to kurs dla osób bez technicznego przygotowania. Nie musisz pisać kodu ani znać żargonu. Dowiesz się, jak działa AI, jak promptować i jak korzystać z niej w pracy.
Wejdź na pokład →
Cztery sygnały, że pora na PostgreSQL
Zamiast zgadywać, obserwuj konkretne objawy. Każdy z nich mówi coś innego.
Pierwszy: w dziennikach pojawia się błąd o zajętej bazie. To najczystszy sygnał, że zapisy zaczęły się o siebie potykać.
Drugi: chcesz postawić drugi serwer aplikacji albo przenieść usługę na kilka maszyn. Plik nie da się współdzielić po sieci w sposób, któremu można ufać.
Trzeci: pojawia się potrzeba nadania różnym osobom różnych uprawnień do danych. W SQLite ta rozmowa kończy się na uprawnieniach do pliku.
Czwarty: raporty na dużych tabelach zaczynają trwać minuty. PostgreSQL ma tu więcej możliwości, od zapytań równoległych po bogatsze indeksy.
Dopóki żaden z tych czterech sygnałów nie występuje, przenosiny są pracą bez zwrotu. Ta sama zasada, którą stosujemy przy wyborze platformy dla repozytorium kodu: zmieniaj narzędzie, gdy coś boli, a nie dlatego, że inne wygląda poważniej.
Przeprowadzka z SQLite na PostgreSQL
Dobra wiadomość: taka migracja bywa prostsza niż zmiana modelu danych. Obie bazy używają SQL-a, więc struktura tabel przenosi się w dużej części wprost. Automatyczna nie jest.
Zaskoczenia są trzy. Typy danych trzeba doprecyzować, bo PostgreSQL wymaga tego, czego SQLite nie wymagał. Daty przestają być tekstem i stają się osobnym typem. Klucze automatyczne zapisuje się inaczej.
Jeśli aplikacja korzysta z warstwy pośredniczącej w dostępie do bazy, większość tej roboty zdejmuje z ciebie biblioteka. Największą pozycją zwykle nie jest samo przeniesienie danych, tylko dopisanie tego, czego wcześniej nie było: kopii zapasowych, monitoringu i planu aktualizacji. Jeżeli zastanawiasz się przy okazji nad innym silnikiem serwerowym, warto zestawić PostgreSQL z MySQL, a gdy dane są nieregularne, także MongoDB z PostgreSQL.
Najczęstsze pytania
Ile użytkowników wytrzyma SQLite?
Producent podaje orientacyjnie sto tysięcy odsłon dziennie i nazywa to szacunkiem ostrożnym. Liczba użytkowników jest jednak gorszą miarą niż profil ruchu. Tysiąc osób czytających artykuły to dla tej bazy spokojny dzień, a garść równoczesnych zapisów potrafi być większym problemem. Wynik zależy od długości transakcji, nośnika i ustawionego limitu oczekiwania na blokadę. Licz równoczesne zapisy, nie odwiedziny.
Czy SQLite nadaje się na produkcję?
Tak i działa tak w milionach urządzeń. Producent opisuje SQLite jako najczęściej używany silnik bazodanowy na świecie, wbudowany we wszystkie telefony i większość komputerów. Pytanie brzmi raczej, czy pasuje do twojego profilu zapisów i czy aplikacja stoi na jednej maszynie.
Czy tryb WAL rozwiązuje problem współbieżności?
Rozwiązuje jego większą część, bo po włączeniu WAL czytający i piszący nie blokują się nawzajem. Ograniczenie jednego piszącego naraz zostaje, ponieważ plik dziennika jest jeden. Dochodzą też koszty: dodatkowe pliki obok bazy, konieczność pilnowania punktów kontrolnych oraz brak obsługi na sieciowym systemie plików.
Czy PostgreSQL ma sens w małym projekcie?
Ma, jeśli projekt od początku jest wielodostępny i ma rosnąć. Wtedy taniej wychodzi postawić serwer od razu, niż przenosić dane w trakcie. Przy narzędziu dla kilkunastu osób albo aplikacji lokalnej dokładasz sobie jednak usługę do utrzymania i nic w zamian nie dostajesz.
Podsumowanie
Pytanie o SQLite i PostgreSQL rozstrzyga profil zapisów, a nie wielkość projektu ani powaga narzędzia. SQLite obsługuje nieograniczoną liczbę czytających i jednego piszącego w danej chwili, więc świetnie nadaje się do aplikacji lokalnych, narzędzi wewnętrznych, serwisów z treścią i środowisk testowych. PostgreSQL wchodzi wtedy, gdy zapisów jest dużo i idą równolegle, gdy aplikacja ma stać na kilku serwerach, gdy potrzebujesz uprawnień na poziomie danych albo ciężkich raportów. Sam producent SQLite podaje ostrożny próg stu tysięcy odsłon dziennie i wprost odsyła do bazy z serwerem przy serwisach intensywnie zapisujących. Zanim zaczniesz przenosiny, sprawdź, czy występuje którykolwiek z tych sygnałów: kolizje zapisów w dziennikach, potrzeba uruchomienia kilku serwerów, bardziej szczegółowe uprawnienia albo raporty, z którymi SQLite sobie nie radzi.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
