MongrelDB is our commercial, closed-source database. This week it shipped eight new language clients: Go, Java/Kotlin, C#/.NET, Ruby, Swift, Zig, D, and Nim. The total language-client count is now twelve.
Rust, TypeScript, and Python are the in-process native bindings, with no daemon and no serialization overhead. The other nine (PHP, shipped earlier this month, plus the eight new today) are pure-language HTTP clients against a running mongreldb-server.
The split is a design decision, not a fallback.
Why not native for everything?
Rust, TypeScript / Node, and Python are well-trodden ground for native bindings: PyO3, NAPI, and cargo give you a clean path from the Rust core to a published wheel or npm tarball with predictable CI. The other nine are not in that category.
- Ruby and PHP still ship extension tooling that expects a C compiler and a Makefile. Native extensions work, but every supported platform is another build matrix.
- Swift, Zig, D, and Nim have real C FFI stories, but each brings a toolchain or platform story that is rougher on the long tail of platforms.
- Java and C# could have native JNI or P/Invoke bindings. The cost is another moving part in an enterprise build pipeline that has earned the right to be dull. Pure-language HTTP clients keep the install to one Maven or NuGet package.
The cost of native bindings for all of them was real engineering hours, a longer release cycle, and a permanent tax on whoever installs a client. Pure-language HTTP against mongreldb-server is a worse solution for latency. It is a better solution for shipping and maintenance.
What we lose
The sub-millisecond, in-process write path of the native bindings does not translate. A network round-trip is a round-trip; the HTTP clients sit in the low-millisecond range, dominated by serialization and TCP, not the database. If you are writing latency-critical Python or TypeScript / Node code, use the native bindings.
For Ruby, PHP, Java, C#, and the rest, this rarely matters. The unit of work in those stacks is rarely a single-row write. ORM flushes, batch inserts, and HTTP request handlers all amortize one round-trip over many rows.
What the C ABI enables
The eight we shipped today use HTTP. That is not the whole plan.
The newest crate in the repository, mongreldb-ffi, exposes a stable C ABI over the engine core. It is the on-ramp for native bindings in any language with a C FFI. We will land more languages on top of it when the engineering case is clear. The HTTP clients we shipped this week are the immediate answer; the C ABI is the durable one.
Where to find them
All twelve clients live under the visorcraft GitHub organization. Install for the eight new:
| Language | Install |
|---|---|
| Go | go get github.com/visorcraft/mongreldb-go |
| Java / Kotlin | Maven / Gradle: com.visorcraft:mongreldb |
| C# / .NET | dotnet add package Visorcraft.MongrelDB |
| Ruby | gem install mongreldb |
| Swift | SwiftPM: https://github.com/visorcraft/MongrelDB-Swift |
| Zig | zig fetch from the repo |
| D | dub add mongreldb |
| Nim | nimble install mongreldb |
Wire-format and protocol details are in the docs. The PHP, Rust, Python, and TypeScript clients live under the visorcraft GitHub organization.
If a language you want is missing, file an issue. The C ABI makes the answer shorter than it used to be.