Managed DuckDB with MyDuck

Self-hosted alpha.56 includes Managed MyDuck on Linux amd64. Cloud alpha.35 packages the same support; shared Cloud availability depends on eligible worker capacity and runtime setup. Public database endpoints remain unavailable.

MyDuck lets an application use a MySQL or PostgreSQL client with one DuckDB database. Both listeners reach the same data. This wire compatibility does not add every MySQL or PostgreSQL feature. Test the chosen driver, migrations, data types and queries before moving an existing application.

What runs#

Hakopod runs one hardened MyDuck container in a Kubernetes StatefulSet. One ReadWriteOnce volume stores app.db, its write-ahead log and bounded temporary spill files. MyDuck translates both wire protocols and executes the queries in DuckDB.

Both accounts use the generated password for that database resource. This release does not create per-application roles or read-only users. It also does not provide PostgreSQL extensions, MySQL replication or native server administration commands.

The Go API and reconciler retain authorization, immutable revisions and durable operation ownership in PostgreSQL. Kubernetes runs the StatefulSet and its volume. Applications receive scoped connection details and public CA material; they receive no Kubernetes credentials.

MyDuck has no managed cluster mode, replica, election or automatic failover. Kubernetes can replace the process and reattach its existing volume when the node and storage remain available. That is process recovery, not high availability. Zone labels or extra nodes do not copy the database.

Fixed capacity and runtime limits#

0.3.1-dev.20260919.3 is the released database version on Linux amd64. The runtime is built from apecloud/myduckserver commit 6e3427591fd8895df9585969e7256f958fb639bb with Hakopod's managed-runtime restrictions. The released image is ghcr.io/hakopod/managed-myduck@sha256:ad324a97360dea53f9e32cb367666b8fefa6f52377000c084a63c1712ca79873, runtime version 0.1.0-hakopod.3.

memory must be at least 512Mi. DuckDB receives 70% of the configured memory budget; the rest is retained for the protocol servers and process overhead. Temporary files may use up to one quarter of the configured data-volume size and share that volume with database files. Each protocol is limited to 64 connections, and statements have a 60-second deadline. These are bounds, not performance claims.

Capacity, placement and engine version are fixed at creation. There is no in-place resize or managed connection pooling. Change capacity by restoring or migrating into a separate compatible target, inspecting it and then changing the application binding.

schema_version = 1
name = "analytics"
engine = "duckdb"
version = "0.3.1-dev.20260919.3"
mode = "standalone"
replicas = 0
shards = 1
cpu = "1"
memory = "1Gi"
storage_gib = 10

[tls]
mode = "required"

Connections and restrictions#

Both listeners require TLS 1.2 or newer and reject plaintext. Clients must verify the database hostname and issued CA. Certificate renewal replaces the single instance, so existing sessions end and applications must reconnect.

The container runs as a non-root user with a read-only root filesystem, no Linux capabilities and no service-account token. Its pod has no outbound network access. Runtime extension installation, external file and network access, replication configuration and account changes are disabled. Client COPY FROM STDIN and COPY TO STDOUT remain the supported transfer path.

The managed Secret rebuilds both protocol accounts at startup. A restored database cannot bring back an old password or an additional account. Credentials, server configuration and temporary files are excluded from database archives.

Backup and separate-target recovery#

A managed backup stops the only MyDuck instance, so current connections close and new ones fail until it restarts. Hakopod fences the durable operation, verifies the database and volume identities, and waits for the database pod to disappear. An isolated helper with no database credentials, network access or listener copies only app.db and an existing app.db.wal, with a size bound and checksum for each file. The normal backup service then encrypts and uploads the archive.

Restore requires a separate empty MyDuck database with the same version. Hakopod verifies the encrypted archive, stops the target and checks its catalog read-only before replacement. A durable marker prevents the runtime from opening files left by an interrupted restore. A failed archive replacement stays stopped and isolated. After transfer, the target succeeds only after live readiness and TLS verification; a failed verification leaves it unverified. The source remains unchanged, and the target must be inspected before an application switches to it.

This is not continuous point-in-time recovery. Losing the separately retained backup encryption key makes the archive unreadable.

Release boundary#

Source tests and native acceptance are separate. The alpha.56 acceptance record covers both protocols, rejected credentials and plaintext, restricted SQL, pod replacement with persistent data, certificate changes, encrypted backup and restore, worker loss and deletion against the released source and images. Public routes have a separate gate for outside-in DNS, firewall, certificate rotation and revocation checks.

Those development cases qualify the named self-hosted release; they do not establish shared Cloud availability, throughput, independent failure domains or compatibility with every MySQL and PostgreSQL client. Oracle Free has its own operator, proprietary image, TCPS, schema quota and Data Pump recovery contract. Passing MyDuck tests cannot enable Oracle Free, Enterprise or Data Guard.

Source and related guides#

The implementation is in the public Hakopod repository. In the source checkout, read docs/managed-myduck.md with the runtime patch and acceptance tests. Return to the database catalog to compare availability, or read the Oracle Free guide for its separate boundary.