Payload CMS czy Sanity: który headless CMS wybrać?

Najprostszy opis brzmi: Payload jest otwartym backendem opartym na Next.js, który wdrażasz we własnej infrastrukturze, a Sanity jest platformą SaaS z zarządzanym Content Lake. To dobry początek, lecz zbyt mało do decyzji architektonicznej.

Payload daje panel, REST, GraphQL, Local API, uwierzytelnianie, kontrolę dostępu, pliki i preview w jednym repozytorium TypeScript. Sanity rozdziela Studio, które możesz dostosować i hostować, od zarządzanej usługi przechowującej treść. Frontendy pytają Content Lake przez GROQ, GraphQL lub biblioteki klienckie.

Wybierasz model odpowiedzialności systemu. Funkcje można często odtworzyć po obu stronach, ale koszt ich utrzymania spada na inny zespół.

Payload po przejęciu przez Figmę

Payload dołączył do Figmy w czerwcu 2025 roku i pozostaje projektem open source. W sierpniu 2026 roku ma to jeden praktyczny skutek, którego nie wolno pominąć w nowej architekturze: wdrażanie nowych projektów do Payload Cloud jest wstrzymane. Istniejące instancje nadal działają, lecz oficjalny komunikat zapowiada ich późniejszą migrację do rozwiązania, które dopiero powstaje.

Nowy projekt Payload trzeba więc liczyć jako self-hosting na platformie potrafiącej uruchomić Next.js. Może to być kontener, serwer Node albo wspierana platforma serverless. Sama aplikacja nie zamyka infrastruktury. Produkcja zwykle potrzebuje jeszcze bazy, trwałego storage dla uploadów, dostawcy e-mail, CDN-u, sekretów, logów i backupów.

Koszt Payload i Sanity: abonament to tylko jedna linia

Sanity ma limity planu i zużycia

Według cennika sprawdzonego 1 sierpnia 2026 roku plan Free obejmuje między innymi 20 miejsc, 2 publiczne datasety, 10 tysięcy dokumentów, milion żądań API CDN, 250 tysięcy zwykłych żądań API, 100 GB assetów i 100 GB transferu miesięcznie. Growth kosztuje od 15 USD za miejsce miesięcznie oraz umożliwia płatne zwiększanie części limitów.

Te liczby są pomocne przy estymacji, ale nie powinny być kopiowane do umowy bez ponownej kontroli cennika. W planie Free przekroczenie limitu żądań, CDN lub transferu nie tworzy rachunku za nadwyżkę. Usługa blokuje odpowiednią funkcję do resetu okresu albo przejścia na wyższy plan. Plan Growth rozlicza wybrane nadwyżki, natomiast limit dokumentów wymaga dodatku lub zmiany planu.

Dokument także zużywa limit. Drafty i dokumenty systemowe mogą wpływać na licznik, więc liczba publicznych podstron nie jest wystarczającą podstawą prognozy. Osobno policz ruch przez CDN, niecachowane zapytania API, transfer obrazów, miejsca zespołu i wymagane dodatki.

Payload nie ma zerowego kosztu

Licencja MIT pozwala używać i modyfikować rdzeń bez opłat licencyjnych. Koszt rośnie jednak wraz z infrastrukturą i wymaganą niezawodnością:

• instancje aplikacji Next.js i ich autoskalowanie,
• PostgreSQL, MongoDB albo SQLite wraz z migracjami i kopiami,
• obiektowy storage plików, transformacje obrazów i CDN,
• e-mail transakcyjny oraz kolejki zadań,
• logi, metryki, alerty i śledzenie błędów,
• aktualizacje bezpieczeństwa oraz dyżur po awarii,
• środowiska testowe i odtwarzanie backupu.

Mały serwis może działać tanio. Duży ruch nie pozostaje bezpłatny i nie daje automatycznie stałego rachunku, ponieważ płacisz dostawcom infrastruktury za zasoby. Payload zamienia abonament w operacje, a ich opłacalność zależy od kompetencji zespołu oraz skali.

Dane, RODO i granica kontroli

Payload obsługuje oficjalne adaptery dla MongoDB, PostgreSQL oraz SQLite. Wybierasz operatora, region, szyfrowanie, politykę backupów i retencję. To pomaga przy wymaganiach lokalizacyjnych albo integracji z bazą aplikacji, ale firma staje się odpowiedzialna za poprawną konfigurację oraz reakcję na incydenty.

Sanity przechowuje dokumenty w Content Lake. Plan Free pozwala używać wyłącznie publicznych datasetów. Publiczny dataset można odpytywać bez tokenu, więc nie nadaje się do prywatnych profili, zamówień ani wewnętrznych materiałów. Dataset prywatny jest funkcją płatną. Dokumentacja zaznacza również, że pliki assetów nie stają się prywatne razem z prywatnym datasetem.

RODO nie sprowadza się do mapy serwerowni. Przed wyborem sprawdź:

• role administratora, procesora i podprocesorów,
• umowę powierzenia oraz warunki transferu danych,
• regiony przechowywania, przetwarzania, backupów i logów,
• usuwanie danych, retencję wersji i realizację praw osoby,
• szyfrowanie, SSO, MFA, historię audytową i reakcję na incydenty,
• rodzaj danych, które w ogóle powinny znaleźć się w CMS-ie.

Self-hosting daje kontrolę, nie zgodność. SaaS odbiera część decyzji infrastrukturalnych, lecz może zapewnić procesy trudne do zbudowania małemu zespołowi. Ostateczna ocena zależy od konkretnego wdrożenia i umów.

Schemat treści i TypeScript

Payload generuje typy z konfiguracji

W Payload konfiguracja kolekcji jest wykonywalnym kodem TypeScript. Z niej powstaje panel, API i plik typów. Hooki, walidacja oraz dostęp mogą korzystać z kontekstu żądania.

// collections/Posts.ts
import type { CollectionConfig } from 'payload'
 
export const Posts: CollectionConfig = {
  slug: 'posts',
  access: {
    read: ({ req }) => Boolean(req.user),
  },
  versions: {
    drafts: { autosave: true },
    maxPerDoc: 50,
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'content', type: 'richText', required: true },
  ],
}

Komenda payload generate:types tworzy interfejsy z konfiguracji. Przy PostgreSQL i SQLite zmiany schematu wymagają też kontrolowanego procesu migracji bazy. Automatyczne dopasowanie w development nie zastępuje migracji sprawdzonej na kopii produkcyjnych danych.

Payload ma jeszcze Local API, które w projekcie Next.js omija sieciowy roundtrip i pracuje bezpośrednio z backendem. Tutaj kryje się pułapka bezpieczeństwa: operacje Local API domyślnie omijają Access Control. Jeśli przekazujesz użytkownika i oczekujesz sprawdzenia reguł, jawnie ustaw overrideAccess: false.

const posts = await payload.find({
  collection: 'posts',
  user: currentUser,
  overrideAccess: false,
  draft: false,
})

Bezpośredni dostęp zwiększa siłę błędu. Reguły kolekcji, pola i scenariusze administracyjne trzeba pokryć testami autoryzacji.

Sanity generuje typy ze schematu i GROQ

Sanity Studio również definiuje schemat w TypeScript. Portable Text zapisuje treść blokową jako dane strukturalne, dzięki czemu frontend nie musi przyjmować dużego fragmentu HTML-u.

// schemaTypes/postType.ts
import { defineField, defineType } from 'sanity'
 
export const postType = defineType({
  name: 'post',
  type: 'document',
  title: 'Wpis',
  fields: [
    defineField({
      name: 'title',
      type: 'string',
      validation: (r) => r.required(),
    }),
    defineField({ name: 'slug', type: 'slug', options: { source: 'title' } }),
    defineField({ name: 'body', type: 'array', of: [{ type: 'block' }] }),
  ],
})

Sanity TypeGen osiągnęło status GA w 2026 roku. Narzędzie generuje typy ze schematu Studio oraz z rezultatów zapytań GROQ oznaczonych przez defineQuery. Stare porównanie, w którym Payload ma typy end-to-end, a Sanity wyłącznie luźną konfigurację JS, jest już nieaktualne.

Różnica nadal istnieje. Payload odwzorowuje własny model backendu i może współdzielić typy w jednej aplikacji. Sanity TypeGen analizuje projekcję zapytania, co dobrze pasuje do frontendów pobierających różne kształty tego samego dokumentu. Oba podejścia wymagają automatyzacji CI, aby zmiana schematu nie ominęła generowania typów i testów.

API, zapytania i wydajność

Payload udostępnia REST, GraphQL i Local API. Gdy CMS oraz frontend działają w tej samej aplikacji Next.js, Local API ogranicza liczbę usług w ścieżce żądania. Oddzielny frontend korzysta z sieciowego API i musi uwzględnić cache, limity głębokości relacji oraz ochronę przed kosztownymi zapytaniami GraphQL.

Sanity opiera typowy frontend na GROQ i API CDN. Projekcja pozwala pobrać tylko potrzebne pola oraz rozwiązać referencje. Dla treści zmieniającej się często dostępny jest Live Content API, który subskrybuje aktualizacje. Nadal trzeba świadomie rozdzielić zapytania cachowane od świeżych, aby nie zużywać niepotrzebnie limitu zwykłego API.

Żaden CMS nie naprawi automatycznie złego wzorca pobierania. N+1, ogromna głębokość relacji, zapytanie wykonywane dla każdego komponentu i brak cache potrafią zniszczyć koszt oraz TTFB po obu stronach.

Workflow redakcyjny: Sanity kontra Payload

Sanity Studio oferuje edycję w czasie rzeczywistym, obecność współpracowników, Live Preview i Visual Editing. Content Source Maps łączą element podglądu z polem w Studio, dzięki czemu redaktor może przejść z komponentu strony do właściwego miejsca edycji. Komentarze, zadania, zaplanowane drafty oraz bardziej rozbudowane role zależą od planu.

Payload ma wersje dokumentu, różnice wersji, przywracanie, drafty, autosave oraz Live Preview oparte na iframe i komunikacji postMessage. Panel powstaje z konfiguracji i można go rozszerzać komponentami React. Funkcje wieloosobowej edycji i zaawansowanych workflow mogą należeć do oferty enterprise, więc trzeba sprawdzić zakres konkretnej umowy.

Nie ogłaszaj zwycięzcy na podstawie demonstracji. Przygotuj dla redaktorów te same zadania:

1. Utworzenie strony z SEO, obrazem i blokiem niestandardowym.
2. Równoczesna poprawka dwóch osób w tym samym dokumencie.
3. Podgląd draftu w kilku rozmiarach ekranu.
4. Zaplanowanie publikacji i wycofanie zmiany.
5. Odtworzenie poprzedniej wersji po błędzie.
6. Tłumaczenie treści z kontrolą brakujących pól.

Minuty i błędy rozstrzygają lepiej niż liczba funkcji na stronie produktu.

Lokalizacja, wersje i wiele serwisów

Payload lokalizuje wybrane pola w jednym dokumencie i pozwala definiować fallbacki. Oficjalny plugin multi-tenant dodaje tenant do kolekcji i filtruje panel. To elastyczne narzędzia, ale izolacja tenantów zależy od poprawnych reguł dostępu i filtrów. Test przekrojowy musi udowodnić, że użytkownik jednej organizacji nie zobaczy danych drugiej.

Sanity pozwala modelować języki jako pola lub osobne dokumenty. Datasets mogą oddzielać środowiska albo zbiory danych, lecz zapytania GROQ i GraphQL nie łączą dokumentów między datasetami. Plan Free oraz Growth zawierają po dwa datasety, a dodatkowe środowiska mogą wymagać innego planu lub dodatku.

W dużym projekcie sprawdź jeszcze granularność ról, workflow akceptacji, liczbę marek, możliwość współdzielenia treści oraz sposób wersjonowania tłumaczeń. Sam przełącznik języka w panelu nie rozwiązuje procesu lokalizacyjnego.

Backup, awaria i odtwarzanie

Przy Payload zespół definiuje RPO i RTO, czyli dopuszczalną utratę danych oraz czas odtworzenia. Backup bazy bez plików jest niepełny, a kopia bez regularnego testu restore pozostaje założeniem. Trzeba zsynchronizować wersje aplikacji, migracje, bazę i storage.

W Sanity infrastruktura Content Lake jest zarządzana, ale aplikacja nadal zależy od zewnętrznej usługi. Potrzebujesz eksportu danych, monitoringu błędów API i decyzji, czy frontend podczas awarii poda cache. Historia dokumentu nie jest tym samym co niezależna kopia umożliwiająca migrację do innego systemu.

Backup bez procedury odtworzenia nie działa. W obu wariantach wykonaj próbę wyjścia: wyeksportuj treść, pliki i referencje, a potem odtwórz reprezentatywną stronę poza głównym środowiskiem.

Vendor lock-in i koszt późniejszej migracji

Własna baza Payload ułatwia dostęp do surowych danych. Nie oznacza to, że inne narzędzie zrozumie kolekcje, relacje, wersje i format rich text bez transformacji. Bezpośrednie zapytania do tabel z pominięciem API mogą też związać dodatkowy kod z wewnętrznym schematem CMS-a.

Sanity udostępnia eksport dokumentów i assetów, lecz aplikacja korzystająca intensywnie z GROQ, Portable Text, stega encoding oraz Presentation Tool będzie wymagała nowej warstwy po migracji. Lock-in mierzy się liczbą kontraktów do przepisania, nie tym, czy istnieje przycisk eksportu.

Przed wyborem przygotuj mały skrypt eksportu do neutralnego JSON-u i zapisz mapowanie assetów. Plan wyjścia powstaje przed wejściem.

Tabela porównawcza Payload CMS i Sanity

Matryca decyzji

• Wybierz Payload dla wspólnego backendu, gdy CMS ma obsługiwać treść i logikę aplikacji, a zespół zna Next.js, bazę oraz produkcyjne operacje.

• Wybierz Payload dla własnej infrastruktury, gdy umowy wymagają wskazanego operatora i regionu, a organizacja przejmie obowiązki bezpieczeństwa.

• Wybierz Sanity dla intensywnej współpracy, gdy wielu redaktorów pracuje równolegle i potrzebuje dojrzałego podglądu wizualnego.

• Wybierz Sanity dla wielu kanałów, gdy ten sam model treści zasila kilka frontendów, a zarządzane API ogranicza obciążenie zespołu platformowego.

• Nie wybieraj darmowego Sanity, jeśli treść musi pozostać prywatna albo zatrzymanie usługi po dojściu do limitu jest niedopuszczalne.

• Nie wybieraj Payload bez właściciela, który odpowie za aktualizacje, backupy, monitoring, pojemność i incydenty.

Proof of Concept przed wyborem CMS-a

Zbuduj w obu systemach jeden pionowy wycinek, a nie dwa efektowne dema. Powinien obejmować ten sam schemat, jeden blok złożony, obraz, relację, lokalizację, role, draft, preview, publikację, webhook, frontend i eksport.

Mierz:

• czas dewelopera od schematu do typowanego widoku,
• czas redaktora od pustego dokumentu do publikacji,
• liczbę ręcznych kroków i błędów,
• zachowanie po zmianie pola oraz cofnięciu wersji,
• TTFB i liczbę requestów przy zimnym oraz ciepłym cache,
• koszt dla obecnego ruchu, potrójnego ruchu i większego zespołu,
• czas odtworzenia danych po kontrolowanej awarii.

Decyzję zapisz jako dokument architektoniczny z założeniami. Gdy zmieni się liczba redaktorów, ruch albo wymagania prawne, będzie wiadomo, czy pierwotne uzasadnienie nadal działa.