# Officially supported MongoDB Driver **URL:** \ **Category:** Pitches\ **Created:** [October 30, 2019, 4:38pm UTC](https://forums.swift.org/t/officially-supported-mongodb-driver/30324 "2019-10-30T16:38:29Z")\ **Posts on this page:** 1\ **Showing post:** 10
**Author:** ![kmahar](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kmahar/32/5380_2.png) [@kmahar](https://forums.swift.org/u/kmahar)\ **Post date:** [November 7, 2019, 4:39pm UTC](https://forums.swift.org/t/officially-supported-mongodb-driver/30324/10 "2019-11-07T16:39:13Z")
Thanks for the link, @valeriomazzeo! > [@IanPartridge](#): > > It would also be great to hear your thoughts on connection pooling design and whether there is any potential to reuse/share code in this area between MongoSwift and other database drivers. I think there is definitely potential for this! Earlier this year our team published a [connection monitoring and pooling](https://github.com/mongodb/specifications/blob/master/source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.rst) specification. This defines a standardized approach for how all MongoDB drivers should pool connections. (The monitoring bit involves publishing events in some language-specific manner when e.g. a connection is checked out or back into a pool.) As libmongoc doesn't comply with this specification right now, we don't either, though we've mostly retrofitted the desired pool API atop their version of pooling. When we get to writing the SwiftNIO-based implementation, we'll want it to fully comply with this spec. We'd be very interested in taking part in any discussions on this going forward and seeing where pooling needs overlap and differ across drivers and whether it makes sense to share any/all of a pooling implementation. > [@Joannis\_Orlandos](#): > > I'd be open to a collaboration if it would be a Swift driver (like MongoKitten). I wouldn't be interested in collaborating on a C based driver. I've got a load of feedback on API design & internals design. As I noted in the pitch above, the pure Swift implementation won't be coming for a while longer, and when it does it will occur in pieces rather than being a complete rewrite all at once. Along the way, we'd certainly like to collaborate with you and the rest of the community on components that are useful to DB drivers and the server-side ecosystem as a whole, e.g. the DNS client you pitched a while back, connection pooling, etc. On the driver code itself, in general the official MongoDB drivers are owned by our team, but welcome collaboration via pull requests, GitHub issues, JIRA, etc. > [@Joannis\_Orlandos](#): > > I like the new API design, although I have my concerns with the enum for BSON Values. MongoDB tends to add new types to BSON when needed. [Decimal128](https://bsonspec.org/spec.html) being a recent example of this. That's why I think an enum is a burden to the driver and user. We considered this, however, adding new BSON types is a pretty rare occurrence (e.g. the last addition Decimal128 was 3.5 years ago). We felt that the benefits of the new approach (being able to exhaustively switch on BSON types, less verbose construction of document literals, being able to fully hide implementation details that were previously on the public protocol, removal of "placeholder" structs containing no data such as `BSONNull`) far outweighed the potential risk of some potential breaking change. --- _[View the full topic](https://forums.swift.org/t/officially-supported-mongodb-driver/30324)._