# What bkpdb backs up today, and what is next

> Engines bkpdb supports today and the ones we plan to add next.

URL: https://bkpdb.com/databases/
Section: Databases

---


{{< stub "Supported today" >}}

<div class="engines">
  <article class="engine">
    <div class="head">
      <h3>PostgreSQL</h3>
      <span class="versions">13 &middot; 14 &middot; 15 &middot; 16 &middot; 17 &middot; 18</span>
    </div>
    <p>Logical backups via <code>pg_dump</code>, custom format. The agent fetches a matching dump binary for the server&rsquo;s major version on demand, from a signed registry, so you do not have to install anything alongside it.</p>
    <p class="row"><span class="status ok">Available</span><span class="sep">|</span>Self-hosted Postgres<span class="sep">|</span>Logical, v1</p>
  </article>
</div>

{{< stub "Next for Postgres" >}}

<div class="engines">
  <article class="engine">
    <div class="head">
      <h3>Point-in-time recovery</h3>
      <span class="versions">base backup + WAL</span>
    </div>
    <p>Continuous WAL streaming on top of the scheduled base backup. Recover to a specific second by picking a base and replaying WAL up to a timestamp or LSN. Target RPO is measured in seconds, set by how aggressively WAL is shipped, not by the daily schedule. Lands after verified restores.</p>
    <p class="row"><span class="status warn">Next</span><span class="sep">|</span>Postgres 13 to 18<span class="sep">|</span>Physical, continuous</p>
  </article>
</div>

{{< stub "Other engines, on the roadmap" >}}

<p style="max-width:42em;color:var(--mute);">The agent is engine-agnostic. Each engine ships as a small plug-in that knows how to dump, how to restore, and (eventually) how to verify. We are not committing dates. We would rather ship one engine well than promise four. PITR for Postgres comes first.</p>

<div class="engines">
  <article class="engine">
    <div class="head">
      <h3>MySQL &amp; MariaDB</h3>
      <span class="versions">planned</span>
    </div>
    <p>Logical backups via <code>mysqldump</code> with single-transaction and triggers, with room for physical backups for the larger end later on.</p>
    <p class="row"><span class="status muted">Planned</span></p>
  </article>

  <article class="engine">
    <div class="head">
      <h3>MongoDB</h3>
      <span class="versions">planned</span>
    </div>
    <p>Logical via <code>mongodump</code>, with index metadata captured separately.</p>
    <p class="row"><span class="status muted">Planned</span></p>
  </article>

  <article class="engine">
    <div class="head">
      <h3>Redis &amp; Valkey</h3>
      <span class="versions">planned</span>
    </div>
    <p>RDB snapshots streamed off a replica, with optional AOF for installations that ask for it.</p>
    <p class="row"><span class="status muted">Planned</span></p>
  </article>

  <article class="engine">
    <div class="head">
      <h3>ClickHouse, SQLite, and others</h3>
      <span class="versions">considered</span>
    </div>
    <p>On the longer list. If you operate one of these and want it on the page above, write to us. Demand pulls work forward.</p>
    <p class="row"><span class="status muted">Considered</span></p>
  </article>
</div>

{{< stub "How an engine gets added" >}}

<div class="two-col">
  <article>
    <p>The agent is engine-agnostic. The engine-specific bits live in a small plug-in that knows three things: how to dump, how to restore, and how to verify. We will publish the contract when the second engine is on staging and the shape has stopped moving.</p>
    <p>For each engine we ship, the commitment is:</p>
    <ul style="font-size:var(--fs-data);color:var(--mute);">
      <li>A logical backup path that runs without elevated privileges on the host.</li>
      <li>A clear list of what is captured, and what is not.</li>
      <li>End-to-end encryption to the same organisation key as Postgres.</li>
      <li>A migration plan from the previous version of the plug-in.</li>
    </ul>
    <p>If the engine you operate is not above and you would like it to be, write to us. We are reading.</p>
  </article>
  <aside>
    <h3>Coverage today</h3>
    <p>Postgres is the only engine the team treats as ready to test against, and even then we are not asking anyone to trust us with production until v1.0.</p>
    <h3>Plug-in shape</h3>
    <p>Three commands (<code>dump</code>, <code>restore</code>, <code>verify</code>) with a typed manifest. No long-running daemons. No state on disk.</p>
  </aside>
</div>

{{< ledger >}}
| Engine / capability | Status | Method | Notes |
|---|---|---|---|
| PostgreSQL 13 to 18 | <span class="status ok">Available</span> | pg_dump &middot; custom | Self-hosted; agent fetches matching binary |
| Postgres, verified restores | <span class="status warn">Roadmap</span> | scheduled clean restore | Paid plans |
| Postgres, PITR | <span class="status warn">Next after verify</span> | base backup + WAL streaming | RPO in seconds |
| MySQL / MariaDB | <span class="status muted">Planned</span> | mysqldump (later: physical) | No date |
| MongoDB | <span class="status muted">Planned</span> | mongodump | No date |
| Redis / Valkey | <span class="status muted">Planned</span> | RDB &middot; AOF | No date |
| ClickHouse / SQLite / others | <span class="status muted">Considered</span> | tbd | Demand-driven |
{{< /ledger >}}