I do not see third-party drivers controlled by entities whose core strategy is to draw users away from Apache Cassandra as a suitable foundation for official Apache Cassandra clients.
Some quick thoughts: – Advancing the database’s wire protocol is increasingly difficult if it requires updates to 5+ client libraries. A common core lib can help here. – I think the native wrapper approach works well for the slightly longer tail of programming languages we’d like to support. – If we do adopt a native wrapper approach, we need a sizable number of committed volunteers to maintain the core library. – There are downsides to native wrappers such as decreased profileability, language-native observability, logging integration, and app-level control of the threading model. – This raises an important question of driver strategy for the project. The project's Java, Python, C++, and Go drivers all seem very mature but have little in common. I wouldn’t be in a rush to replace any of them, unless core maintainers of these libraries agreed that it would be desirable to migrate one or more of them toward a native wrapper. – At the same time, if the maintainers of a driver wanted to pursue wrapping a memory-safe implementation - I’d also be receptive and eager to follow. – It could be interesting to prototype a Python lib implementation backed by cassandra-rs which exists today as well. – I think this proposal warrants a fleshed-out CEP. Since there’s a lot to cover, I think we need more than the body of the CASSPYTHON-8 ticket and a DISCUSS thread. Bret, thanks for starting this discussion - eager to follow. – Scott > On Feb 5, 2026, at 9:38 PM, Jon Haddad <[email protected]> wrote: > > Why reinvent the wheel? > > https://github.com/scylladb/scylla-rust-driver > > On Thu, Feb 5, 2026 at 10:57 AM Bret McGuire <[email protected] > <mailto:[email protected]>> wrote: >> I don't disagree at all Josh but I also don't view the two approaches as >> contradictory. I would certainly expect that any Rust work we did for the >> Python driver should transfer very naturally over to a Rust core when we get >> to that point. The Python driver uses a combination of C and cython for a >> fair number of things (including type serde and eval of row data). These >> are things we would need in a common Rust core and I would absolutely expect >> that any impl we come up with for these things would transfer easily. >> Perhaps more importantly I would argue this allows us to work on a Rust >> implementation incrementally; it would be nice to be able to tackle chunks >> of the core (and get them out in the wild where we can validate them with >> real-world use cases) without waiting for the whole core to be complete. >> >> This change also has significant benefits for the Python driver as it >> stands now; moving the current cython & C code into a common framework (and >> updating it) will be of considerable utility to the driver going forward. >> But this shouldn't get in the way of any effort to move to a common core. >> >> - Bret - >> >> On Thu, Feb 5, 2026 at 8:52 AM Josh McKenzie <[email protected] >> <mailto:[email protected]>> wrote: >>> From a general philosophical perspective, I think the health of our >>> ecosystem would be better served by having one core natively compiled >>> driver lib and then language ecosystem native wrappers around that core. >>> Similarly to how the Swift driver wraps the C++ driver. Lowering the amount >>> of engineering required to keep multiple language ecosystem drivers in >>> parity is a big win as the ecosystem's currently pretty fragmented. >>> >>> Using rust for the core of that given its memory safety, concurrency >>> correctness, performance, language interconnect ecosystem, and general >>> zeitgeist makes a lot of sense to me. >>> >>> On Tue, Feb 3, 2026, at 2:21 PM, Bret McGuire wrote: >>>> Greetings all! >>>> >>>> Another one that seemed worthwhile to bring to the list. I've just >>>> filed CASSPYTHON-8 <https://issues.apache.org/jira/browse/CASSPYTHON-8> to >>>> explore the idea of replacing our current C and cython code with >>>> equivalent Rust implementations. This technique is becoming more common >>>> in the Python world but there are concrete benefits for us on the Python >>>> driver team. There's some discussion about these benefits on CASSPYTHON-8. >>>> >>>> Our upcoming release (likely 3.30.0) will be intended to get an >>>> ASF-branded Python driver out into the wild so I'm not planning on >>>> tackling any work in this area then. The plan would be to start with this >>>> effort for 3.31.0. We'll start with something small, just to try out the >>>> mechanism for integrating Rust code into a Python project, and see where >>>> that takes us. >>>> >>>> Thanks! >>>> >>>> - Bret - >>>
