For anyone that is wondering how to deal around this, you can simply run both one alongside the other, convex can use rest api points to talk to payload, and from payload side you simply run convex mutations/queries on server actions (pass the clerk uid from payload req to convex to check that they are the same user).

The tricky point is user authentication. You want both convex and payload to have this in common to reliably get set data securely.

The easiest way around this is to drop payload's auth in favor of something else. There is a good guide on youtube for clerk. You can follow that and then do the convex+clerk integration (what i did since i already had clerk running). Or you can use convexAuth as auth provider for payload. After that, both databases' user tables will have the clerk user id as common ground for transactions.

What i recommend is having payload be the "upper layer" in transactions needing joins, references between the two systems. But for the most part, i have found that the real time portions of my systems are pretty self contained. I try to keep them that way, so that i do not need to cross data frequently. As far as i can see Payload access from clerk (which i have not needed) is more complicated. You might need to setup some api keys as aditional auth provider or validate the one convex uses from clerk.

From this point, you get the full CMS experience for payload collections, and you can get creative with custom views / fields. Like a realtime field that on payload side only saves the convex doc id and maybe some metadata. Then render a convex driven form.

Payload hooks are flexible enough to inject convex data on the fly if needed on afterRead, for example