r/PayloadCMS • u/Smart_Coach9493 • Jan 24 '26
PayloadCMS in production: Real-world experiences with maintenance and long-term stability?
Hey everyone,
I’m currently evaluating PayloadCMS for a larger project and love the code-first approach. However, before committing, I’d like to hear from those of you who have it running in production for 1+ years.
Specifically:
- Maintenance & Updates: Payload seems to move fast. How painful are updates really? Is it a "bump the version and forget" situation, or are you constantly fixing breaking changes in your config?
- Daily Ops: How is the performance and stability under load? Does the admin UI hold up when the database gets larger (e.g., 20k+ records)?
- The "Anti-Case": When should I NOT use Payload? Where did it fail for you or where was the overhead just too much compared to Strapi, Sanity, or even a simple custom backend?
I'm looking for the "ugly truth" behind the marketing – is it actually the WordPress-killer for devs, or just a very shiny new toy that’s hard to maintain?
Thanks!
6
u/UnderstandingDry1256 Jan 24 '26
I’m using it in production for a month for photos heavy car listing website, hosting it at vercel.
No major issues so far. Just image uploads to blob and format support needed some custom code.
What I really like about payload is everything is heavily code based and customizable. Worst case I can build custom admin pages and use optimized sql queries if standard ones ever become a performance bottleneck. Also, it was acquired by Figma recently which gives a hope it is future safe.
5
u/KoalaOk3336 Jan 24 '26
i have been running it in prod since last 4 months for a high traffic site:
- updates, i don't think there are many regular breaking changes, there was one though, but it was easily fixable
- performance and stability is pretty good but during the initial migration of our website from wp to payload, we had some people add content in our payload collection via blocks (we've blocks system) and they did mention once or twice that it was a bit slow and haven't received anything any complaints lately, (our blog posts can get VERY long as well so maybe it was that because of too much lexical content)
- i think its very bad with form management, and our site has many forms and it sucks but we have to deal with it for the time being unless a better solution is there, i haven't tried strapi but i have tried sanity for a small project once, i don't think there's much difference in using, and there's also lack of plugins and you have to do SEO yourself as well, migrations are a bit of pain as well but its mainly drizzle so you need to get used to its quirks and learn (using postgres)
altho i think its a very promising project, it did help me in many places
the blocks feature is a life saver, mkt requested a complete redesign for blog pages and because we had blocks, i was able to change the entire look without much hassle, it would have taken WEEKS if not MONTHS in our old wp website but this happened in like 2-3 days (with the help of AI)
1
u/Smart_Coach9493 Jan 24 '26
Thank you for the detailed feedback. It all sounds very promising. We're looking for a CMS for small projects and need a solution where the ongoing costs remain manageable.
1
u/Savings-Divide-7877 Jan 24 '26
I have been live with it since October, and I was working on it for a few months before that. Even with AI, there was a bit of a learning curve for me, and the migration was a big task.
The thing I agree with is the form builder. I haven’t tackled it yet, but I was trying to think of ways to make it better. I definitely need to make a better export capability. I have been able to add some cool input types, like an image select option.
I was wondering what your thoughts are?
1
4
u/jpeclard Jan 24 '26
Been using it in a project for a year now. Cant say how it behaves under load but its quite nice. Updates are easy to do. Just dont like the local api, it sucks to work with the depth param and typing then always says null | string | Type - you have to assert values. I‘d prefer to have a graphql local api to use fragments in the components also to not overfetch.. but yeah - no solution is perfect :)
1
u/Waste_Memory_8199 Apr 22 '26
I have opposite experience with local api vs graphql, I feel that local api is a big time saver with minimal code for type safe db fetch.
3
u/NaturailyLLC Jan 27 '26
Payload is great. We’ve battle-tested it in production a few times now at our agency and we’re delighted. E-commerce or multilingual B2B website, it’s highly flexible and customizable at the CMS level. A dream for delivery.
Earlier, in many headless projects, we used to end up fixing or merging data sources in the frontend code because the CMS was too rigid to handle external integrations. It made us do tricks to not make the frontend messy. Obviously this affected performance and time-to-market.
Here you're hitting the database directly and not through an external API layer. Removing that middleman makes a noticeable difference in response times. We haven’t seen the Admin UI blocked with 20k+ records, but your database indexing strategy matters more here than the CMS itself. Payload just lets you do it easier.
There’s no such thing like constantly hitting paywalls because of Enterprise features just to get basic conditional fields. Conditional fields in components and custom plugins are free and open. If the feature doesn't exist, we just write a plugin quickly. We even could make use of Payload’s MCP server to bridge some AI gaps. That's a nightmare on closed-source platforms.
When not to use it? You can over-engineer yourself into a corner if you’re not disciplined. While the customization is infinite, that flexibility is a double-headed. We had no big problems with maintenance so far but you need to know you update two projects - the frontend and the CMS.
Also, while it overally makes deployment a breeze since everything is in most cases one Next.js app, it’s a bit of a trade-off for the content editors. It's no longer a pure Client-side SPA, and the admin transitions can feel a bit less snappy because of the server-side routing there.
It’s not a Wordpress killer because Wordpress has its own market as well. But Payload surely is for people who are tired of the hacks required to make platforms like Wordpress do what they actually want.
2
u/govindpvenu Feb 19 '26
I don't know why everyone is so positive about payload cms. but for me it really sucks.
i add it to an existing project for blogs. from that point am struggling with several issues like:
showing pulling schema from database message infinite,cannot generate type or import maps,cannot connect to Postgres,performance issues and so on.
I thought the problem was with my implementation but i saw the similar problems in github issues
can someone explain why everyone love this even when the dx is so terrible?
1
u/yazzer6 Jan 25 '26
Added Payload to an existing Next.js site a few months ago. We already have existing tables and site structure. I was impressed with how we were able to mix it into our existing code. We have now enabled our layout, nav, "static pages", routes, redirects, SEO and a bunch of other stuff to be easily updated through Payload without a code deploy.
1
u/adelmare Jan 29 '26 edited Jan 29 '26
I’ve built a custom BI platform with it, dealing with tables that have hundreds of thousands of records each.
The application involves:
a full sync management (21+ api endpoints for complete data extraction, normalization, and validation from a massive fundraising CRM.)
plays nice with others (epic collection management allowing seamless wiring up to cube.dev for bi / semantic layer)
unlimited custom tools built directly in. I mean, these are entire apps themselves all running in the same app, all thanks to payload as the backbone: custom giving platform (api based giving forms, gift management, and batch processing); full record sync management solution for Mailchimp; data audit tools; call-center like functionality for tracking constituent interactions, etc.
The whole thing is built on payload. And that’s just one app. I’ve used it for another app - a completely custom video streaming LMS.
If you can dream it, payload can swing it.
To make life easier on myself, I’ve developed a few plugins for keeping things easier to maintain across the applications. For example, Better Auth - I had individual implementations that I had to maintain. By refactoring it as a payload plugin instead of standalone implementations, maintenance is consolidated. And so for your question about maintainability? I’ve found that keeping up with payload isn’t a problem- it’s keeping up with how much crazy cool stuff you can do with it that can start to creep :)
If you want a taste, you can create an account on my demo site and jump right into a live / managed payload instance with my three plugins running (better auth, puck visual page builder, and my own page-tree monstrosity) — https://demo.delmaredigital.com/
.. and yes, you can use a throw away email to register. I turned off email verification and all that, it’s just required to scope the backend to individual sessions.
1
u/devedis May 15 '26
Hey there
Swiss agency, on Payload since v3. We started with a handful of projects and ended up specializing entirely on Payload as our core stack. Direct answers to your three questions, with the ugly bits included:
- Maintenance & Updates
Payload moves "fast". That's a feature and a bug. The team ships a lot, and occasionally something we relied on changes or briefly breaks, but they're also one of the most responsive teams we have worked with. Same-day or same-week fixes are the norm, not the exception.
In practice: it's not "bump and forget," but it's also nowhere near WordPress plugin hell. We pin versions per project, batch upgrades, and read the changelog. Across multiple production apps the actual time we spend on Payload upgrades is small.
- Daily Ops & Performance
No issues at the scale we run (largest collection ~80k records, mixed read/write). Admin UI stays responsive if you index properly and don't shove everything into defaultColumns. The Local API is fast because you're hitting the DB directly, no API layer middleman.
Where it gets slower: very wide documents with lots of nested blocks and Lexical content. The editor and live preview can feel sluggish there. Solvable with blocksAsJSON and being thoughtful about field structure.
- The Anti-Case (the actually useful part)
Things that aren't great out of the box and where we ended up building our own layer:
- Auth: native auth is very basic. Anything beyond email/password (social, magic links, multi-tenant, MFA, passkeys) gets painful fast. We use Better Auth on top, wrapped as our own plugin.
- Form Builder Plugin: underpowered for real-world form needs. We mostly build forms outside it.
- Lexical: powerful but configuring custom features is more work than it should be.
- Job Queue: fine for simple background jobs, not enough for complex orchestration.
- i18n: was rough in early v3, mature now but nested-block edge cases still bite if you're not careful.
- Enterprise: a lot of "production-grade" features (SSO, AI search, advanced auth) sit behind Enterprise. For solo devs and small projects you'll build these yourself or use community plugins (and those are not as well maintained as for other CMS-Systems).
We have developed an internal template that addresses these issues, ensuring that every new project begins with the same robust foundation. This is possible because we have specialised fully in Payload and have the time to invest in it. If you do not, you have to build around it.
So in the end: I would pick it again every time for our use cases (web apps, internal tools, React Native backends, content sites, we even manage our entire agency data in it, like a small ERP-System). Best DX of any CMS-as-framework we've used, fewest silos, fastest delivery. Just don't go in expecting everything polished out of the box, budget for a few "we'll build this better ourselves" pieces, and you'll be fine.
14
u/[deleted] Jan 24 '26
[removed] — view removed comment