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 none of them needs the native engine - each talks HTTP over its own language stack.
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 ship with every release - six platform targets for the C-ABI archives, five in the JNI fat JAR.
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 addon 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. The pure-TypeScript @visorcraft/mongreldb-kit layer (schema DSL, query builder, migrations) sits on top of it. The published addon ships prebuilt binaries for Linux x64/arm64 only; other platforms use the daemon/HTTP client or build from source.
npm install @visorcraft/mongreldbPython 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. PyPI ships compiled wheels for CPython 3.10 and 3.11; other interpreters can use the HTTP client against the daemon.
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, published on Maven Central as a fat JAR with five platform natives bundled (Linux x64/arm64, macOS x64/arm64, Windows x64). The NativeDB class runs SQL, migrations, and queries in-process; the HTTP MongrelDB class covers the daemon path.
com.visorcraft:mongreldb-jni (Maven Central)Kotlin 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-local (GitHub checkout)Dart tools and services can use the HTTP client to keep MongrelDB behind a stable daemon process.
dart pub add mongreldb --git-url https://github.com/visorcraft/mongreldb-dartElixir applications can keep BEAM processes focused on application work while MongrelDB runs behind HTTP as the local database service.
{:mongreldb, github: "visorcraft/mongreldb-elixir"}Erlang 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.
build from source (GitHub)Use 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 a standard-library sockets client for analytics and research code that wants MongrelDB features without hosting the engine in-process.
] add https://github.com/visorcraft/mongreldb-juliaKotlin/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 LuaSocket-backed client for scripts, tools, and embedded runtimes that should avoid linking the storage engine directly.
luarocks make (rockspec in GitHub repo)Mojo reaches the daemon through an http-backed client, fitting AI and systems code that wants MongrelDB access without native storage linkage.
mojo run -I src (from source)Nim 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 https://github.com/visorcraft/mongreldb-nimObjective-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.
copy lib/MongrelDB.pm (from GitHub)Bring 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 ./src/MongrelDB.psd1R users reach MongrelDB through a libcurl-backed client for local analytics, retrieval workflows, and repeatable data tooling.
R CMD INSTALL . (GitHub checkout)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 'mongreldb', git: 'https://github.com/visorcraft/mongreldb-ruby'Use 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 (the C-ABI archives cover six platform targets, the JNI fat JAR five).
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. Prebuilt binaries ship for Linux x64/arm64; other platforms build from source or use RemoteDatabase over HTTP.
npm install @visorcraft/mongreldbnpm install @visorcraft/mongreldb-kitPython can use MongrelDB without operating a separate database server, which fits agent memory, ETL, local analytics, embedding experiments, and fast test fixtures. Wheels are published for CPython 3.10/3.11; other versions use the daemon over HTTP.
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 five platform natives bundled (Linux x64/arm64, macOS x64/arm64, Windows x64). Each NativeDB class runs SQL, migrations, and queries in-process; the pure-JVM HTTP client covers the daemon path.
com.visorcraft:mongreldb-jni (Maven Central)The 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.
-- Scored hybrid retrieval - runnable over the daemon.
SELECT id, title, fused_score
FROM hybrid_search_scored(
'docs',
'{"must":[
{"bitmap_eq":{"column":"tenant","value":"acme"}},
{"range":{"column":"created_at","lo":1767225600,"hi":1798761600}},
{"fm_contains":{"column":"body","pattern":"needle"}}],
"retrievers":[
{"name":"dense","ann":{"column":"embedding","query":[0.12,0.31],"k":50}}],
"limit":20}',
'id,title')
ORDER BY fused_score DESC;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.
Transactions are ACID across tables, with ReadCommitted, RepeatableRead, and Serializable isolation - the serializable level adds SSI-style certification at commit - plus savepoints and idempotent commits that make retries safe after a crash.
Beyond HTTP/JSON, a native gRPC protocol carries Protobuf control messages and Arrow IPC batches over multiplexed HTTP/2 - TLS 1.3 only, with optional mTLS, SCRAM-SHA-256, and OIDC/JWKS auth - served by a pooled Rust NativeClient with streaming, cancellation, and prepared statements. A MySQL wire listener (TLS 1.3, caching_sha2_password) lets existing MySQL clients run queries, transactions, and prepared statements, and an online migration tool moves MySQL databases in with a consistent snapshot, binlog catch-up, resumable checkpoints, and count/checksum validation before a locked cutover.
Tier 2 packages are language-native HTTP clients with no native engine dependency. 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. Users and roles are managed with GRANT/REVOKE SQL DDL, the native listener adds SCRAM-SHA-256 and OIDC/JWKS, Vault Transit can act as the key-management service, and a bounded audit log records security events. Storage-layer credential enforcement can make authenticated principals mandatory for opens and operations.
Single-node is the default, but two optional modes scale beyond it: Raft-replicated HA (openraft consensus, RPO-0 quorum writes, five read-consistency levels from linearizable to eventual) and a tablet-sharded cluster (Hash/Range/Tenant/TimeRange partitioning, tablet split/merge, distributed two-phase-commit transactions, mTLS cluster transport).
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 engine is exercised with deterministic simulation and fault-injection harnesses, and every official language client must pass a 14-operation live wire-compatibility conformance matrix against a running daemon in CI.
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.
Six secondary index kinds - bitmap, PGM learned range, FM-index, HNSW ANN, learned-sparse, and MinHash - resolve into a shared RowId space, allowing the engine to combine different access patterns before it decodes rows. The primary-key point-lookup path (in-memory HOT, on-disk learned PGM) is implicit on top of that.
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 version GC. Time-travel queries (AS OF EPOCH), timestamp-column TTL policies, and backup with point-in-time recovery round out the operational surface.
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_columns, 1M-row scaleBenchmark numbers are from the current BENCHMARKS.md (v0.64-era release builds on one Linux x86-64 machine; 1M-row and write-path measurements collected 2026-07-14/15, exact-SHA REM-J measurements 2026-07-27). The same file records 1,000 concurrent HTTP sessions against the daemon with 0 failed requests and 259 MB peak RSS. These are engineering measurements from one machine, not cross-machine guarantees - 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.Nativecom.visorcraft:mongreldb-jni (Maven Central)Gradle + libmongreldb_jnipip install mongreldb-kitcargo add mongreldb-coresbt + libmongreldb_jninpm install @visorcraft/mongreldbdeps.edn / Leiningenshards add mongreldbdub add-local (GitHub checkout)dart pub add mongreldb --git-url https://github.com/visorcraft/mongreldb-dart{:mongreldb, github: "visorcraft/mongreldb-elixir"}rebar3dotnet add referencefpmbuild from source (GitHub)go get github.com/visorcraft/mongreldb-go] add https://github.com/visorcraft/mongreldb-julialuarocks make (rockspec in GitHub repo)mojo run -I src (from source)nimble install https://github.com/visorcraft/mongreldb-nimCMake (links Foundation)odin buildcopy lib/MongrelDB.pm (from GitHub)composer require visorcraft/mongreldb-phpImport-Module ./src/MongrelDB.psd1R CMD INSTALL . (GitHub checkout)gem 'mongreldb', git: 'https://github.com/visorcraft/mongreldb-ruby'Swift 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.