Databasement: a self-hosted backup manager for eight database engines

What Databasement actually replaces

Most small teams back up databases with a shell script per engine, a cron entry, and a directory on some server nobody checks. Databasement takes that arrangement and gives it a UI, a scheduler, a storage layer and a job log. The README lists MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, MongoDB, SQLite, Firebird and Redis/Valkey as supported engines, each dumped through its native CLI tool: mariadb-dump, pg_dump, sqlpackage for .dacpac files, mongodump, sqlite3 .backup, gbak for Firebird, and redis-cli --rdb for Redis. The audience is the operator who has four or five of those engines in production and no dedicated DBA. Databasement is not a database management system in the academic sense, and it does not run queries against your data outside the Adminer browser it embeds for MySQL, PostgreSQL and SQLite.

The mechanism: native CLI dumps, a queue worker, and pluggable storage

The design leans on tools that already exist rather than reimplementing dump formats. A job runs the engine's CLI binary against the target server, compresses the output with gzip, zstd or AES-256, and writes it to the configured storage backend: local disk, S3-compatible object storage, Azure Blob Storage, Samba/SMB, or SFTP/FTP. Scheduling is daily or weekly, with retention expressed either as a simple number of days or as a GFS (grandfather-father-son) policy. The repository layout shows a Laravel application: app/, routes/, config/, database/ and artisan at the root, with a separate worker process. The docker-compose.yml used for local development makes that split explicit, running the web container and a worker container whose command is php artisan queue:work --queue=backups,default --tries=3 --timeout=3600 --sleep=3 --max-jobs=1000. That timeout value matters: a dump that runs longer than 3600 seconds is killed. For networks that cannot accept inbound connections, the README describes remote agents that connect out over HTTPS, dump locally, and upload to your storage. SSH tunnels handle the opposite case, reaching databases behind a bastion with password or key authentication.

Installing Databasement with Docker and taking a first backup

The README gives a single-container command as the quick start. It publishes port 2226, stores the application's own metadata in SQLite under /data, enables the queue worker inside the same container, and mounts a host directory for persistence. Note that ./databasement-data is a relative path, so run it from the directory where you want the volume to live.

docker run -d \
  --name databasement \
  -p 2226:2226 \
  -e DB_CONNECTION=sqlite \
  -e DB_DATABASE=/data/database.sqlite \
  -e ENABLE_QUEUE_WORKER=true \
  -v ./databasement-data:/data \
  davidcrty/databasement:1

Once the container is up, the README says to open http://localhost:2226 and create your first admin account. It also notes that the container handles volume permissions itself, and that PUID and PGID environment variables let you match your system's user and group IDs. For anything beyond a trial, the README points at the configuration guide for environment variables and best practices.

First run: what happens after you open port 2226

Opening http://localhost:2226 presents a first-admin-account screen, according to the README. From there you register a database server, choose a storage target, and attach a schedule. The README states that the container handles volume permissions on its own, and that PUID and PGID environment variables let you match the host user and group. That detail is worth taking seriously on a bind mount, because a dump written as the wrong UID is a dump your backup tooling may not be able to read later. The README also points to a live demo for anyone who wants to see the UI before installing. What the README does not document is a rollback path for a restore that fails halfway; the restore feature is described as replaying snapshots between compatible servers, with scheduled restores for refreshing a target on a recurring basis, but recovery from a partial restore is left to the operator.

Limits that decide whether Databasement fits

Redis and Valkey are listed as backup-only: the support table shows redis-cli --rdb under CLI Tool and No under Restore. If your Redis instance holds anything you would need to bring back, Databasement will store the RDB file but will not put it back for you. SQL Server is a different shape from the rest, using sqlpackage and .dacpac files rather than a plain dump, so the restore semantics are schema-and-data deployment rather than a byte-for-byte replay. The worker timeout of 3600 seconds is a hard ceiling on a single job; a multi-hundred-gigabyte PostgreSQL dump on slow storage will hit it. And Databasement backs up databases, not hosts: it has no concept of filesystem snapshots, WAL archiving or point-in-time recovery. If your recovery objective is measured in seconds rather than in the time it takes to restore last night's dump, this is the wrong layer of the stack.

How it compares with running pg_dump and a cron file

The honest alternative is not another product; it is the shell script you already have. A cron job calling pg_dump, piping through zstd, and pushing to S3 with the AWS CLI does the same core work in about ten lines, with no container, no queue worker and no web UI. The difference is everything around the dump: Databasement adds retention policies you configure rather than write, failure notifications through Email, Slack, Discord, Telegram, Pushover, Gotify or a generic webhook, job logs with progress, cross-server restore, and role-based access control with OAuth/SSO and optional two-factor authentication for teams. The script wins on transparency and on the ability to tune the exact dump flags. Databasement wins when the number of engines times the number of environments exceeds what one person can hold in their head. There is also a REST API and an MCP server for CI/CD and AI assistant integration, which the README calls out as automation surfaces.

Maintenance, licence and upgrade cost

The repository is MIT licensed, which permits commercial use and modification; the LICENSE file is at the root. No legal advice follows from that, only the observation that MIT imposes no copyleft obligation on your own code. On maintenance: the last push was on 2026-09-09, and the most recent releases listed are v1.7.14, v1.7.13 and v1.7.12, all dated within the first week of September 2026. The version numbers move in small increments, which suggests frequent patch releases; pinning the image tag rather than tracking latest is the lower-risk choice for a backup system. The upgrade cost is mostly the container image plus any schema migrations the application runs against its own SQLite or external database. Deployment options listed in the README are Docker, Docker Compose, Kubernetes with a Helm chart published on Artifact Hub, and a native Ubuntu install, so the migration path off Docker exists but is the least documented of the four.

Editorial conclusion

Adopt Databasement if you run several engines and want one scheduler, one storage target and one restore button instead of a pile of cron scripts. Skip it if you need point-in-time recovery, Redis restores, or a backup agent that survives the host it runs on. Before trusting it, verify three things: that the CLI tool for each engine is present in the image you deploy, that the restore path works for your largest database, and that your retention policy matches what the GFS option actually keeps. The README documents scheduling and retention, but the docs are silent on rollback of a failed restore, so test that path on a throwaway target first.

Frequently asked questions

Official sources

1. David-Crty/databasement on GitHub
2. License: MIT
3. Project website
4. README
5. Releases