MongoDB adapter: no way to use Vercel attachDatabasePool to avoid MongoDB Atlas connection limit

[jhb-dev]

Describe the Bug

On Vercel (Fluid Compute enabled) with Payload v3 and the MongoDB adapter, I frequently hit MongoDB Atlas Flex’s 500 concurrent connections limit. Other developers have reported similar connection limit issues on Discord.

Vercel recommends attaching database clients to its function lifecycle using @vercel/functions attachDatabasePool so connections are cleaned up when functions are suspended. This pattern is not currently possible with Payload’s MongoDB adapter, since there is no supported way to inject or wrap the MongoClient instance.

Reference (Vercel announcement and sample code):

import { MongoClient, MongoClientOptions } from 'mongodb';
import { attachDatabasePool } from '@vercel/functions';

const options: MongoClientOptions = {
  appName: "devrel.vercel.integration",
  maxIdleTimeMS: 5000
};
const client = new MongoClient(process.env.MONGODB_URI, options);
   
// Attach the client to ensure proper cleanup on function suspension
attachDatabasePool(client);

// Export a module-scoped MongoClient to ensure the client can be shared across functions.
export default client; 

In general, I could not find any official resources from Payload explaining how to prevent excessive database connections when hosting on a serverless platform like Vercel.

Link to the code that reproduces this issue

https://github.com/payloadcms/payload/tree/main/packages/db-mongodb

Reproduction Steps

Which area(s) are affected? (Select all that apply)

db: mongodb

Environment Info

Binaries:
  Node: 24.3.0
  npm: 11.4.2
  Yarn: N/A
  pnpm: 10.12.4
Relevant Packages:
  payload: 3.62.0
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6041
  Available memory (MB): 24576
  Available CPU cores: 14

[joshuademarco]

Same issue here, last night my application on Vercel fully bricked as i hit the 500 connection limit with MongoDB Atlas. Website became fully unresponsive as no more connection could be made. I assume this would solve it. Maybe also related to #7312 ?

[ChristopherNowlan]

Yeah I'm having the same issues on a few projects. All of them are using the nested docs plugin

[AlessioGr]

Please test out https://github.com/payloadcms/payload/pull/14649 and let me know if it works (see PR description for example).

Pre-release: 3.65.0-internal.ef3958a

@ChristopherNowlan @joshuademarco @jhb-dev

[joshuademarco]

Please test out #14649 and let me know if it works (see PR description for example).

Pre-release: 3.65.0-internal.ef3958a

@ChristopherNowlan @joshuademarco @jhb-dev

Didn't test it in length but it looks solved to me. Connections stabilized around 100 compared to the volatile 200-500 connections before:

Thanks for jumping on this so quickly. Really appreciate it!

[ChristopherNowlan]

I think its better. Will let you know how it goes during heavy admin use

[ChristopherNowlan]

On another project as soon as a user started using the CMS it spiked. Happy to share access to repo. See if its something I have done.

[ChristopherNowlan]

@AlessioGr I don't think the above fix actually fixed my issue. When a user uses the admin the connections spike and the cms pretty much become unusable.

[joshuademarco]

I can confirm that the 500-connection limit still gets hit and breaks the application. However, i have a hunch that we have two separate issues here.

Referring to my post above, connections (at least in my example) have become generally les and more granular after implementing attachDatabasePool. Meaning that even if connection spikes, it does not hold for long and quickly reverts to a low number. I would say this confirms that the implementation was correct and the function works as intended:

"This function ensures that idle pool clients are properly released before functions suspend." - Vercel - Docs

Something i realized is that connection count definitively spikes whenever i open media collection in the admin panel. Can somebody confirm this behaviour? Even after setting disablePayloadAccessControl: true

Also, if somebody is interested about the problem: The real serverless compute to database connection problem, solved

[ChristopherNowlan]

@joshuademarco Same when the media collection is open it spikes or uploading a image. Then seems to stay high for awhile. Im using @payloadcms/storage-s3 . I haven't disable access control yet. Is it worth adding?

[mquayle-viewa]

@joshuademarco @ChristopherNowlan I've had similar issues with the media collection (also using storage-s3). Implementing disablePayloadAccessControl: true helped, but what (almost) solved it for me was removing the image preview from the Media list view by setting defaultColumns to exclude the image/media preview.

I never confirmed this, but it looked to me that a new DB connection was being opened for each image that was displayed on the list view - If I set to the page to display 100 entries at a time, my DB connections would blow up.

[ChristopherNowlan]

@mquayle-viewa removing the filename column from the default columns show seems to have reduced the connections. @AlessioGr maybe something worth investigating there.

[jhb-dev]

Thanks for the quick fix and the pre-release, @AlessioGr!

I can also confirm that connections now close significantly faster, resulting in a more granular and overall lower number of open connections.

@ChristopherNowlan @mquayle-viewa @joshuademarco I previously encountered the same issue where opening the media list view, particularly with a large pagination limit, caused a big surge in new connections. The underlying reason was that the /api/media endpoint was hit with many parallel requests to load the thumbnail images.

I resolved this by setting disablePayloadAccessControl: true and ensuring that thumbnailURL points directly to the storage provider (in my case S3). With this approach, there is no need to disable the filename (and therefore the thumbnail) column in the list view.

I recommend opening the media list view with your browser’s dev tools to inspect the outgoing requests. If you observe numerous calls to /api/media, this is likely the cause of the elevated number of database connections.

[ChristopherNowlan]

@jhb-dev I tried that but than all my images 404. Do I need to update my image component?

[jhb-dev]

@ChristopherNowlan so you mean the thumbnail images do not load in the list view? I think then you should check if the thumbnailURL field is correctly generated for your images. It might also be worth checking if these are incorrectly stored in the DB (may be related to https://github.com/payloadcms/payload/issues/14562)

[ChristopherNowlan]

@jhb-dev the image don't load on the front end either - https://drkaylenehenderson.vercel.app/

[jhb-dev]

@ChristopherNowlan It looks like there is an issue with the url and thumbnailURL fields in your media collection. When inspecting the media entries via the API (https://drkaylenehenderson.vercel.app/api/media), you can see URLs such as undefined/drkaylenehenderson.com/Resource Pack 1-300x188.webp

[joshuademarco]

@ChristopherNowlan @jhb-dev @mquayle-viewa Definitively the issue, setting disablePayloadAccessControl: true does indeed still cause thumbnails to be queried through db and ultimately result in multiple not found.

A shame that Payload does not point the thumbnail automatically to the blob like it does with file url. Setting the following in the upload field, is working for me:

adminThumbnail: ({ doc }) =>
      `https://<STORAGE URL>/${(doc.sizes as any)?.thumbnail?.filename ?? doc.filename}`,

@AlessioGr I don't know how easy the above is to fix but maybe we could get a little documentation section under Deployment > Performance? To prevent others from going down that rabbit hole too

[github-actions[bot]]

🚀 This is included in version v3.65.0