It's been a whirlwind of activity at Payload since we launched version 2.0, and I wanted to take a moment to share with all of you some of our progress and our exciting plans coming over the next few months.

Amid all the hustle bustle, we've managed to double most of our performance metrics, which undeniably was a challenging task with exciting results. The adoption of Payload has skyrocketed in the last month, and there are many things in flight at the moment, but I am incredibly excited about the future.

Before we delve into what's to come, let's pause and discuss our current situation.

Conquering Bugs and Issues

One of our chief priorities is dealing with bugs and open issues. If you've been keeping tabs on our progress, you'd notice that the Payload team is on a sprint to resolve these issues. Every week we set aside “Bug Fix” Mondays, where we pull an all-day marathon to tackle and debug as many issues as possible.

At present, our focus isn't on introducing novel features but enhancing stability, resolving bugs, and optimizing existing ones to give you a smooth and positive experience with Payload.

Looking at our Github, there are 66 open pull requests for issues. A number lesser than what most other CMS and application frameworks have, but we aspire to keep it as low as possible. Know that we are tirelessly working on keeping on top of things and ensuring bugs don't pile up over time.

Stabilizing Newly Released Packages

Our second focus area is stabilizing the packages that we introduced in version 2.0, including Postgres, Lexical, and Live Preview. These features are getting our particular attention as we want them to transition from beta to stable as early as possible.

In particular, our adapter-based pattern has us excited about what we can do. For example, Postgres will also be able to run without being influenced by our work on Next.js (more details below). It can function alongside it, which is exciting news.

We also plan to improve how we handle relationships in your database when using Postgres. For instance, instead of jamming everything into one Payload relationships table for each collection, we're working on providing you with more of an expected table structure, especially in one-to-one relationships.

We also plan to roll out performance optimization for Live Preview, particularly optimizing how relationships are batched and retrieved as they’re updated from the frontend.

Contribute to Payload

Briefly, we’ve cleaned up our roadmap, but I want to point out that we have labeled several items with "help wanted" tags. These are low-ambition tasks that would be perfect entry points for folks looking to contribute to Payload. Browse through our Priority 1, 2, and 3 tags, pick out tasks marked "Help wanted," and lend us a hand. We're most likely to give attention and merge PRs related to these issues.

Yes, Payload Will be Moving to Next.js

Let's talk about the big stuff.

I found it pretty revealing that we opened up a roadmap discussion about moving to Next.js just two weeks ago, and it's already received significant traction. And, as everyone probably expects at this point, Payload will be moving to Next.js.

Personally, I think that this is going to be a fantastic move for us.

We've completed a very promising proof-of-concept, and we've got a utility that automatically parses the config down into only things that are safe to be run in the browser—so you don't need to worry about it ever again.

This monumental shift means you're going to get server-side hot module reloading out of the box. So when you change your Payload config, your handlers / endpoints will automatically update. This eliminates the need for nodemon. It will just work seamlessly.

Another benefit is the simplification and quality of our templates and boilerplates. At the moment, we’re maintaining several Next.js templates. This includes our website template and e-commerce template, among others. After moving to Next.js, these templates will inherit unparalleled stability, while allowing Payload to better focus as a company.

And then we're also going to completely remove our requirement of supporting bundlers.

In retrospect, our release of Vite was a mistake. Though great for simple projects that are not isomorphic, meaning that they don't have code shared between the server and the browser, incorporating Vite did not really fix any of our problems. It was a good exploration, but with Payload and Next.js, it becomes unnecessary. We're going to just use Next.js as the compiler. We are close to getting Turbopack working already, which is very exciting—and that's going to be a huge DX improvement.

How We’ll Make the Move

To pull off the move to Next.js, we’ve assembled a “Skunk Works” team.

Back in the Cold War era, Lockheed Martin had a group of very talented engineers that were basically assigned to a secret project, and they worked away from all of the bureaucracy and the red tape and everything else. They just worked in this little tiny unit, labeled “Skunk Works,” with a specific goal of moving very quickly and very effectively.

That’s how we envision our move to Next.js.

Meanwhile, the rest of the Payload team is going to continue focusing on the issues and the stability of the ecosystem and our other roadmap items.

When we get close to releasing Next.js, there will be breaking changes with this. However, one thing we learned from our 2.0 release is that we're not just going to throw out 3.0. Instead, as soon as we have a proof-of-concept that’s ready to share, we're going to release 3.0 beta, and we're going to let it cook—for months. That's going to be on another branch, and we're going to support both 2.0 and 3.0 beta.

We anticipate this could all come about relatively quickly. But what we want from our community, especially those of you that understand how Payload works, is to get into that 3.0 beta, let us know what you think, and help us fine-tune and improve so that before we release it, it's good, stable, reliable, and that it’s been put through the ringer.

Exciting Features to Watch Out For

Besides moving to Next.js, we also have dozens of features outlined in our roadmap, categorized into priorities one to three. Few of the major ones include:

Bulk Upload: A feature that allows for multiple uploads at the same time. We expected to have this done in the next month.
Folder View: A folder system for our list view to manage not just media but any document with a folder structure.
List Filters: Often in Payload, you might have big collections that have considerable querying potential, and you may want to save filters for reuse. This will allow you to define filters statically in code, and even save them on a user-by-user basis. You will then be able to reference them quickly whenever you return to the admin panel.
Localization Improvements: Visually differentiating localized fields from non-localized fields, publishing individual locales, and editing multiple locales at once.
WebSocket API: To enable real-time communication, and open the door to future features like multiplayer editing. We’re aiming to build in a very isolated, compartmentalized way, similar to how we built database adapters, where you can install it and it will just work. And this is going to open up the door for real-time communication between Payload and your frontend.
SQLite and MySQL Support: We are going to add SQLite support as a precursor to the goal of eventually adding MySQL support.

I encourage you to explore more of these features on our roadmap and upvote the ones you would like us to prioritize. Keep an eye out for more updates on our progress!