Cmssy vs Sanity: edycja pól kontra składanie stron
Oba są code-first i oba mają wizualną edycję. Prawdziwe pytania to co Twoi redaktorzy robią całymi dniami i czy płacisz za każde miejsce.
Trzy argumenty, które tutaj nie działają
Sanity to poważny produkt, szanowany przez deweloperów, i większość typowych kątów porównania odbija się od niego bez skutku. Odpuśćmy je od razu.
Sanity jest code-first. Schematy to TypeScript w Twoim repo, a samo Studio konfiguruje się w kodzie i wdraża z Twojego projektu. Tak jest od lat - to prawdopodobnie stąd wzięła się ta idea. Zdanie "my definiujemy schematy w kodzie, a oni nie" po prostu nam nie przysługuje.
Sanity ma wizualną edycję. Narzędzie Presentation łączy Studio z Twoim żywym frontendem przez content source maps i kodowanie stega, więc redaktor klika element na prawdziwej stronie i go edytuje. Działa z Next.js, Remixem, Nuxtem i Astro.
Sanity nie limituje języków. Locale są nielimitowane od planu darmowego w górę, ograniczone tylko limitami atrybutów. Jeśli przyszedłeś tu z nadzieją, że pobijemy ich cenowo na wielojęzyczności - nie pobijemy. Ten argument działa przeciw Storyblokowi i Contentfulowi, nie przeciw Sanity.
Zostaje różnica realna: w kształcie produktu i w sposób naliczania.
Prawdziwa różnica: co robią redaktorzy
Sanity stawia na structured content. Model myślowy to dokumenty i pola. Redaktor otwiera dokument w Studio, wypełnia pola, a frontend decyduje, jak je wyrenderować. Presentation czyni tę pętlę wizualną - klikasz element, edytujesz pole na miejscu - ale jednostką pracy nadal jest pole. Zbudowanie strony to zadanie dewelopera, w kodzie.
Cmssy stawia na składanie stron. Jednostką pracy jest blok. Redaktor otwiera stronę w edytorze, przeciąga sekcję z opiniami nad sekcję z cennikiem, poprawia tekst na żywej stronie i publikuje. Nikt nie dotyka repo. Same bloki to nadal React należący do dewelopera, z typowanym schematem - ale składanie ich w stronę to robota redaktora, nie deploy.
Całe porównanie w jednym zdaniu: Sanity daje redaktorom lepsze pola, Cmssy daje redaktorom stronę.
Które podejście jest słuszne, zależy od tego, co Twój zespół faktycznie robi. Jeśli Twoja treść to katalog produktów, zestaw dokumentacji albo archiwum artykułów zasilające kilka powierzchni, structured content jest właściwym modelem, a Sanity jest w tym świetne. Jeśli Twój zespół marketingu chce budować i przestawiać landingi jeszcze dziś po południu, edytor pól nie jest tym, o co prosi.
Cennik
To druga oś i gryzie w konkretnym punkcie.
Sanity: Free za $0 (do 20 miejsc, 2 datasety, 250K żądań API i 1M żądań CDN miesięcznie), Growth za $15 za miejsce miesięcznie (do 50 miejsc, komentarze i zadania, prywatne datasety), Enterprise na zapytanie. Dodatkowe datasety na Growth kosztują $999 za dataset miesięcznie. SSO, własne role, content releases i ścieżka audytu są tylko w Enterprise.
Cmssy: Hobby darmowy (1 workspace, 5 stron, 3 własne bloki), Pro za $19/msc stałe (5 workspace'ów, nielimitowane strony, 25 własnych bloków, AI i MCP), Enterprise na zapytanie.
Per seat kontra stała opłata - to trzeba policzyć. Jeden redaktor na Sanity Growth to $15, my $19 - przegrywamy. Pięciu redaktorów to $75 przeciw naszym $19. Dwunastu to $180 przeciw naszym $19. Próg opłacalności przekracza się niemal natychmiast i to dokładnie w momencie, w którym CMS zaczyna być użyteczny, czyli gdy dotyka go więcej niż jedna osoba.
O $999 za dodatkowy dataset warto wiedzieć, zanim oprzesz architekturę na datasetach - jeśli Twoim odruchem jest jeden dataset na markę albo na środowisko, wycenić to trzeba najpierw.
Dane Sanity sprawdzone 27 lipca 2026 - zweryfikuj przed decyzją.
Gdzie ich darmowy plan bije nasz
Wprost: darmowy plan Sanity jest znacznie hojniejszy od naszego. Dwadzieścia miejsc, dwa datasety, realny limit API. Nasz plan Hobby to jeden workspace, pięć stron i trzy własne bloki - to wersja próbna, nie dom. Jeśli Twój projekt jest mały, bez finansowania i taki pozostanie, darmowy plan Sanity jest lepszym układem i nie będziemy udawać inaczej.
Odpytywanie danych
Sanity używa GROQ, własnego języka zapytań. Jest naprawdę mocny - projekcje, złączenia i filtrowanie, które w GraphQL byłyby niezgrabne - i to realny powód, dla którego deweloperzy zostają. Kosztem jest kolejny język do nauczenia się przez zespół, w dodatku specyficzny dla Sanity.
Cmssy to GraphQL w każdym planie, z codegenem produkującym typowane dokumenty. Mniej ekspresyjny niż GROQ w skrajnych przypadkach, ale nie ma się czego uczyć, a narzędzia już istnieją.
Werdykt: realny kompromis, nie wygrana. Weź GROQ, jeśli odpytujesz głęboko; weź GraphQL, jeśli wolisz nie wprowadzać nowego języka.
AI
Cmssy wystawia workspace przez serwer MCP, więc agent taki jak Claude tworzy strony, pisze teksty, uzupełnia tłumaczenia i ustawia SEO przez to samo API, którego używa edytor - na treści, nigdy na Twoim kodzie. Ponieważ jednostką Cmssy jest strona, agentowi można powiedzieć "dodaj stronę cennika z trzema planami" i on faktycznie ją wyprodukuje. To polecenie nie ma czystego odpowiednika w modelu pól i dokumentów, gdzie struktura strony żyje w repo.
Zwycięzca: Cmssy - i zauważ, że ta przewaga wynika z modelu składania stron, a nie jest osobną funkcją.
Gdzie wygrywa Sanity
- Personalizacja Studio - Studio to Twoja aplikacja React. Własne komponenty pól, structure builder, szyte na miarę workflowy. Nasz edytor jest znacznie bardziej narzucający.
- Współpraca w czasie rzeczywistym - wielu redaktorów w jednym dokumencie naraz, z obecnością. Dojrzałe i dobrze zbudowane.
- GROQ i Portable Text - dwa naprawdę dobre kawałki projektowania, zwłaszcza Portable Text dla bogatej treści, która musi renderować się poza webem.
- Darmowy plan - dwadzieścia miejsc, jak wyżej.
- Dojrzałość i społeczność - lata użycia produkcyjnego, duży ekosystem wtyczek, głęboka dokumentacja.
- Szerokość frameworków - wizualna edycja w Next.js, Remiksie, Nuxcie i Astro. My skupiamy się na React i Next.js.
- Omnichannel - jeśli treść zasila aplikacje i inne powierzchnie, structured content jest właściwym modelem, a składanie stron niewłaściwym.
Porównanie
| Cecha | Cmssy | Sanity |
|---|---|---|
| Schemat w kodzie | Tak | Tak |
| Wizualna edycja | Tak, składanie bloków | Tak, pola w miejscu |
| Redaktorzy budują strony | Tak, przeciągnij i upuść | Nie, robią to deweloperzy |
| Limit locale | Nie | Nie |
| Model cenowy | Stały, $19/msc | Per seat, $15/miejsce/msc |
| Koszt przy 5 redaktorach | $19/msc | $75/msc |
| Plan darmowy | 1 workspace, 5 stron | 20 miejsc, 2 datasety |
| Język zapytań | GraphQL | GROQ (+ GraphQL) |
| AI przez MCP | Pro ($19/msc) | Brak odpowiednika |
| Współpraca na żywo | Nie | Tak |
| Personalizacja edytora | Narzucający | W pełni konfigurowalny |
| Wdrażasz i hostujesz sam | Tak | Tak |
Werdykt
Wybierz Sanity, jeśli Twoja treść to dane strukturalne obsługujące kilka powierzchni, jeśli chcesz sam kształtować narzędzie autorskie, jeśli pociąga Cię GROQ i Portable Text albo jeśli jesteś na tyle mały, że dwadzieścia darmowych miejsc przesądza sprawę.
Wybierz Cmssy, jeśli robotą są strony WWW, a wykonują ją marketerzy, którzy chcą budować strony bez dewelopera, jeśli masz więcej niż dwóch czy trzech redaktorów i naliczanie per seat zaraz zaboli, albo jeśli chcesz agenta AI, który potrafi stworzyć całą stronę, a nie wypełnić pole.
Uczciwe podsumowanie w jednym zdaniu: Sanity to lepszy backend treści, Cmssy to lepszy CMS do stron. One tak naprawdę nie konkurują o to samo popołudnie.
Następne kroki
- Postępuj wg przewodnika instalacji, aby wpiąć
@cmssy/reacti@cmssy/nextw aplikację Next.js - Zobacz, jak definiuje się bloki w kodzie
- Przeczytaj o serwerze MCP
- Porównaj Cmssy i Contentful albo Cmssy i Storyblok