Been struggling with MongoDB ORMs in serverless environments for months. Everything was either too heavy, had terrible TypeScript support, or just didn’t work with Cloudflare Workers’ connection model.
Just wanted to share what I ended up building - Mondel. It’s a 27KB TypeScript ORM that actually solves the serverless MongoDB problems:
const userSchema = defineSchema("users", {
timestamps: true,
fields: {
email: s.string().required().unique(),
role: s.enum(["ADMIN", "USER"]).default("USER"),
},
});
// Factory pattern for serverless (no persistent connections)
const connect = createClient({ serverless: true, schemas });
// Just works in Workers
const db = await connect(env.MONGODB_URI);
const user = await db.users.create({ email: "test@example.com" });
What finally worked for me:
Bundle size under 30KB (was hitting 100KB+ with other ORMs)
Full TypeScript autocomplete (no more runtime type errors)
Lazy connections (crucial for Workers pricing model)
Built-in Zod validation
Transactions, aggregations - all the MongoDB features I need
Been running this in production for 6 months now. If anyone else is dealing with the “MongoDB + serverless” headache, this might save you some pain.
Full disclosure: I’ve been using this in production and just published it to NPM today as v0.2.0. It’s been battle-tested in my apps but would love feedback from others dealing with the same MongoDB + serverless headaches.
What solutions have you guys found for MongoDB in serverless?
Please confirm that MONGODB_URI supports srv version, or we will have to use legacy URI with multiple replica sets, and lastly, is it production-ready? How much latency do you experience with Cloudflare Workers?
This is really interesting, @Edjo_Brandao. Thanks for sharing
I recently wrote about using a reusable MongoDB client pattern with TanStack Start, and it’s cool to see similar problems being solved in edge runtimes. Curious how you’re handling connection reuse and cold starts in Workers?
I worked around this by maintaining state using durable objects, but I’d be curious to get a sense of how effective you’ve found your approach. Have you benchmarked this to validate it’s behaving the way you expect?
I don’t know why api latency is still 1-2 seconds for simple api requests, possibly due to workers’ cold starts, short lived connection, as Cloudflare Hyperdrive only supports PostgreSQL or SQL-based databases optimized for serverless workers.
Currently, it seems hard to go with mondel at production, although it was a good attempt to fix MongoDB connectivity with workers. In future updates, this may get fixed.
Mondel uses the native MongoDB Node.js driver without altering latency.
1–2 seconds is usually not caused by the library itself, but rather by connection establishment, region distance, or workers’ cold starts.
Since Hyperdrive is limited to PostgreSQL, the comparison is irrelevant.
With plain driver code, the same delay would occur. I can assist with troubleshooting if you share your setup (DB provider, region, and connection pattern).
Thanks! That’s because Mondel is essentially a thin TypeScript layer on top of the native MongoDB Node.js driver.
It doesn’t introduce a custom engine or heavy abstractions — the goal is simply to provide better organization and type safety while keeping full support and performance of the official driver.
Yes, SRV URIs are fully supported.
It’s production-ready, as it uses the native MongoDB Node.js driver.
On Cloudflare Workers, latency is low, but traditional connection pooling is limited by the runtime.
Yep, you’re reading it correctly. Mondel caches the MongoClient at module scope to maximize reuse within the same Worker isolate. Once the isolate gets recycled (cold start / eviction), a new MongoClient (and pool) will be created again — there’s no way around that with plain in-memory caching.
I haven’t benchmarked this yet. It’s open source, so I’d actually love help to validate it - if you’re interested in running a quick benchmark, or sharing your DO-based approach/results, I’m happy to collaborate and document the findings.
Excellent question! Mondel uses only the official MongoDB Node.js driver and doesn’t implement any custom connection logic.
The driver’s built-in connection pool and the same client are reused across requests in a warm Worker isolate by caching a single instance of MongoClient at module scope.
There is a crucial disclaimer with Cloudflare Workers, though: recycling the isolate erases the in-memory cache, and a new client (and pool) will be created for the subsequent request. Therefore, cold starts are ultimately a platform limitation rather than a library issue, but reuse works well while the runtime stays warm.
Mondel keeps behavior consistent and in line with the native driver by simply adhering to this standard pattern without any additional abstraction.
@Edjo_Brandao, that’s a really clear breakdown, thanks for explaining. Sticking with the official MongoDB Node driver and leaning on its native pooling behavior is a clean approach.
And yes, the isolate recycling caveat is important context. Appreciate you calling that out
If this package is a thin wrapper for the official mongodb driver (which is now supported by cf workerd) then how is this “lighter” then the original drivers? the mongodb node modules are still loaded into the worker runtime no? i get the TS support which is great, but doesn’t the official package also have types?
When you say 27kb, it is still importing mongodb (1mb), so you mean its 1m + 27kb.
@Rishi_uttam Yes, there is a dependency on the MongoDB driver, but it won’t be installed automatically. Just like we also have a dependency on Zod… what we’re saying is that the ORM layer is only 27kb.
Ps: During installation, we specified that the command to be executed is pnpm add mondel mongodb zod.
