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/Security & Reliability

Backup & Disaster Recovery

Full and incremental backups, point-in-time restore, and scheduled backup automation.

Last Updated: August 2026

1. How Backups Work

Because KOLMOS stores data as content-addressed Parquet segments, `kolmos backup` copies the object store (segments, catalog history, and the HEAD pointer) to a destination — local path or S3/R2 URI. Re-running a backup against the same destination is effectively incremental, since content addressing means only genuinely new objects get transferred. The full commit history is retained and GC-protected, so a restore can target any commit ever made, not just a moment a backup happened to run.

2. Taking a Backup

Use `--verify` to have KOLMOS restore the backup into a scratch location immediately afterward and run the same integrity check as `kolmos verify` — worth the extra time for anything you'd actually rely on in an incident.

bashKOLMOS Reference

# Backup to local disk, with integrity verification:
kolmos --root /data/kolmos backup --dest /backups/kolmos-2026-08-31 --verify

# Backup to S3-compatible object storage (e.g. Backblaze B2, R2, MinIO):
kolmos --root /data/kolmos backup --dest s3://my-backup-bucket/kolmos \
  --s3-region auto \
  --s3-access-key-id "$B2_KEY" \
  --s3-secret-key "$B2_SECRET"

# List recorded backup checkpoints:
kolmos --root /data/kolmos backup-log --dest /backups/kolmos-2026-08-31

3. Restoring & Point-in-Time Recovery

`kolmos restore --from <path-or-s3-uri>` writes into the top-level `--root` you pass — always a fresh or empty location, since restore never overwrites live data. By default it restores to the latest state in the backup. Pass `--as-of <manifest-id>` to restore to a specific commit, or `--as-of-time <millis-since-epoch>` to restore to the newest commit at or before a given timestamp (these two flags are mutually exclusive). A `--as-of-time` target older than the oldest recorded commit fails cleanly rather than silently picking the wrong point.

bashKOLMOS Reference

# Restore the latest state into a fresh root:
kolmos --root /data/kolmos-restored restore --from /backups/kolmos-2026-08-31

# Restore to a specific commit:
kolmos --root /data/kolmos-restored restore --from /backups/kolmos-2026-08-31 \
  --as-of 01J8X9K2QYR3F7VZC6N4P5M0T1

# Point-in-time restore to "as it looked at this timestamp":
kolmos --root /data/kolmos-restored restore --from /backups/kolmos-2026-08-31 \
  --as-of-time 1756598400000

4. Scheduling Backups

KOLMOS doesn't schedule backups itself — wire `kolmos backup` into your platform's own scheduler. A common pattern is a Kubernetes `CronJob` running the CLI image against the live store's S3/R2 bucket on a nightly cadence; see `docs/deployment.md` in the repo for a full example manifest. Combine with `backup-log` in a monitoring check to alert if a scheduled backup silently stops running.

← Previous

Security & Authentication

High Availability & Replication