Yeah! The other big difference with Sanity is that the API side of Sanity is 3rd-party. So you never truly have control over the API logic or backend side at all. Whereas with Payload, you control both the admin UI AND the entirety of your API. That's what I mean by "closing the gap" between an app framework and a headless CMS. Lots more backend potential with Payload.
Knut from Sanity.io here. First of all, congrats on the launch and what seems to be a well done product!
And to be a bit nit-picky and to clarify our world-view: The API side of Sanity isn't 3rd-party (it's native to the platform), but it is hosted and propertary.
There are always trade-offs, so no, you don't get the kind of control you get when you host your own Express-server or sit on your own MongoDB instance, but then again, you don't have to do those things to have a scalable real-time document store that supports deeply nested document structures with queryable references (with referential integrity). We build our APIs specifically to improve developer experience where we take care of the hard parts™ so that you can focus on the productive things. All of our HTTP APIs are versioned, because we specifically want to avoid breaking changes as much as possible.
Furthermore, there are other things that you just get. Like GROQ which is way more expressive and flexible for querying data compared to GraphQL (which we also offer). You get on-demand image transforms. You get both content and assets behind a CDN. You have a mutation/patch API that can do transactions with pretty specific operations (“change only this value in an nested array for this key if it matches this value”). Since the backand has full attributed revision history, you can also have controls that prevents race conditions, so that you can programatically update documents even if people are editing them. You can define triggers for webhooks and its payload with GROQ, so you can use serverless functions (or a server) to update content based on conditions. You can hit the export API endpoint and get all of your stuff over a stream wherever you want it. And so on and so forth.
Of course, there are always use cases where you want a solution that can be run fully on-prem or specific bespoke behavior in the database/API-layer beyond the capabilities in the platform. If you need those things, then you should probably look elsewhere than Sanity.io, and Payload might be an excellent choice.
Not yet. When we built the site, Payload's licensing and business model was built around a SaaS model, and was all baked into Payload's frontend. Of course, it does use Payload on the backend (including the entirety of our old SaaS billing infra) but for those reasons, we did not open-source it.
However, v2 is coming and that will 100% be open-source!
