Upstream PostgreSQL and MySQL own their SQL, optimizer, catalogs, transactions, and native wire protocols.
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.
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.
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 prototypeConnect 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 passedConnect 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.
PG or MySQL compute
Native psql/mysql clients, ordinary language drivers, upstream SQL semantics, and query execution.
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.
Page services
Separate PostgreSQL and InnoDB page adapters, sparse writable overlays, and bounded reconstruction.
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 serviceworkingDURABILITYThree-keeper WAL path with 2-of-3 fsync quorum and fencingworkingHISTORYImmutable snapshots, bounded log-manifest deltas, incremental overlays, and O(1) branchesworkingPG RECOVERYPostgreSQL-verified arbitrary-LSN replayworkingPROMOTIONSigned recovery publication, writer activation, lease handoff, and 2-of-3 failover drillworkingOBJECT STORER2 platform smoke and MinIO S3 page/redo paths verified; broader backend certification continuesin progressMYSQLCloud SQL clone, patched MySQL 8.4, 2-of-3 redo quorum, object recovery, remote-page refill, compaction, and unmodified PHP app verifiedworkingCLOUDFLAREFree-tier Rust Worker, Durable Objects, and guarded R2 StandardworkingACCEPTANCEIsolated PostgreSQL and MySQL Cloud SQL clones, real application traffic, and bounded comparison benchmarkspassedRELEASEConstrained beta canary, workload-specific compatibility certification, regional capacity, soak, and SLOsnextNo 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.