W tym artykule szczegółowo opisano, co faktycznie obejmuje PostgREST, co pozostawia Tobie, i porównuje poważne alternatywy — aż do tego, co Aurabase faktycznie obejmuje wewnętrznie, co jest weryfikowane w kodzie, a nie zakładane.
Najważniejsze
- PostgREST generuje interfejs API REST na podstawie schematu Postgres: filtry, osadzanie relacji, wywołania RPC, RLS oparte na JWT, specyfikacja OpenAPI — bez linii kodu zaplecza.
- Czego nie robi natywnie: emituje JWT, przechowuje pliki, wypycha w czasie rzeczywistym lub udostępnia moduł puli połączeń ze zintegrowanym przełączaniem ról.
- W Aurabase projekt silnika Postgres działa na prawdziwej dedykowanej instancji PostgREST v12.2.8 — a nie na ponownej implementacji. Projekt silnika MongoDB przechodzi przez warstwę REST specyficzną dla Aurabase, inspirowaną tymi samymi konwencjami, ale z różnymi ograniczeniami.
- Alternatywy obejmują hostowany samodzielnie PostgREST (wszystko, co można wokół niego złożyć) po kompletny backend (Supabase, Aurabase) za pośrednictwem interfejsów API GraphQL, takich jak Hasura lub PostGraphile.
Czym dokładnie jest PostgREST?
PostgREST to autonomiczny serwer WWW, który przekształca istniejącą bazę danych PostgreSQL w API REST, bezpośrednio z jej schematu. Brak warstwy aplikacji do pisania: tabele, widoki i funkcje stają się trasami, a uprawnienia SQL — role, zasady RLS — stają się warstwą autoryzacji.
Konkretnie PostgREST obejmuje pięć możliwości, które pojawiają się w prawie wszystkich ocenach:
- Filtrowanie poziome — około trzydziestu operatorów (
eq,gt,like,ilike,in,is,cs,ov,fts...) bezpośrednio w ciągu zapytania. - Filtrowanie i osadzanie w pionie —
?select=projektuje kolumny i osadza relacje poprzez klucz obcy, na przykładcustomer:customers(email). - RPC —
POST /rpc/{fonction}bezpośrednio wywołuje funkcję SQL, która staje się punktem końcowym. - RLS sterowany przez JWT — PostgREST przełącza aktywną rolę Postgres zgodnie z otrzymanym tokenem (
SET LOCAL ROLE), więc Twoje zasady obowiązują bez zduplikowanej logiki autoryzacji po stronie aplikacji. - Samodzielnie wygenerowany interfejs OpenAPI — specyfikacja została wydedukowana z ujawnionego schematu, bez pliku, który należy konserwować ręcznie.
Pojedyncze żądanie HTTP filtruje opłacone zamówienia, osadza adres e-mail klienta za pomocą klucza obcego i sortuje według daty — bez konieczności ręcznego zapisywania pojedynczej trasy.
RPC kieruje się tą samą logiką: funkcja SQL już zapisana w bazie danych staje się punktem końcowym POST, a jej argumenty są przekazywane w formacie JSON.
Ta zasada — schemat Postgres jest jedynym źródłem prawdy w interfejsie API — sprawia, że PostgREST jest przewidywalny: każda zmiana zachowania przechodzi przez migrację SQL, a nie przez oddzielną warstwę aplikacji, która mogłaby wywodzić się z rzeczywistego schematu. Projekt jest projektem typu open source, opracowanym na GitHub, niezależnie od konkretnego dostawcy BaaS.
Czego PostgREST nie robi
PostgREST rozwiązuje warstwę CRUD. Nie rozwiązuje to reszty zaplecza aplikacji. W zespołach, które wdrażają je samodzielnie, systematycznie występują cztery niedociągnięcia.
- Uwierzytelnianie — brak wydawania JWT i zintegrowanego zarządzania użytkownikami. Musisz zbudować go w SQL lub oddelegować do usługi zewnętrznej.
- Przechowywanie plików — brak. Pozostaje oddzielne podłączenie łyżki S3 lub jej odpowiednika.
- Czas rzeczywisty — PostgREST odpowiada na jednorazowe żądania HTTP, nie wysyła żadnych zdarzeń.
- Pula połączeń — Sam PostgREST łączy się z Postgres, ale nie integruje żadnych zaawansowanych modułów puli. Na dużą skalę zarządzanie nim staje się samodzielną decyzją operacyjną: moduł puli w klasycznym trybie transakcji koliduje z mechanizmem przeładowywania schematu PostgREST (zobacz poniżej, jak Aurabase rozwiązuje ten kompromis).
Żadne z tych niedociągnięć nie jest wadą projektową: PostgREST wykonuje określone zadanie (schemat → REST API) dobrowolnie. To właśnie ten wąski obwód sprawia, że jego zachowanie jest przewidywalne.
Praktyczną konsekwencję należy jasno określić: bez uwierzytelnienia Twoje zasady RLS stają się jedyną granicą bezpieczeństwa pomiędzy anonimowym klientem a Twoimi danymi. Źle napisana polityka dotycząca roli anon nie jest wyprzedzana przez dodatkową warstwę aplikacji – takiej nie ma.
PostgREST w Aurabase: co jest naprawdę omówione
W projekcie silnika Aurabase Postgres — silnik domyślny — brama kieruje każde żądanie CRUD bezpośrednio do instancji PostgREST v12.2.8 dedykowanej dla tego projektu, dwóch replik, zlokalizowanych w klastrze Postgres dzierżawcy. Nie jest to przybliżona kompatybilność: jest to sam plik binarny PostgREST, z tymi samymi operatorami, tym samym osadzeniem, tym samym RPC, tym samym RLS sterowanym przez JWT.
W przypadku projektu silnika MongoDB sytuacja jest inna. MongoDB nie ma odpowiednika PostgREST: żądania te są kierowane do wewnętrznej usługi Aurabase, która ponownie implementuje podzbiór tych samych konwencji — identyczne nazwy operatorów, składnię ?select= z osadzaniem, nagłówki Prefer i Content-Range — ale w silniku dokumentów, a nie relacyjnym. Warstwa ta ma swoje własne ograniczenia: żądanie osadzania w reprezentacji zwróconej przez mutację jest jawnie odrzucane, a nie dyskretnie ignorowane, a także nie ma trasy RPC równoważnej funkcjom SQL.
Pełna kompatybilność z PostgREST — łącznie z RPC i RLS — jest faktem dotyczącym silnika Postgres, a nie gwarancją obejmującą wiele silników. Jeśli Twój projekt zależy od funkcji SQL udostępnianych w RPC, na dzień dzisiejszy jedyną opcją jest silnik Postgres.
Szczegóły techniczne kontrastują z intuicją: każda dedykowana instancja PostgREST pozostaje bezpośrednio połączona z podstawowym Postgresem, bez konieczności przechodzenia przez moduł puli PgBouncer wdrożony dla tego dzierżawcy. Zakładana przyczyna: tryb łączenia transakcji przerwałby przeładowywanie schematu PostgREST, które opiera się na LISTEN/NOTIFY — trwałym połączeniu, niekompatybilnym z pulą, która odnawia połączenie dla każdej transakcji.
Kolejny przydatny szczegół w produkcji: nieaktywny projekt można wstrzymać, aby zaoszczędzić zasoby. Pierwsze żądanie uśpionego projektu powoduje jego wybudzenie i otrzymuje 503 z opóźnieniem ponownej próby, czyli czasem, w którym dedykowana instancja PostgREST ma powrócić do działania — zakładany kompromis między kosztem a opóźnieniem w przypadku zimnej awarii, a nie ukryty incydent.
Jakie istnieją alternatywy dla PostgREST?
PostgREST ma jasne zastosowanie: schemat Postgres jest źródłem prawdy, a zespół chce uniknąć ręcznego pisania warstwy CRUD. Oprócz tego konkretnego przypadku istnieje kilka rodzin alternatyw, w zależności od tego, co chcesz dodać — od niczego (samodzielny hosting) po kompletny, gotowy do użycia backend.
Poniższa tabela porównuje, co każda opcja obejmuje natywnie, i co wyraźnie pozostawia Tobie – bez oceny architektury wybranej przez każdy projekt.
| Hostowany na własnym serwerze PostgREST | Samodzielnie wygenerowany interfejs API REST (filtry, osadzanie, RPC, RLS). | Uwierzytelnianie, przechowywanie, czas rzeczywisty, interfejs administratora — wszystko do połączenia. |
|---|---|---|
| Supabaza | Zintegrowany PostgREST + uwierzytelnianie (GoTrue), przechowywanie, czas rzeczywisty, funkcje brzegowe. | Heterogeniczny stos (Elixir/Go/TS/Node) montowany usługa po usłudze. |
| Hasura / PostGraphile | Automatycznie wygenerowany interfejs API GraphQL z Postgres. | Podejście GraphQL, a nie REST — dedykowane porównanie poniżej. |
| Directus | Interfejs administratora + ogólny interfejs API REST/GraphQL, wiele systemów DBMS. | Zaprojektowany do zarządzania danymi/CMS, a nie do kompletnego backendu aplikacji. |
| Ręcznie robiony framework (Express, FastAPI, Rails…) | Pełna kontrola na każdej drodze. | CRUD, walidacja, uwierzytelnianie, łączenie — wszystko pisane odręcznie. |
| Aurabaza | Prawdziwy PostgREST dedykowany dla projektu Postgres + uwierzytelnianie, pamięć masowa, funkcje czasu rzeczywistego, funkcje brzegowe i sztuczna inteligencja już zintegrowane. | W silniku MongoDB warstwa REST przebudowana przez Aurabase — a nie sam PostgREST. |
Punkt często niedoceniany przy wyborze opcji „samodzielnego hostowania”: Sam PostgREST pozostaje łatwy w obsłudze, ale operacje produkcyjne (aktualizacja wersji, wysoka dostępność, powiązanie z pulą, monitorowanie) pozostają całkowicie Twoją odpowiedzialnością - to właśnie ta praca operacyjna, a nie oprogramowanie, pochłania zarządzane platformy.
Aby uzyskać szczegółowe porównanie podejść GraphQL — pg_graphql, Hasura i PostGraphile — zobacz nasz artykuł poświęcony API GraphQL w Postgres.
Jak wybrać
Najczęściej pojawiają się cztery sytuacje. Właściwy wybór zależy głównie od tego, co chcesz samodzielnie złożyć i konserwować.
- Chcesz po prostu interfejsu API REST na istniejącym schemacie Postgres, nic więcej. Samoobsługowy PostgREST wystarczy: robi dokładnie to, co robi i nic więcej nie trzeba instalować.
- Potrzebujesz dodatkowej autoryzacji, przechowywania i pracy w czasie rzeczywistym i jesteś gotowy, aby skompilować kilka usług. Supabase, czyli PostgREST z własnym stosem aplikacji, spełnia tę potrzebę.
- Wolisz GraphQL od REST. Hasura lub PostGraphile zajmują się tym obszarem — inny wybór architektoniczny, a nie bezpośredni zamiennik PostgREST.
- Chcesz mieć kompletny backend Postgres bez łączenia wielu oddzielnych usług. To jest kąt, pod jakim dokumentuje nasza zunifikowana architektura Rust: prawdziwy PostgREST dla warstwy CRUD, natywnie otoczony funkcjami uwierzytelniania, przechowywania, czasu rzeczywistego i brzegowymi.