Porównanie CMS

Cmssy vs Sanity

Oba definiują schematy w kodzie, oba mają wizualną edycję i żaden nie limituje języków. Różni je model edycji - pola w miejscu kontra strony składane z bloków - oraz rachunek per seat kontra stały.

Z
Zespół Cmssy
9 min read

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

CechaCmssySanity
Schemat w kodzieTakTak
Wizualna edycjaTak, składanie blokówTak, pola w miejscu
Redaktorzy budują stronyTak, przeciągnij i upuśćNie, robią to deweloperzy
Limit localeNieNie
Model cenowyStały, $19/mscPer seat, $15/miejsce/msc
Koszt przy 5 redaktorach$19/msc$75/msc
Plan darmowy1 workspace, 5 stron20 miejsc, 2 datasety
Język zapytańGraphQLGROQ (+ GraphQL)
AI przez MCPPro ($19/msc)Brak odpowiednika
Współpraca na żywoNieTak
Personalizacja edytoraNarzucającyW pełni konfigurowalny
Wdrażasz i hostujesz samTakTak

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