Kolmos is a cloud database engine built for PostgreSQL, MySQL, and MongoDB workloads. It combines self-compressing storage, columnar architecture, and multi-wire compatibility to reduce database storage and cloud infrastructure costs.

Which database wire protocols does Kolmos support?

Kolmos natively supports PostgreSQL (port 5432), MySQL (port 3306), and MongoDB (port 27017) wire protocols. Standard drivers, ORMs (Prisma, Drizzle, SQLAlchemy, Hibernate), and database clients connect seamlessly with zero application code changes.

How does Kolmos reduce cloud database storage costs?

Kolmos uses an autonomous Explanation Ladder that mines Minimum Description Length (MDL) formulas and prototype clusters to compress data 1.66×–2.12× smaller than Parquet-zstd. It stores files directly on Cloudflare R2 object storage ($0.015/GB/mo) with zero data egress fees, cutting overall cloud database storage bills by 10× to 40×.

Is Kolmos data recovery 100% lossless?

Yes. Kolmos guarantees 100% mathematical fidelity via Invariant #1: decode(encode(x)) == x across all SQL and BSON data types. Every row decodes bit-perfectly with zero precision drift.

How does Kolmos execute fast analytical queries on cloud object storage?

Kolmos embeds min/max statistics and Bloom filters into segment headers. Using Apache DataFusion vectorized execution and predicate pushdown, the engine prunes irrelevant segments and streams zero-copy Apache Arrow memory buffers without downloading unneeded data.

What prevents vendor lock-in with Kolmos storage formats?

Every Kolmos segment footer pins an open, self-contained WASM decoder covenant executed in an isolated Wasmtime sandbox. This guarantees your database files remain readable perpetually decades later without requiring proprietary server runtimes.

Docs/Operations & Optimization

Docker, Compose & Kubernetes

Deploying KOLMOS with the official Dockerfile, docker-compose, and Kubernetes manifests.

Last Updated: August 2026

1. Docker Image

The official `Dockerfile` is a two-stage build — a pinned Rust builder stage compiling `kolmos-cli` with the `s3` feature, and a slim `debian:bookworm-slim` runtime stage. The container runs as a non-root `kolmos` user, exposes `/data` as a volume, and defaults to `kolmos --root /data serve --host 0.0.0.0` on port 5432. Note the shipped image builds with S3 support but without the Postgres/MySQL/Mongo *ingest* connectors — those are for batch-loading external databases, separate from the wire-protocol servers.

bashKOLMOS Reference

docker run -d \
  -p 5432:5432 -p 3306:3306 -p 27017:27017 \
  -v ./data:/data \
  -e KOLMOS_SERVE_PASSWORD=my-secret-password \
  kolmos/kolmos:latest \
  --root /data serve --host 0.0.0.0 --mysql-port 3306 --mongo-port 27017

2. docker-compose

The repo's `docker-compose.yml` starts just the `kolmos` service by default (local-filesystem storage), reading secrets like `KOLMOS_SERVE_PASSWORD` from a git-ignored `.env` file. Run with the `dev` profile to additionally spin up a MinIO + `minio-init` pair, giving you a real S3-compatible target for testing cold-storage offload or backups without touching a cloud account.

bashKOLMOS Reference

# Local-fs only:
docker compose up

# With a local MinIO S3 endpoint for testing R2/S3 features:
docker compose --profile dev up

3. Kubernetes

There's no packaged Helm chart — `docs/deployment.md` in the repo ships plain YAML examples instead: a `Deployment`/`Service` pair for running replicas behind a load balancer (see the High Availability guide for the readiness-probe wiring against `/healthz`), and a `CronJob` for scheduled backups. Copy and adapt these directly rather than expecting `helm install`.

4. What's Intentionally Not Provided

- No systemd unit file — if you're running on bare metal, write your own service unit around the `kolmos` binary. - No Helm chart — use the plain manifests in `docs/deployment.md` as a starting point. - No install script — deployment is Docker image or self-built binary via `cargo build --release -p kolmos-cli`. - No CI-published container registry — this is a deliberate v1 decision to keep image provenance local-build-only; build and push your own image to your registry as part of your pipeline.

← Previous

Observability & Monitoring

CLI Reference