Work in progress · engineering preview

PostgreSQL + MySQL,
unbundled.

The databases and native clients you already know, with durable engine logs and immutable page history on R2, MinIO, or S3. Upstream compute. Rust infrastructure. Made to recover, branch, and scale without copying a whole database.

Actual database engines

Upstream PostgreSQL and MySQL own their SQL, optimizer, catalogs, transactions, and native wire protocols.

Durable before “done”

PostgreSQL commits cross a fenced log quorum. MySQL flushes cross a 2-of-3 fsync keeper quorum and immutable S3-compatible redo storage before acknowledgement.

Immutable by default

Checksummed page layers and manifests are content-addressed. Branches reuse history instead of duplicating it.

Two engines.
Native clients.

No translated SQL and no proprietary driver. DBlicious keeps each upstream engine at the compute boundary and shares the storage and control plane beneath it.

PostgreSQL 18

working prototype

Connect with psql, libpq, JDBC, psycopg, pgx, and ordinary PostgreSQL tooling.

  • Native WAL quorum and fenced writer leases
  • Remote page layers and arbitrary-LSN recovery
  • Signed promotion and failover drill verified

MySQL 8.4 LTS

acceptance passed

Connect with the mysql CLI, Connector/J, Go, Python, Node.js, PHP, and ordinary MySQL libraries.

  • Cloud SQL 8.0 database cloned into patched upstream MySQL 8.4
  • Unmodified PHP application and native clients live verified
  • Immutable InnoDB layers and redo-before-ACK verified on MinIO
  • One-keeper-loss commit path and lagging-keeper catch-up verified
  • Fresh-PVC recovery from immutable snapshot plus archived redo verified
  • Verified remote-page eviction, refill, compaction, and cache refresh

One database.
Four clean layers.

DBlicious keeps PostgreSQL and MySQL semantics in their upstream engines while sharing durability, object storage, timelines, and lifecycle machinery.

01 · Connect

PG or MySQL compute

Native psql/mysql clients, ordinary language drivers, upstream SQL semantics, and query execution.

02 · Commit

WAL / redo durability

PostgreSQL and MySQL both gate durable acknowledgement on a fenced 2-of-3 keeper quorum; immutable WAL/redo is retained in S3-compatible storage.

03 · Materialize

Page services

Separate PostgreSQL and InnoDB page adapters, sparse writable overlays, and bounded reconstruction.

04 · Retain

S3-compatible history

Immutable layers and atomic manifests on Cloudflare R2, MinIO, AWS S3, or a certified compatible backend.

Built in public.
Measured honestly.

This is an active engineering preview, not a production database offer. The site goes live early; customer provisioning waits for recovery, compatibility, and performance evidence.

FOUNDATIONPostgreSQL 18 storage hooks and authenticated page serviceworking
DURABILITYThree-keeper WAL path with 2-of-3 fsync quorum and fencingworking
HISTORYImmutable snapshots, bounded log-manifest deltas, incremental overlays, and O(1) branchesworking
PG RECOVERYPostgreSQL-verified arbitrary-LSN replayworking
PROMOTIONSigned recovery publication, writer activation, lease handoff, and 2-of-3 failover drillworking
OBJECT STORER2 platform smoke and MinIO S3 page/redo paths verified; broader backend certification continuesin progress
MYSQLCloud SQL clone, patched MySQL 8.4, 2-of-3 redo quorum, object recovery, remote-page refill, compaction, and unmodified PHP app verifiedworking
CLOUDFLAREFree-tier Rust Worker, Durable Objects, and guarded R2 Standardworking
ACCEPTANCEIsolated PostgreSQL and MySQL Cloud SQL clones, real application traffic, and bounded comparison benchmarkspassed
RELEASEConstrained beta canary, workload-specific compatibility certification, regional capacity, soak, and SLOsnext
Preview status

No magic. No compatibility theater.

PostgreSQL 18 recovery, signed promotion, bounded manifest history, and a 138.91-second 2-of-3 quorum-loss recovery are verified. MySQL 8.4 restored a real Cloud SQL database, served its unmodified PHP application, recovered from immutable MinIO history, refilled verified evicted pages, compacted layers, and resumed the same blocked commit after a 42.77-second majority outage. The latest surgical write test removed an accumulating redo-copy slowdown and finished its last block slightly faster than its first. Both isolated application clones are healthy with unchanged source-table counts and checksums. The next milestone is an explicitly approved, reversible beta canary—not an automatic production cutover.