The most expensive part of a database was never the license, it was the operational surface you agreed to live with, and the industry spent about fifteen years making that surface bigger while calling it progress. Running Elasticsearch meant running a JVM, which meant heap sizing, garbage-collector tuning, and a support matrix that tied your database version to your Java version; running Cassandra was the same story with different flags; Kafka added ZooKeeper on top for years, so a single logical service was three processes deep before you wrote the first record. Docker showed up in the middle of that era and got treated as the fix, but a container does not remove the runtime, it just moves the runtime inside an image that somebody still has to build, scan for CVEs, rebuild when the base image patches, and keep warm in a registry. The shape a small team actually wants is the one MySQL had in 2003, one package, one process, one config file, and a service manager that already knows what to do with it.
That is the shape MongrelDB is built to, and the reason is not nostalgia, it is arithmetic, because every runtime, sidecar, and orchestrator you add to a deployment is a recurring tax on a team that is not going to hire a platform engineer to run a database. The pitch of this post is simple: one Rust workspace compiles to one server binary per platform and one shared library per ABI, there is no JVM and no interpreter in the middle, Docker is an option rather than a requirement, and the parts of the codebase you are not running are not merely disabled in config, they are not in the binary at all.
What the artifact actually is
The server build is one cargo invocation, cargo build --release -p mongreldb-server --bin mongreldb-server, and what falls out is a single executable that speaks HTTP, serves SQL and the typed Kit API that the language SDKs talk to, manages its own WAL and compaction, and needs nothing on the host beyond a directory to own. The feature seam is compile-time rather than runtime, which is the part worth slowing down for: the cluster data plane, the native gRPC listener, the OIDC integration, the Vault KMS client, and the remote-embedding sidecar client all sit behind cargo features, and the default feature set is the standalone HTTP-only build, so a plain build does not carry that code, does not link those dependencies, and cannot be tricked into loading them. That distinction matters more than it reads, because “turned off in the config file” still means the code shipped, still means its dependencies appear in your vulnerability scan, and still means the next operator can turn it back on by accident; code that was never compiled has no config surface and no CVEs, and it costs nothing to audit. The prebuilt release binaries are the maximal case rather than the minimal one, since the release workflow compiles them with the full feature set so that one artifact covers every deployment, and the team that wants the lean build gets it with the same single cargo command minus the feature flags.
The release page carries the platform matrix directly: mongreldb-server for Linux x64 and arm64 against glibc, a fully static musl build for Linux x64, a profile-guided-optimized Linux x64 build, and macOS arm64 plus a universal2 binary, each one a bare file you download, chmod, and run. The PGO artifact deserves one clause of explanation, because profile-guided optimization means the compiler was fed a profile collected from the project’s own benchmark suite and rebuilt against it, and it ships as a separate asset for the boring reason that the profile can only be collected on the native architecture, so the musl, arm64, and macOS legs keep the plain build. The musl build is the one worth pausing on, because static linking is what makes the artifact honest: there is no glibc version to match, no libssl dance, no base image at all, so the same file runs on Alpine, on a bare-metal box from 2019, or inside a scratch container if you insist on Docker, and the deployment story shrinks to copy one file and point a service manager at it.
curl -L -o mongreldb-server \
https://github.com/visorcraft/MongrelDB/releases/latest/download/mongreldb-server-linux-x64-musl
chmod +x mongreldb-server
./mongreldb-server /data/mongreldb 8453
Three commands, and the middle one is a formality. There is a Dockerfile in the repo for teams that already live in containers, and its runtime stage is debian:bookworm-slim with one binary copied in, but the container is packaging, not a dependency, and the entrypoint is the same two arguments you would type by hand.
The embedded side is the same artifact
The server is only half the story, because the same engine also ships as libmongreldb.so, .dylib, and .dll, built from the FFI crate as both a cdylib and a staticlib, distributed per platform as a tarball with the shared library and the single C header that describes it. Every Tier-1 language binding sits on that one artifact, which means the PHP client, the Node NAPI addon, and the rest of the binding fleet are all thin shims over the same compiled core rather than thirty separate ports of the engine, and a fix in the core reaches every language on the next build. For an embedded deploy there is no process at all, no port, and no service manager, because the database is a link step and an open call, which is the deal SQLite made thirty years ago and the reason it ended up in every phone on the planet. An edge device, a CLI tool, a test suite that wants a real engine instead of a mock, a desktop app that syncs when it feels like it; these are the workloads where “apt install a server and keep it alive” was always the wrong answer, and they are exactly the workloads a linkable artifact serves without ceremony.
The economics compound quietly from there. One artifact per platform means one thing to cache in CI, one thing to checksum in a supply-chain manifest, one thing to pin in a deploy script, and one thing to roll back when a release misbehaves, and the rollback is a file copy rather than a helm chart archaeology session. It also means the floor for trying the engine is a download and a double-click, which is a genuinely different adoption funnel than “first, install a container runtime.”
What it costs
The honesty section, because the single-binary story has real edges and pretending otherwise is how vendor blogs lose the room. The first edge is size: the server binaries run from roughly 200 to 220 MB depending on the target, because the binary carries a DataFusion SQL layer, the full secondary-index set (bitmap, learned-range, FM-index, ANN, sparse, and MinHash), the tokio and axum runtime, and the encryption stack, so this is not SQLite’s svelte two-megabyte footprint and it never will be. For a server daemon that is a rounding error against the disk it manages, but if your mental model of “single binary” is a five-megabyte static Go CLI, recalibrate; the comparison that matters is against a JVM plus a heap plus an image, and against that baseline the artifact is still one file you can email.
The second edge is that single binary means single node by default, and there is no invisible clustering hiding behind a flag, because in a default-feature build the flag literally does not exist. The redundancy story the engine ships is warm standby rather than automatic failover, WAL streaming to a ReplicationFollower that applies committed records to a local copy for read scaling and a ready-to-promote replica, and it is honest warm standby in the sense that promotion is your runbook, not the engine’s election. Consensus-based clustering lives behind the cluster feature, and turning it on means accepting the operational surface that comes with it, which is the correct trade, because a team that has not outgrown one node should not be paying the complexity bill for Raft. The third edge is build time, since a Rust workspace of this size compiles in minutes rather than seconds from a cold cache, and that is precisely why the prebuilt archives exist; building from source is for people hacking on the engine, and everyone else should be downloading the artifact.
The last edge is the flip side of the compile-time feature story, because a lean self-built binary cannot grow the enterprise features in the field without a rebuild and a redeploy. That is a deliberate choice rather than an oversight, since the alternative is shipping only the maximal binary where every integration lives behind a config key, and we have all maintained that binary, the one where the config file is a compliance document and half the linked dependencies exist to serve code paths nobody at your company will ever execute.
The modern equivalent
We ran databases from one package in 2003 because the operational surface was the bill, then we spent a decade and a half pretending a JVM, a container runtime, and an orchestrator were free, and the bill came due in platform teams and on-call rotations. The single binary is the same old idea with a better engine inside: the artifact is the deployment, the features you did not compile are not your problem, and the day you genuinely need a cluster is the day you build the binary that has one, not a day sooner.