Sanity vs Payload: 6 Costly Regrets Teams Always Face

Nobody writes a blog post when their CMS choice works out. The signal lives in GitHub issues filed at 2am, Reddit threads that start with "am I doing it wrong or is it really this bad?", and migration discussions where someone says "just threw away weeks of work." I've been reading those threads obsessively while auditing Sanity and Payload CMS for a research project, and clear patterns emerge. Teams don't regret choosing the wrong CMS — they regret the specific thing they didn't evaluate before committing.

This article is a taxonomy of CMS regrets, organized by what surprised teams after they'd already invested weeks or months into a platform. Every example comes from real GitHub issues, community discussions, and documented behavior. If you're still evaluating your options, this is the checklist of questions you should be asking before you write your first schema.

Regret 1: "I didn't realize the editor would feel this slow"

This is the most common regret across both platforms, and it catches teams off guard because CMS demos always use small, clean datasets.

On Sanity, the pattern looks like this: you build your schema, create a few test documents, and everything feels snappy. Then your editorial team starts working for real. They create documents with 50+ fields, arrays with hundreds of references, and deeply nested Portable Text blocks with custom components. Suddenly every keystroke has a 300-500ms delay. The Studio feels laggy. Characters get dropped during fast typing. Editors start complaining, and you realize the performance characteristics of the Studio are schema-complexity dependent in ways that weren't obvious during your proof of concept.

This isn't speculation. GitHub issue #7456 reports "every keystroke is slow and laggy" with performance concerns tied to cloud sync. Issue #5226 describes similar input lag and was closed as "not planned." Issue #2445 documents arrays with 900+ references slowing the UI to a halt, with requests for pagination or virtualization. Issue #3185 reports the Studio lagging and cutting characters during autosave in nested Portable Text structures. These span years of reports, and while Sanity has improved Studio performance over time, the fundamental pattern persists for complex schemas.

On Payload, the regret takes a different form. The admin panel itself is generally responsive, but the development server can become painful. One detailed report describes a multi-tenant project with 25 blocks and 20 collections hitting 10-60 second load times during development, with roughly 13GB of RAM usage at startup. Another cluster of reports ties performance degradation to specific Next.js versions — maintainers identified regressions starting around Next.js 15.5 and have been tracking fixes.

The lesson: your CMS proof of concept needs to be realistic. Don't test with 3 documents and a simple schema. Create 50-100 documents with the full complexity of your planned content model. Have actual editors try the workflow. And if you're evaluating Payload, test with the specific Next.js version you plan to use in production.

Regret 2: "I didn't understand the real cost until month six"

Pricing regret on Sanity typically arrives in two waves. The first wave is seat pricing — you start with three editors on the Growth plan at $15/seat/month, and then marketing wants access, then the intern needs an account, then the freelance writer needs to log in. Per-seat pricing scales linearly with humans, and CMS access tends to expand beyond the initial team faster than anyone predicts.

The second wave is metered resources. Sanity meters API requests, bandwidth, documents, and assets. On lower tiers, these aren't just billing items — they're hard caps. If your site gets an unexpected traffic spike or your content library grows faster than expected, you can hit limits that block operations until you upgrade or pay overages. Teams that budgeted for the base plan price discover that the real cost includes a usage component that's harder to predict.

Pricing regret on Payload is subtler and shows up differently. The CMS itself is free and MIT-licensed. The regret comes from underestimating the total cost of self-hosting. You need a database (managed Postgres or MongoDB isn't free), hosting for your Node.js application, object storage for media assets, a backup strategy, monitoring, and the engineering time to set up and maintain all of it. One Reddit thread about first-time Payload deployment captures the pattern well — users struggling with production infrastructure they hadn't budgeted time or money for.

The deeper version of this regret applies to both platforms: teams that chose based on sticker price without modeling their actual usage pattern. A Sanity project with 20 editors and heavy API usage can easily cost more than self-hosting Payload on a $50/month VPS with managed Postgres. Conversely, a Payload project where you need to hire devops help or pay for premium hosting can cost more than Sanity's Enterprise plan would have.

The lesson: model your costs for month one, month six, and month eighteen. For Sanity, estimate your seat count, API request volume, and asset storage growth. For Payload, price out your hosting, database, storage, and the engineering hours for setup and maintenance. Then add 40% to both numbers, because you will underestimate.

Regret 3: "I can't get my content out the way I need to"

This regret is almost exclusively about Sanity, and it's the one that turns into a genuine business problem rather than just a frustration.

The regret doesn't happen immediately. It happens when requirements change. Your company gets acquired and the new parent company standardizes on a different CMS. Your agency client wants to bring the project in-house and doesn't want to maintain a Sanity account. Your startup pivots and the content model needs to change dramatically enough that rebuilding makes more sense than migrating.

When that moment arrives, teams discover what I outlined in my lock-in article: your data is in a proprietary Content Lake, your queries are in GROQ (a language only Sanity understands), and your rich text is in Portable Text (a format that requires Sanity-specific rendering). Exporting raw data is possible — Sanity provides CLI tools for that. But transforming that data into a format another CMS can ingest, rewriting your queries, and converting Portable Text into HTML or another rich text format is a multi-week engineering project that nobody budgeted for.

Payload users rarely report this regret. Your data is in Postgres or MongoDB. If you need to leave Payload, the migration path is "build a new admin panel and API layer on top of your existing database." The data itself doesn't need to be transformed or exported — it's already in a standard format.

The lesson: before you commit to a CMS, run a mental exercise. Imagine you need to migrate away from it in eighteen months. How much of your codebase is coupled to the CMS's proprietary concepts? How much of your content would need to be transformed? If the answer makes you uncomfortable, that's information worth having before you start.

Regret 4: "The security model wasn't what I assumed"

Security regrets play out differently for hosted versus self-hosted platforms.

On Sanity, the most common security surprise is around public datasets. By default, Sanity datasets can be public — readable by anyone, regardless of authentication. Teams that assume their content is private because they haven't shared the project URL discover that public datasets are queryable by anyone who knows the project ID. This is documented behavior and it's configurable (you can make datasets private), but teams that don't read the security docs carefully can expose content unintentionally.

On Payload, the security regrets are more severe. In 2025-2026, Payload disclosed a critical SQL injection vulnerability with a CVSS score of 9.8 — affecting all Postgres and SQLite deployments that use JSON or richText fields through the Drizzle-based adapters, in versions below 3.73.0. A separate vulnerability allowed cross-collection access to user preferences in multi-auth setups using serial IDs on Postgres or SQLite. These are not theoretical risks. They are documented, exploitable vulnerabilities that affected real deployments.

The pattern with Payload security is that self-hosting means self-securing. Sanity handles infrastructure security for you — patching, monitoring, access control at the platform level. Payload publishes security advisories and provides patches, but applying those patches is your responsibility. If your team doesn't have a disciplined upgrade cadence, you can be running vulnerable code without knowing it.

The lesson: for Sanity, read the security documentation carefully. Understand dataset visibility, CORS configuration, and token management before you go to production. For Payload, subscribe to GitHub security advisories and build upgrade discipline into your workflow. If you're using Postgres or SQLite with Drizzle adapters, staying current on patches is not optional — it's a security requirement.

Regret 5: "The migration between versions was harder than expected"

Version migration regret shows up on both platforms, but in different ways.

On Sanity, the big migration story is v2 to v3 (and for older projects, v1 to v3). This wasn't just a package upgrade — it involved changing the build system (Webpack to Vite), rewriting configuration syntax, and adapting to a new plugin architecture. The official guidance recommends initializing a fresh v3 Studio and manually copying your schemas over, rather than trying to upgrade in place. Sanity v2 support ended December 7, 2023, so teams that delayed the migration eventually had no choice. The good news is that the Content Lake data is separate from Studio versions, so you're migrating code, not content.

The v3 to v4 migration was deliberately minimal — the only breaking change was requiring Node.js 20 instead of 18. Sanity explicitly called it "a major version bump for a minor reason." This is reassuring for current users, but the v2-to-v3 experience left some teams cautious about major version bumps.

On Payload, the v2 to v3 migration was more fundamental. Payload v3 redesigned the framework around Next.js integration, changing the internal architecture significantly. One Reddit thread titled "just threw away weeks of work" captures the frustration of teams whose migration assumptions didn't hold. Payload provides migration files and CLI tooling, and v3 has been stable since release, but the migration itself required meaningful refactoring for complex projects.

The additional wrinkle with Payload is that version upgrades can be forced by security patches. If you're running a version below 3.73.0 with Postgres or SQLite and JSON/richText fields, upgrading isn't optional — it's a security necessity. That can compress your migration timeline in uncomfortable ways.

The lesson: before choosing either platform, look at their version history. How often do they ship breaking changes? What does their migration path look like? And critically — how long do they support old versions? Sanity's v2 EOL and Payload's security-driven upgrade pressure both mean you can't just "set it and forget it" with either platform.

Regret 6: "I built the proof of concept with the wrong project type"

This is the meta-regret that encompasses all the others. Teams evaluate a CMS by building a blog or a simple marketing page, and then discover that their actual project — an e-commerce catalog, a multi-tenant application, a large editorial operation — has completely different requirements.

A blog proof of concept won't reveal Sanity's Studio lag with complex schemas because a blog schema is simple. It won't reveal Payload's dev-server weight because a blog has five collections, not fifty. It won't trigger Sanity's API rate limits because a blog gets moderate traffic. It won't expose Payload's security edge cases because a blog usually has one auth collection with a handful of users.

The teams that don't regret their CMS choice are the ones that built their proof of concept using a realistic subset of their actual project. Not a toy blog. Not a tutorial app. A stripped-down version of the real thing, with realistic data volume, realistic schema complexity, and realistic editorial workflows.

The lesson: spend an extra week on your proof of concept. Model your actual content types, create realistic test data, and have real editors try the workflow. Test the queries your pages will actually make. Push the CMS to the edge of what you expect it to handle, and watch where it starts to strain. That week of extra evaluation time can save you months of regret.

The regrets I almost never see

It's worth noting what teams almost never regret, because it tells you what both platforms get right.

Nobody regrets choosing a code-first CMS. Both Sanity and Payload define schemas in code, which means your content model lives in version control, can be reviewed in pull requests, and can be tested. Teams that migrated from GUI-based CMS platforms to either Sanity or Payload consistently report this as a significant improvement.

Nobody regrets choosing a headless architecture. The decoupling of content management from content presentation is a genuine improvement over monolithic CMS platforms, regardless of which headless CMS you choose.

Nobody regrets the developer experience of either platform at a foundational level. Sanity's GROQ is genuinely powerful for shaping content queries. Payload's Local API is genuinely fast for server-side rendering. Both platforms have strong TypeScript support and active communities. The regrets are about specific trade-offs and edge cases, not about the core product quality.

Using this taxonomy

If you're currently evaluating CMS options, use these six regrets as a checklist. For each one, ask: "Have I tested for this? Do I understand how this trade-off applies to my project?" If you can answer yes to all six, you'll make an informed choice regardless of which platform you pick.

And if you've already committed to a platform and recognize one of these regrets — most of them have mitigations. Sanity's Studio lag can be reduced with simpler schemas and careful reference management. Payload's security risks are addressed by staying current on patches. Pricing surprises can be managed with monitoring and quota alerts. The key is recognizing the problem early enough to address it before it becomes a project-level crisis.

Let me know in the comments if you've experienced any of these regrets firsthand, and subscribe for more practical development guides.

Thanks, Matija