Embedded when latency matters. HTTP when portability wins.
MongrelDB supports 35 languages without changing the engine underneath it. Nine run the engine in-process through native bindings - Rust, TypeScript, Python, C, C++, C#/.NET, Java, Kotlin, and Scala - and 26 more connect through daemon-backed HTTP clients, from Clojure and Crystal to V and Zig.
The client strategy is deliberately simple: keep the engine in-process for the languages where native bindings exist, and use the daemon when you want broad language coverage with no native extension requirement.
Rust, TypeScript, Python, C, C++, C#/.NET, Java, Kotlin, and Scala run the engine in-process. That preserves MongrelDB’s low-latency write path and avoids paying a network round trip just to query local data.
Twenty-six languages - from Clojure, Crystal, D, Dart, Elixir, and Erlang through Go, Julia, Kotlin/Native, Lua, Nim, Perl, PHP, R, Ruby, Swift, Tcl, V, and Zig - connect to a running mongreldb-server. The clients stay easy to install because they do not need native dependencies.
The mongreldb-ffi crate exposes a C interface over the engine core (SQL, typed queries, transactions, migrations), mongreldb-kit-ffi wraps the Kit layer, and mongreldb-jni is a JNI shim for Java, Kotlin, and Scala. Prebuilt libraries for six platform targets ship with every release.
Every client should make the same strengths approachable: durable local writes, columnar reads, hybrid indexes, DataFusion SQL, Arrow-friendly data movement, encryption, and daemon-backed multi-process access when needed.
Use these when you want the engine inside your application process and care about avoiding an extra service boundary.
Direct crate access for applications that want the core engine close to the code. The best fit for systems work, embedded products, test harnesses, and anything that benefits from Rust-native ownership of the data path.
cargo add mongreldb-coreThe native NAPI path follows the better-sqlite3 model: in-process, no HTTP hop, typed object/method calls, DataFusion SQL, Arrow IPC results, and lossless BigInt row ids, counts, and epochs.
npm install @visorcraft/mongreldb-kitPython gets the embedded engine through PyO3, making it a natural fit for local analytics, AI retrieval experiments, data prep scripts, and tools that need a real database without operating another service.
pip install mongreldb-kitC projects embed the engine in-process through the C ABI, linking a prebuilt libmongreldb and libmongreldb_kit for SQL execution, typed queries, transactions, and migrations. A libcurl-backed HTTP client is included for daemon deployments.
CMake (links libcurl) or prebuilt libmongreldbA header-only C++ client embeds the engine through the same C ABI, with prebuilt libmongreldb and libmongreldb_kit for native SQL, queries, and migrations. The header-only libcurl client covers the daemon path.
CMake (header-only, links libcurl) or prebuilt libmongreldbThe Visorcraft.MongrelDB.Native package embeds the engine in-process through P/Invoke over the prebuilt native libraries, bundling runtimes/<rid>/native/ for six platform targets. The HTTP Visorcraft.MongrelDB package stays pure-managed for daemon deployments.
dotnet add package Visorcraft.MongrelDB.NativeJava embeds the engine through the mongreldb-jni shim, distributed as a fat JAR with all six platform natives bundled. The NativeDB class runs SQL, migrations, and queries in-process; the HTTP MongrelDB class covers the daemon path.
Maven/Gradle + libmongreldb_jniKotlin embeds the engine through the same mongreldb-jni shim, with a NativeDB surface that mirrors the Java class for SQL, migrations, and queries. The HTTP client keeps daemon deployments idiomatic.
Gradle + libmongreldb_jniScala embeds the engine through the mongreldb-jni shim alongside Java and Kotlin, with a NativeDB surface for in-process SQL, migrations, and queries. The pure-JVM HTTP client covers the daemon path.
sbt + libmongreldb_jniUse these when you want a language-native package that talks to mongreldb-server without compiling native bindings.
Clojure apps reach the daemon through a small clj-http-backed client, keeping the database process separate from JVM application code.
deps.edn / LeiningenCrystal gets a pure-language HTTP::Client path to the daemon for services and tools that want MongrelDB without embedding the Rust engine.
shards add mongreldbD applications can use the HTTP client to reach a warm MongrelDB daemon while avoiding native storage linkage in the application runtime.
dub add mongreldbDart tools and services can use the HTTP client to keep MongrelDB behind a stable daemon process.
dart pub add mongreldbElixir applications can keep BEAM processes focused on application work while MongrelDB runs behind HTTP as the local database service.
{:mongreldb, "~> 0.1"} in mix.exsErlang gets an httpc-backed client for BEAM releases that want MongrelDB behind a daemon boundary, keeping the storage engine out of the OTP runtime.
rebar3F# reaches the daemon through an HttpClient-backed client, pairing cleanly with functional .NET services and scripts.
dotnet add referenceFortran talks to the daemon over a curl-backed client, fitting scientific and HPC workflows that want a real database without embedding native storage.
fpmGleam gets a gleam_http client for the BEAM-native crowd that wants a typed, pure-language path to a warm daemon.
gleam add mongreldbUse Go for services, CLIs, and worker fleets while talking to the daemon over a pure-language net/http client. Good for deployment targets where native database bindings add friction.
go get github.com/visorcraft/mongreldb-goJulia gets daemon-backed access through HTTP.jl for analytics and research code that wants MongrelDB features without hosting the engine in-process.
] add MongrelDBKotlin/Native compiles to native machine code with no JVM, talking to the daemon through a ktor-client-curl HTTP client for cross-platform tools and services.
Gradle (compiles to native, no JVM)Lua gets a small lua-curl-backed client for scripts, tools, and embedded runtimes that should avoid linking the storage engine directly.
luarocks install mongreldbMojo reaches the daemon through an http-backed client, fitting AI and systems code that wants MongrelDB access without native storage linkage.
magic add mongreldbNim gets a pure-language path to the daemon, useful for command-line tools, services, and experiments that need MongrelDB access without embedding the Rust engine.
nimble install mongreldbObjective-C apps reach the daemon through an NSURLSession-backed client for macOS and iOS tools that want a separately managed database service.
CMake (links Foundation)Odin talks to the daemon over a pure-language net/http client, fitting data-oriented tools that want MongrelDB without native bindings.
odin buildPerl scripts and services use an HTTP::Tiny-backed client for SQL, query routes, and operational access without native storage linkage.
cpanm MongrelDBBring MongrelDB to PHP web applications and workers through a cURL-backed client. The package stays simple to install while the server keeps the database process warm.
composer require visorcraft/mongreldb-phpPowerShell reaches the daemon through Invoke-RestMethod, fitting automation, gluing, and ops tooling that wants a real database behind a module.
Import-Module mongreldbR users reach MongrelDB through a libcurl-backed client for local analytics, retrieval workflows, and repeatable data tooling.
install.packages("mongreldb")Give Ruby apps access to MongrelDB’s SQL, native query routes, and daemon-managed warm state through a net/http client without requiring native database bindings inside the application process.
gem install mongreldbUse Swift Package Manager to connect Swift tools and applications to a MongrelDB daemon over URLSession, keeping the database engine as a separately managed local service.
Swift Package ManagerTcl scripts reach the daemon through the built-in http package, fitting automation, tooling, and legacy glue that wants a real database behind a warm process.
package require mongreldbV talks to the daemon over a pure-language net.http client, fitting fast-compiling tools and services that want MongrelDB without native bindings.
v installFor Zig projects, a std.http-backed client keeps integration straightforward while still exposing the same daemon-backed database surface.
zig fetchThe nine embedded clients are for applications that should feel like they are using a local library, not a remote service. That matters when your strengths are sub-millisecond writes, RowId-level set intersections, and Arrow batches returned directly to the caller. Rust, TypeScript, and Python bind through their own native toolchains; C, C++, C#/.NET, Java, Kotlin, and Scala bind through three shipping native shims with prebuilt libraries for six platform targets.
Rust gets direct access to mongreldb-core, the storage engine crates, examples, and testable internals. Use it for embedded products, local-first backends, and storage-aware application code.
cargo add mongreldb-coreThe NAPI addon exposes typed object/method APIs, SQL execution, Arrow IPC bytes, BigInt row identifiers, promise variants, and RemoteDatabase for daemon-backed multi-process use.
npm install @visorcraft/mongreldb-kitcd crates/mongreldb-node && npm install && npm run buildPython can use MongrelDB without operating a separate database server, which fits agent memory, ETL, local analytics, embedding experiments, and fast test fixtures.
pip install mongreldb-kitThe mongreldb-ffi and mongreldb-kit-ffi crates ship as libmongreldb and libmongreldb_kit for six platform targets, with C headers for SQL execution, typed queries, transactions, and the full migration runner. The C and C++ clients bundle both headers for direct native embedding.
CMake + prebuilt libmongreldb, libmongreldb_kitThe native package embeds the engine through P/Invoke over the prebuilt libraries, bundling runtimes/<rid>/native/ and resolving them via NativeLibrary.SetDllImportResolver. The pure-managed Visorcraft.MongrelDB package stays HTTP-only.
dotnet add package Visorcraft.MongrelDB.NativeThe mongreldb-jni shim powers all three JVM languages, distributed as a fat JAR with all six platform natives bundled. Each NativeDB class runs SQL, migrations, and queries in-process; the pure-JVM HTTP client covers the daemon path.
Maven/Gradle/sbt + libmongreldb_jniThe useful part is not just language coverage. It is that dense vector ANN, substring matching, bitmap equality, range filters, null checks, and byte-prefix conditions can compose into one RowId-space intersection before rows and columns are decoded.
-- Same data, multiple access paths.
SELECT rowid, title, score
FROM docs
WHERE tenant = 'acme'
AND created_at BETWEEN TIMESTAMP '2026-01-01' AND TIMESTAMP '2026-12-31'
AND body LIKE '%needle%'
AND ann_search(embedding, '[0.12, 0.31, ...]', 50)
ORDER BY score DESC
LIMIT 20;The HTTP tier is not a weaker engine. It is a deployment boundary. Run mongreldb-server when multiple processes or languages need the same database directory, cache, auth boundary, replication stream, and change notifications.
The daemon keeps a multi-table Database warm and exposes SQL, native query routes, and typed Kit endpoints such as schema, transaction, query, and create-table routes.
Tier 2 packages are pure-language HTTP clients. That means the application can stay idiomatic in Clojure, Crystal, D, Dart, Elixir, Erlang, F#, Fortran, Gleam, Go, Julia, Kotlin/Native, Lua, Mojo, Nim, Objective-C, Odin, Perl, PHP, PowerShell, R, Ruby, Swift, Tcl, V, or Zig while the daemon owns the engine process.
The daemon supports bearer token auth, HTTP Basic auth users, connection limits, and page-level encryption passphrases. Storage-layer credential enforcement can make authenticated principals mandatory for opens and operations.
Replication streams committed WAL records to followers, while change data capture uses SQL NOTIFY/LISTEN and an SSE events endpoint for real-time notifications.
The integration model changes by runtime, but the underlying capabilities stay consistent: hybrid access paths, durable writes, columnar scans, DataFusion SQL, Arrow results, encryption, and operational tooling.
Eight index families resolve into a shared RowId space, allowing the engine to combine different access patterns before it decodes rows.
A WAL with group commit feeds a Bε-tree memtable, then flushes to immutable .sr PAX-columnar sorted runs with MVCC snapshots.
DataFusion SQL gives applications joins, recursive CTEs, windows, materialized views, multi-statement execution, and FTS ranking without leaving the engine.
AES-256-GCM protects pages, WAL frames, result cache entries, and index checkpoints. Encrypted stats envelopes let encrypted columns prune like plaintext ones.
MongrelDB includes daemon mode, connection pooling, auth, replication, change data capture, schema evolution, compaction, check, doctor, and cleanup paths.
MongrelDB is dual-licensed under MIT or Apache-2.0, built in Rust, and organized into focused crates for storage, SQL, server, client, the C ABI, the Kit C ABI, the JNI shim, Node bindings, and benchmarks.
bulk_load_columnsBenchmark numbers are from the 1M-row dev-sandbox profile. Keep them paired with the benchmark methodology and update them when the benchmark suite changes.
Start with the package for your runtime, then choose embedded or daemon-backed deployment based on how close the engine should sit to your application.
CMake or prebuilt libmongreldbCMake or prebuilt libmongreldbdotnet add package Visorcraft.MongrelDB.NativeMaven/Gradle + libmongreldb_jniGradle + libmongreldb_jnipip install mongreldb-kitcargo add mongreldb-coresbt + libmongreldb_jninpm install @visorcraft/mongreldb-kitdeps.edn / Leiningenshards add mongreldbdub add mongreldbdart pub add mongreldb{:mongreldb, "~> 0.1"} in mix.exsrebar3dotnet add referencefpmgleam add mongreldbgo get github.com/visorcraft/mongreldb-go] add MongrelDBluarocks install mongreldbmagic add mongreldbnimble install mongreldbCMake (links Foundation)odin buildcpanm MongrelDBcomposer require visorcraft/mongreldb-phpImport-Module mongreldbinstall.packages("mongreldb")gem install mongreldbSwift Package Managerpackage require mongreldbv installzig fetch
Embed MongrelDB where latency matters, run the daemon where language reach and multi-process access matter, and keep the same storage model underneath both.