mongodb

[mikenomitch]

The mongodb does not work even with node_compat_v2 on.

It can be imported, but it does not properly connect to a DB. The package relies on net.Socket and tls.TLSSocket.

See Issue for more context: cloudflare/workers-sdk#6684
See Blog for more context: https://alexbevi.com/blog/2024/09/11/why-cloudflare-workers-dont-work-with-mongodb/

[vicb]

@xofyarg reported an issue on the unenv repo which @pi0 fixed.

It should be integrated in unenv with cloudflare/workers-sdk#6920

[vicb]

/cc @ricky11 @anonrig

[anonrig]

Working on this - #3315

[tobsn]

/cc @ricky11 @anonrig

it's been forever now... I can't remember when I encountered this the first time but it must be at least 2 years ago.
as new mongodb atlas instances now dont even list the deprecated data api menu tab and the existing instances will only be available for one more year, it's about hot damn time this gets fixed... ;)

thanks!

[anonrig]

Working on this - #3315

[tobsn]

Working on this - #3315

thank you! this way we can use cloudflare AI on cloudflare workers and still use our mongodb atlas instance... it will save us a massive amount of time and energy. I assume that will be the same with a lot of other people once they realize the September atlas data API deprecation deadline is approaching ... anyway, thanks again! immensely appreciated!

[faradaytrs]

I saw the thread on the forum which says that the only problem is that workers don't support TLS

[Yusaney]

I've started a new Mongodb instance, and I can't use it with my Cloudflare workers; I want to use a Cloudflare environment with queues, kv, etc., but I can't use it if workers don't actually work...

[tobsn]

/cc @ricky11 @anonrig

December 6th

[ricky11]

Amazing, tls support for workers whereby native mongodb drivers would work! that would be such a blessing!

[alexbevi]

@anonrig this is great news!

[Imtiajrex]

any movement on this @anonrig

[anonrig]

I've opened an in progress PR - #3315

[anonrig]

TLSSocket and connect() has landed into main. It will be available to the general public in the next couple of weeks.

[DaryeDev]

How can one use mongodb on Workers, now that node:net is merged?

[DaryeDev]

Great to know, thanks!

[vicb]

FYi, this code works on bleeding edge (available in 5-10 days)

[DaryeDev]

Perfect, should be just updating the worker library, then. Thanks!

[raininglemons]

Is there any where public these kind of releases can be tracked?

[vicb]

Is there any where public these kind of releases can be tracked?

We'll give an update here when the changes are deployed.
The current status is that all changes have been merged,
it will take a few days before this reaches wrangler and prod.

[vicb]

As promised, here is an update:

workerd now implements node:timers and node:net (thanks @anonrig).

wrangler 3.106 which was just released contains the latest version of workerd.

Meaning that you should be able to use mongodb from your node apps!

Please test and report your experiences!

🙏

edit:

You need to use the nodejs_compat compatibility flag with a compatibility date set after 2024-09-23.

I have tested with:

# wrangler.toml
compatibility_date = "2024-12-05"
compatibility_flags = ["nodejs_compat"]

[JetLua]

TLSSocket and connect() has landed into main. It will be available to the general public in the next couple of weeks.

Latest Wrangler test result: querySRV EBADQUERY _mongodb._tcp.yew.oqbm7gt.mongodb.net

update: everything was perfect!

[sarge1989]

@JetLua Ran your minimal repro, mine's working on a deployed worker

[JetLua]

Sorry, everything was perfect! Thank you.

[huw]

Working for me, including with Mongoose! Mongoose just needs a quick patch to add package.json#exports:

diff --git a/package.json b/package.json
index 46468fcb6a56ecd494c5a590b2940746a29c57ba..29a1a366f9e2adbdac15ee3dc3d43648d40eb3cd 100644
--- a/package.json
+++ b/package.json
@@ -112,6 +112,15 @@
   },
   "main": "./index.js",
   "types": "./types/index.d.ts",
+  "exports": {
+    ".": {
+      "workerd": "./index.js",
+      "node": "./index.js",
+      "browser": "./dist/browser.umd.js",
+      "types": "./types/index.d.ts",
+      "default": "./index.js"
+    }
+  },
   "engines": {
     "node": ">=16.20.1"
   },

(Otherwise, it’ll import the browser bundle. See Automattic/mongoose#14613)

[pawmanaloto]

Working for me, including with Mongoose! Mongoose just needs a quick patch to add package.json#exports:

diff --git a/package.json b/package.json
index 46468fcb6a56ecd494c5a590b2940746a29c57ba..29a1a366f9e2adbdac15ee3dc3d43648d40eb3cd 100644
--- a/package.json
+++ b/package.json
@@ -112,6 +112,15 @@
   },
   "main": "./index.js",
   "types": "./types/index.d.ts",
+  "exports": {
+    ".": {
+      "workerd": "./index.js",
+      "node": "./index.js",
+      "browser": "./dist/browser.umd.js",
+      "types": "./types/index.d.ts",
+      "default": "./index.js"
+    }
+  },
   "engines": {
     "node": ">=16.20.1"
   },

(Otherwise, it’ll import the browser bundle. See Automattic/mongoose#14613)

How did you make it work? Do I need to do something or just wait for Mongoose to patch it?

[vicb]

/cc @alexbevi ☝️

[alexbevi]

Thanks for flagging @vicb. I've been following along closely and looking forward to testing this out now that the latest workerd is released with additional Node API support.

[ai-slave]

The moment i finally give up and switch to D1 from mongo you release THIS. But big thank you for finally doing this!!

[dustinsherwood]

Same

[ricky11]

how is your experienced moving to d1 from mongo? d1 is sql i believe. must be low latency for all over the world?

[equalogix]

I want to raise another related issue. First off there is a workaround see: mongodb polyfill
I have been using it in development since it was published and it mostly works. However, there is a bug that occurs when making certain requests, Mongodb throws: BSONOffsetError. I believe it is caused when the requests to the database returns a large object. In my case I get the error when making $vectorSearch request and getting back many documents. The exact error is:
Mongodb vector search error: BSONOffsetError: Parsed documentSize (10568 bytes) does not match input length (4075 bytes). offset: 0
I'm guessing that this error is not specific to the polyfill and will arise even when TLSSocket issue is resolved.

Another important point:
I am developing my app using ReactRouterv7, if I run the app locally using the react-router dev (basically using node-js), I don't get the errors. But if I run locally using wrangler dev or if I deploy the app, then I get the errors.

@alexbevi, seeing as you are from Mongodb, do you have any insight about this error, have you encountered it? The BSONOffsetError object itself is marked as experimental in the Mongodb Docs.

Finally I'm not the only one that is getting these errors, see polyfill issue 4

[equalogix]

I was wrong, this bug has everything to do with the polyfill. But the good news is that I fixed it, and I am now able to use MongoDb Atlas from my Cloudflare worker in preview and production. I have made a pull-request in the polyfill's repo with changes, waiting for it to be reviewed and merged.

[alexbevi]

Thanks for staying on top of this @equalogix. I haven't had a chance to test the polyfills again (hopefully can do that soon), but FYI #3594 is currently being worked on as well (which should hopefully be the last piece of the puzzle to getting this working natively in workerd)

[ricky11]

Amazing work guys, this will be one less reason to leave MongoDB due to the deprecation of the DATA API, hoping for documentation around this as well, or a blog post to help us newbs.

[ManasMadrecha]

If everything's working fine in a production deployed worker, can we kindly have a blog or official documentation on it to so that googling "how to use mongodb with Cloudflare worker" shows that article and not GH discussion? 😊🙏🏻 Thanks for all your amazing work everyone.

[equalogix]

You need to explicitly close the connection when you are done with it with client.close(). You can (and should) keep a connection open and make multiple call to the db from it (as needed) but only for as long as the worker is processing its request.

[ricky11]

Yes was thinking the same.. I currently use lamba functions with mongdb, and functions last about 20-30 seconds, subsequent connections use the existing connection and provide super fast 10ms connectivity... pooling is out of my technical expertise, but would be great if this supports cloudflare hyperdrive which keeps connections open (currently only works with sql i believe)

[gerhardcit]

@ricky11 , been testing this with a Mongo Atlas (Flex) db.
added maxIdleTimeMS and using client.close() I cannot get the number of connections past 10 to show up on Atlas monitoring.

const client = new MongoClient(uri, {
    maxPoolSize: 1,
    minPoolSize: 0,
    serverSelectionTimeoutMS: 5000,
    maxIdleTimeMS: 10000, // Close idle connections after 10 seconds
} as MongoClientOptions);

but I would love to hear some expertise around the architecture of mongo connections and how Atlas handles that.

[ricky11]

CF Pages returns a build error from one of my functions.. I have the flags set correctly in wrangler.toml within my functions directory.

Works beautifully locally with wrangler pages dev ./dist, but when pushed to cf, pages fails to build the project.

Any ideas?

14:32:38.016	✘ [ERROR] Could not resolve "mongodb"
14:32:38.016
14:32:38.016	api/incrementdlPusher.js:1:38:
14:32:38.016	1 │ import { MongoClient, ObjectId } from 'mongodb';
14:32:38.016	╵ ~~~~~~~~~
14:32:38.016
14:32:38.016	You can mark the path "mongodb" as external to exclude it from the bundle, which will remove this error.

[ricky11]

Found that this is because pages uses ⛅️ wrangler 3.101.0, now i need to see how i can modify the version in pages.

[ricky11]

Has anyone gotten this to work with Pages Functions as oppose to native workers.. I think CF Pages Functions use a different version of wrangler which still fails.

[anonrig]

cc @vicb

[ricky11]

Found out that pages functions is pinned to 3.101, what we need is 3.106. I was asking the guys on discord too.

[huw]

Starting a new thread for issues with connection pooling. We’d like to re-use connections across invocations, because otherwise we add a ~1500ms cold start to every invocation. However, @gerhardcit noted that you can’t re-use connection pools (created by mongodb.connect or mongodb.createConnection) across invocations of the same worker, because it gives this error:

✘ [ERROR] A hanging Promise was canceled. This happens when the worker runtime is waiting for a Promise from JavaScript to resolve, but has detected that the Promise cannot possibly ever resolve because all code and events related to the Promise's I/O context have already finished.
✘ [ERROR] Uncaught (in response) Error: The script will never generate a response.

This isn’t that informative, because the actual issue is that a deeper exception gets caught, which causes the promises to not resolve. Firing up the debugger and breaking on caught exceptions gives us:

Exception has occurred: Error: Cannot perform I/O on behalf of a different request. I/O objects (such as streams, request/response bodies, and others) created in the context of one request handler cannot be accessed from a different request's handler. This is a limitation of Cloudflare Workers which allows us to improve overall performance. (I/O type: Writable)
  at Socket._writeGeneric (node-internal:internal_net:328:33)
    at Socket._write (node-internal:internal_net:355:10)
    at writeOrBuffer (node-internal:streams_writable:366:12)
    at _write (node-internal:streams_writable:308:10)
    at TLSSocket.write (node-internal:streams_writable:312:10)
    at _Connection.writeCommand (file:///<REDACTED>/.wrangler/tmp/dev-V18Y3f/index.js:28009:25)
    at async _Connection.sendWire (file:///<REDACTED>/.wrangler/tmp/dev-V18Y3f/index.js:27877:11)
    at async _Connection.sendCommand (file:///<REDACTED>/.wrangler/tmp/dev-V18Y3f/index.js:27920:22)
    at async _Connection.command (file:///<REDACTED>/.wrangler/tmp/dev-V18Y3f/index.js:27957:26)
    at async _Server2.command (file:///<REDACTED>/.wrangler/tmp/dev-V18Y3f/index.js:29563:25)

Okay, so it seems like a non-starter to actually re-use a connection in a Worker. Instead, let’s try use a singleton Durable Object to manage the connection pool. Durable Objects shut down about a minute after their last client disconnects, which should be enough to keep a connection pool around across multiple requests.

I added this to wrangler.jsonc:

{
  "durable_objects": {
    "bindings": [
      {
        "name": "MONGO_DB_CONNECTION",
        "class_name": "MongoDBConnection"
      }
    ]
  },
  "migrations": [
    {
      "tag": "v1",
      "new_sqlite_classes": ["MongoDBConnection"]
    }
  ]
}

My index.js looks like this. I’ve provided a locationHint to my DO, based on where my MongoDB databases are:

export { MongoDBConnection } from "./MongoDBConnection.js";

export default {
  async fetch(request, { MONGO_DB_CONNECTION, MONGO_DB_URI }) {
    // FWIW, you’ll probably want to do an auth check or similar here, to prevent wasting resources on fuzzing attacks
    // We can just forward the request straight onto the Durable Object
    const id = MONGO_DB_CONNECTION.idFromName(MONGO_DB_URI);
    const connection = MONGO_DB_CONNECTION.get(id, { locationHint: "apac" });
    return await connection.fetch(request);
  }
};

Then MongoDBConnection.js looks like this:

import { DurableObject } from "cloudflare:workers";
import mongoose from "mongoose";

export class MongoDBConnection extends DurableObject {
  connection;

  constructor(ctx, env) {
    super(ctx, env);
    this.connection = mongoose.createConnection(env.MONGO_DB_URI, {
      // Decrease the selection timeout from 30s (default) to 5s, so that if something breaks, we don't wait around for it.
      serverSelectionTimeoutMS: 5000,
      // Time out idle connections after ~20 seconds, to avoid using up too much wall time (tweak this as needed for your use case)
      maxIdleTimeMS: 20 * 1000,
    });
  }

  async fetch(request) {
    // Wait for the connection to become available
    await this.connection.asPromise();
    // Do work here
    return new Response("OK");
  }
}

This code just transparently forwards all requests straight onto the DO, which can hold onto the connection pool across multiple requests and re-use it. My end-to-end timings went from ~2000ms to ~300ms after doing this!

[Imtiajrex]

@alexbevi which version of mongodb did you use for your blog post? Been testing something similar to your article, but get serialization issues (presumably with DO). Want to try and test as close to the working example you had :)

Could not serialize object of type "Db2". This type does not support serialization.

You can't pass javascript Objects/function back and forth between DO and workers. only json serializable data can be passed

[raininglemons]

Ah @Imtiajrex that's it. I've misunderstood DO. I was trying to instantiate the client, then pass it to the calling worker. So really what I need to do is actually proxy all calls to the client through the DO, then return the response after it's resolved. Hero, thanks

[irvinebroque]

You can pass any structuredclone-able JS type between Workers and Durable Objects

https://developers.cloudflare.com/workers/runtime-apis/rpc/

[huw]

Let me know if any of you figure out how to deal with this:

All of my requests return quite quickly, no issues, but because the Durable Object hangs around I get 2 issues with Workers Logs. First is, as above, the wall times for all of my invocations look much longer than I’d expect them to report. And second, the logs for the Durable Objects don’t show up in Workers Logs (either real-time or stored) until the Durable Object goes idle, which can take minutes. It makes debugging annoying. Evidently, the cause of this is the long timeout on the MongoDB connection, but I don’t want to shorten that.

[alberto-htl]

Still slower than Aws lambda right? It would be great to be able to reuse the connection natively between calls like lambda.

[flixyudh]

someone can tell me how to make a connection between cloudflare worker with mongoDB Atlas? i don't know how to get public IP of cloudflare worker to be added into mongoDB Atlas network access dashboard.

[jkauszler]

Has anyone had luck connecting remotely with these public addresses? I've only been able to get 0.0.0.0 to work.

[tobsn]

Has anyone had luck connecting remotely with these public addresses? I've only been able to get 0.0.0.0 to work.

you can't basically, I asked Cloudflare directly. if you use workers the remote IP addresses are all over the place from ALL their IP addresses they have, all ranges — the IP list is something separate and does not apply to workers. (not what Im saying, quoting their support)
You are forced to open it to any IP range. I switched to Cloudflares D1 and Supabase... not worth the pain in the butt trying to make this work. I guess it's in benefit of Cloudflare.

[jkauszler]

if you use workers the remote IP addresses are all over the place from ALL their IP addresses they have, all ranges

This makes sense if they're leveraging each of their nodes around the globe for compute (workers). It's definitely not ideal though for an access security perspective. Thanks for the report, @tobsn

If anyone has found ways to implement a network allow list on mongo that doesn't also redirect from a single proxy, I'd love to hear how. Curious to see if there's a clever solution, either with existing CF services (R2, KV, DO, etc) or some external service.

@alexbevi you've been exploring cool ways integrate CF and Mongo together. Any ideas here?

[tobsn]

fyi I think the whole mongodb and Cloudflare implementation issue is a very very niche problem as this wasnt possible in the beginning so most have already skipped it long ago. if you ask claude/etc. it will actually tell you its not possible as this was status quo for so long. you could use D1 and then http into D1 and sync it into mongodb?

[anonrig]

cc @thomasgauvin

[ricky11]

Tangent: been using the Postmark node sdk with workers for a couple of weeks, but today the worker returned:

"There is no suitable adapter to dispatch the request since :\n- adapter xhr is not supported by the environment\n- adapter http is not available in the build"

Postmark does have a API, but cumbersome, any chance of looking into Postmark support?

[66Bunz]

I tried to set up an integration between MongoDB and Cloudflare Workers (free plan), following Alex Bevilacqua's tutorials, this discussion and other threads around the internet, tried to mess around with compatibility dates and flags, but I still get this following error only when deploying, it's working fine with wrangler dev on my machine:

MongoDB connection error: MongoServerSelectionError: [unenv] net.createConnection is not implemented yet!

am I missing something? I can see that the createConnection is not available yet (https://developers.cloudflare.com/workers/runtime-apis/nodejs/http/#request) but I guess that for someone it works, I just cannot figure out what the missing part is.

If someone could help me I'll be grateful.

[anonrig]

please enable nodejs compat flag, and set a recent compat date.

[alexbevi]

@66Bunz If you're going off the article I have at https://alexbevi.com/blog/2025/04/11/performance-profiling-mongodb-on-cloudflare-workers/#default-workers-experience I've got a wrangler.jsonc and test script that should allow you to verify this.

[66Bunz]

please enable nodejs compat flag, and set a recent compat date.

This is my wrangler.toml

name = "droptop-api"
main = "src/index.js"
workers_dev = false
compatibility_date = "2025-09-15"
compatibility_flags = ["nodejs_compat"]

[observability]
enabled = true

[[durable_objects.bindings]]
name = "MONGODB_DURABLE_OBJECT"
class_name = "MongoDBDurableConnector"

[[migrations]]
tag = "v1"
new_sqlite_classes = ["MongoDBDurableConnector"]

[66Bunz]

@66Bunz If you're going off the article I have at https://alexbevi.com/blog/2025/04/11/performance-profiling-mongodb-on-cloudflare-workers/#default-workers-experience I've got a wrangler.jsonc and test script that should allow you to verify this.

Creating a new worker with your example works. I'll try to create a new one for mine too, maybe this solves the issues.

[66Bunz]

Idk why when I stopped using the wrangler.toml and started with wrangler.jsonc file everything works.

[tobsn]

@66Bunz

import { MongoClient, MongoClientOptions, UpdateResult } from 'mongodb';
client = new MongoClient(mongoUri, {
        maxPoolSize: 5,
        minPoolSize: 0,
        serverSelectionTimeoutMS: 10000,
        connectTimeoutMS: 10000,
        socketTimeoutMS: 10000,
        maxIdleTimeMS: 30000,
        minHeartbeatFrequencyMS: 2000,
      } as MongoClientOptions);

wranger.toml

compatibility_flags = ["nodejs_compat_v2"]
compatibility_date = "2024-03-20"

packages.json

  "dependencies": {
    "mongodb": "^6.18.0",

Quick copy paste from one of a quick worker I did last week, its vibe coded because its just a 1:1 proxy of data no handling and I did not want to waste time on it - it used the example code from the blog that shows how to implement the socket changes.
I had not seen the compat date until now because it worked fine... hope it helps a bit.

[66Bunz]

Idk why when I stopped using the wrangler.toml and started with wrangler.jsonc file everything works. Even though you have been using a toml file, idk why mine wasn't working

[tobsn]

im not sure either what exactly works... I tried for a while earlier this year to get it to work and I just couldn't. no example, no config combination worked. couple weeks ago I fed all the data into Claude Code and had it figure it out and it ran like 10 different combinations and that somehow then started to work.

[mikenomitch]

Resolving as this is now doable with nodejs_compat

[ricky11]

Yes it works work Cloudflare Workers, but does not work in Cloudflare pages functions -- reason is the workerd that is used in cloudflare functions is pinned to use a older version hence even with the nodejs_compact this will not work in functions.

[MasFana]

Does it work on Framework Template like Solid,Svelte ?