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

The gap Databasement fills: eight engines, eight cron jobs

Most teams do not lack a dump command. They lack a consistent place to put the schedule, the credentials, the retention rule and the restore procedure for every engine they run. A shop with MySQL, a MongoDB replica set and a SQLite file used by an internal tool ends up with three shell scripts, three cron entries, three sets of credentials, and no shared answer to the question of where last night's dump went. Databasement targets that specific mess. It is a self-hosted web application, written in PHP under the MIT licence, that registers database servers once and then applies the same scheduling, storage and notification machinery to all of them. The README describes it as a backup management application rather than a backup tool, and that framing is accurate: the actual data extraction is delegated to mariadb-dump, pg_dump, sqlpackage, mongodump, sqlite3 .backup, gbak and redis-cli --rdb. The audience is operations engineers and small platform teams who want a UI and an audit trail without buying a commercial backup suite, and who are comfortable running a container next to the databases it protects.

Native dump tools behind a scheduler, not a reimplementation

The mechanism is worth stating plainly because it explains most of the project's constraints. Databasement does not speak the wire protocol of MySQL or PostgreSQL to extract data. It shells out to the vendor CLI listed in the supported versions table: mariadb-dump for MySQL and MariaDB, pg_dump for PostgreSQL, sqlpackage producing a .dacpac for SQL Server, mongodump and mongorestore for MongoDB, sqlite3 .backup for SQLite, gbak v5 for Firebird, and redis-cli --rdb for Redis and Valkey. That means the container image has to carry those binaries, and the versions matter. The README lists pg_dump v16 and v18 as the shipped variants and gbak v5 for Firebird, so a PostgreSQL 12 server is dumped by a v16 or v18 client. Dump compatibility generally runs forward, but this is the kind of detail to confirm against your own servers rather than assume. Around that core sits the management layer: a scheduler that runs jobs on daily or weekly intervals, a queue worker enabled by ENABLE_QUEUE_WORKER=true, compression in gzip, zstd or AES-256, and a storage abstraction that writes to local disk, S3-compatible object storage, Azure Blob Storage, Samba/SMB, or SFTP/FTP. Retention is either time-based in days or GFS (grandfather-father-son). Restores are first-class: a snapshot can be replayed onto a different compatible server, and a scheduled restore can refresh a target on a recurring cadence, which the README illustrates as a nightly production to staging refresh. For databases inside private networks, two options exist. An SSH tunnel through a bastion with password or key authentication, or a remote agent that dials out over HTTPS, dumps locally and uploads to your storage, so no inbound port has to be opened.

Running it: one container, one SQLite file, port 2226

The quick start in the README is a single docker run. The container listens on 2226, and the example passes DB_CONNECTION=sqlite, DB_DATABASE=/data/database.sqlite, ENABLE_QUEUE_WORKER=true, and mounts ./databasement-data at /data. That SQLite file is Databasement's own metadata store, not a database it is backing up, which is an easy point of confusion on first read. After the container starts you open http://localhost:2226 and create the first admin account. Volume permissions are handled by the entrypoint, and PUID and PGID environment variables let you match the container user to your host user. The README points to four deployment paths: the single Docker container, Docker Compose with an external database, Kubernetes via a Helm chart published on Artifact Hub, and a native Ubuntu installation without Docker. The configuration guide is where the rest of the environment variables live; the README does not enumerate them, so treat that page as required reading before a production rollout. Beyond the UI there is a REST API for managing servers, backups and restores, and an MCP server intended for AI assistant integration. For teams that already have CI pipelines, the API is the more interesting of the two, since it lets a deployment job trigger a pre-migration snapshot without a human clicking anything.

Where the design runs out: no point-in-time recovery, no Redis restore

The supported versions table is the most honest page in the project, and it contains two entries that should shape your decision. First, the Restore column reads No for both Redis and Valkey. You can schedule RDB snapshots of a Redis instance through Databasement, but the application will not restore them for you; recovery is a manual operation with redis-cli or by replacing the RDB file. If Redis durability is a real requirement in your environment, this tool covers half the job. Second, every engine in the table is backed up by a logical dump. There is no physical backup, no WAL or binlog shipping, and therefore no point-in-time recovery. If a table is dropped at 14:03 and your last dump was 02:00, you have lost eleven hours of writes and Databasement cannot help you narrow that gap. The same logic applies to incremental backups: a multi-terabyte PostgreSQL cluster will produce a full dump every run, and neither the README nor the feature list mentions deduplication or delta transfer. Restore time is the other constraint. Logical dumps restore serially, and the README gives no figures for throughput or for how a scheduled restore behaves when the previous run is still in flight. Those are things to measure on your own data before you rely on a nightly production to staging refresh as part of a release process.

Databasement against pgBackRest and the per-engine specialists

The obvious alternative for PostgreSQL shops is pgBackRest. The difference in approach is not cosmetic: pgBackRest operates on the physical level, understands WAL archiving, supports full, differential and incremental backups, and can restore to a specific point in time. Databasement operates on the logical level through pg_dump, which makes it engine-agnostic and portable across versions but caps it at the granularity of a full dump. If your stack is PostgreSQL only and your recovery objectives are measured in minutes, pgBackRest is the right tool and Databasement is a downgrade. If your stack is PostgreSQL plus MongoDB plus a SQL Server instance plus a SQLite file, running three separate specialist tools with three separate retention policies is the problem Databasement exists to remove. The same comparison holds per engine: mongodump driven by hand gives you exactly the same artifact Databasement produces, minus the schedule, the storage routing and the failure notification. The project's value is in the orchestration layer, and it should be judged on that basis rather than on the quality of the dumps themselves, which are the vendor tools' responsibility.

Licence, maintenance and the cost of staying current

Databasement is MIT licensed, which is permissive and imposes no copyleft obligation on your own code or on the backups it produces. This is not legal advice; if you redistribute the software or bundle it into a product, read the licence text yourself. The release cadence is the more practical maintenance question. Three patch releases landed within two days in early September 2026 (v1.7.12, v1.7.13, v1.7.14), and the last push to the default branch is dated 2026-09-09. A cadence that dense suggests active development, and it also means pinning matters. The quick start example pins the image tag to davidcrty/databasement:1, which follows the major version rather than a specific patch, so an unattended pull can move you between releases. For a component that holds credentials to every database in your fleet and writes to your backup storage, pinning to an exact patch tag and upgrading deliberately is the safer default. The upgrade cost itself is not documented in the README: there is no migration guide excerpt, and the internal schema lives in the SQLite file or external database you configured. Back up the Databasement metadata database before each upgrade, because it holds the server credentials, schedules and job history that make the rest of the system meaningful.

Who should run this, and what to check on day one

Databasement fits a specific shape of team: mixed database engines, a handful of environments, no dedicated backup platform, and a willingness to run one more container. The multi-tenant organizations feature, with isolated workspaces, role-based access control, OAuth and SSO through Google, GitHub, GitLab or OpenID Connect, and optional two-factor authentication, suggests the author expects it to be shared across teams rather than run per engineer. Notifications fan out to Email, Slack, Discord, Telegram, Pushover, Gotify or a generic webhook, so a failed job does not sit unnoticed in a log file. The built-in Adminer browser for MySQL, PostgreSQL and SQLite is a convenience for inspection, gated behind an admin flag and role checks. The case against adoption is equally clear: you need point-in-time recovery, you need Redis restore, you need incremental backups, or you cannot install matching client binaries alongside the application. None of those are fixable by configuration. On day one, the concrete checks are to confirm the client tool versions in the image against your server versions, to run one backup and one restore per engine on a non-production target, and to decide whether the SSH tunnel or the remote agent is the right path for anything behind a firewall, since the two have different operational footprints: the tunnel needs reachable SSH credentials, the agent needs outbound HTTPS and a place to run.

Editorial conclusion

Adopt Databasement if you already run the native client tools for your engines and want one scheduler, one storage abstraction and one restore button across a mixed fleet. Do not adopt it if you need point-in-time recovery, per-table or incremental backups, or if you cannot install matching client binaries in the container. Before committing, verify three things on a staging host: that the bundled client versions match your servers (the README lists pg_dump v16 and v18, mariadb-dump, sqlpackage, mongodump, gbak v5 and redis-cli), that a restore of a large dump finishes inside your maintenance window, and that Redis or Valkey backups are acceptable to you given the restore column reads No for both.

Official sources

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