vibe-mongodriver 1.0.1: MongoDB 8 driver for D

[Bogdan Szabo]

On Friday, 14 August 2026 at 12:37:28 UTC, Sönke Ludwig wrote:
> Am 28.07.26 um 10:11 schrieb Bogdan Szabo:
>> I have released vibe-mongodriver 1.0.1, a MongoDB client for D 
>> supporting servers up to 8.0. It started as MongoDB work 
>> inside a fork of vibe.d and outgrew it. I opened pull requests 
>> upstream but have not had feedback on them, and a rewrite 
>> spanning this many commits was unlikely to land as a single 
>> change anyway. Missing support for recent MongoDB versions is 
>> a common reason to pass on vibe.d, so rather than leave the 
>> work sitting in a private fork, I am releasing it as a 
>> separate package.
>> 
>> 
>> Beyond vibe-d:mongodb, it adds Server Discovery and 
>> Monitoring, replica set and sharded topologies, load-balanced 
>> mode, mongodb+srv seedlists, transactions with pooled 
>> sessions, causal consistency, retryable writes, change 
>> streams, GridFS, client-side field-level encryption, MongoDB 8 
>> bulkWrite, wire compression, and SCRAM-SHA-256 and X.509 
>> authentication. CI runs the integration suite against MongoDB 
>> 3.6 through 8.0. The API is unchanged, so migration is one sed 
>> (s/vibe\.db\.mongo\b/ vibe.db.mongodriver/g), and since only 
>> module names differ, both packages can link into the same 
>> binary, letting a large codebase migrate incrementally.
>> 
>> MIT licensed, original vibe.d history preserved.
>> 
>> https://code.dlang.org/packages/vibe-mongodriver
>> https://gitlab.com/GISCollective/vibe-mongodriver
>
> I'm sorry that the reviews kind of starved. I really tried to 
> allocate time for it, but the amount of changes is just beyond 
> what I can realistically review and I never made it to the end 
> of the largest PR. However, all the changes I've seen so far 
> were of high quality.
>
> What I'm thinking is that it might make sense to make this the 
> first version of an official standalone MongoDB driver package 
> (I had planned to move the code to a separate repository 
> anyway) - so it would keep the original package name 
> (vibe.db.mongo) and the vibe.d main package would be modified 
> to enable opting in to use the new standalone package instead 
> of the existing code in the main vibe.d repository. That way we 
> could get good real-world exposure of the new code while 
> keeping the old code available in case there are any unforeseen 
> breaking changes. Eventually, the old code could then just be 
> removed.
>
> What do you think?

Yeah, I totally get this. Same on my side; work and family take a 
lot of time, and I don't have time to focus on public 
contributions as I did in the past.

I am currently using the fork in production already, but with 
only one DB server, no shards or replicas, and it works great so 
far. Atlas and replicas are a thing for the future to fully test 
on a real prod env once I have more budget on GISCollective, but 
it worked great on my local setup anyway, even though there might 
be issues (which, if anyone finds, I will do my best to fix, 
because this lib is one of the core libs that I use).

I'm fine with making this package official; I can prepare all the 
imports and such, but I would like to be able to contribute to it 
even if it gets moved to the vibe.d organisation.

Let me know the best way to collaborate, and I'll make the 
changes.

Bogdan