What MyDuck’s two SQL protocols actually mean

A table written through MySQL can be read through PostgreSQL because both MyDuck listeners use the same DuckDB database file.

That does not make MyDuck a drop-in MySQL or PostgreSQL server. Drivers, migrations, parameter types and queries still need testing, and one database file does not provide high availability.

Managed MyDuck is included in self-hosted alpha.56 on Linux amd64. Cloud alpha.35 packages the same support; shared Cloud availability remains capacity-dependent. Public database endpoints remain unavailable.

One database, two listeners

MyDuck translates two wire protocols into queries against one DuckDB database:

• MySQL clients connect on port 3306 as root to the app database.
• PostgreSQL clients connect on port 5432 as postgres to the same app database.

Wire compatibility does not turn DuckDB into MySQL or PostgreSQL. PostgreSQL extensions, MySQL replication and native server administration commands are not present. Drivers, migrations, parameter types and query behavior still need testing against MyDuck. An application that happens to connect is not proof that its full database workload is compatible.

The stack is one instance and one database file

Hakopod runs one hardened MyDuck container in a Kubernetes StatefulSet. A ReadWriteOnce volume holds the database, its write-ahead log and bounded temporary spill files.

There is no managed cluster mode, replica, election or automatic failover. Kubernetes can replace a failed process and reattach its volume if an eligible node and the storage remain available. That recovers a process. It does not keep another database copy ready to serve traffic.

This distinction matters when reading placement settings. Several workers or zone labels do not replicate the DuckDB file. A storage or node failure can still interrupt the only instance.

The Go control plane owns authorization, immutable revisions and durable operation claims. Applications receive the database resource’s administrative credentials, endpoint and public CA. This release does not create per-application roles or read-only users. Applications never receive Kubernetes credentials, the service-account token or the TLS private key.

Capacity protects more than the query engine

An instance needs at least 512Mi of container memory. DuckDB receives 70% of that budget, while the protocol servers and process overhead use the rest. Temporary query files may use up to one quarter of the configured data volume and share it with persistent database files.

Each protocol has a 64-connection limit, and statements have a 60-second deadline. Those limits bound resource use; they are not throughput results.

CPU, memory, storage, placement and version are fixed when the database is created. Managed pooling and in-place resize are absent. A capacity change means creating a separate compatible target, moving or restoring the data, inspecting it and deliberately changing the application binding.

The runtime closes broad extension paths

The container runs without root, Linux capabilities or a service-account token. Its root filesystem is read-only, and the database pod cannot make outbound network connections.

Runtime extension installation, external file access, remote database access, replication configuration and account changes are disabled. Client COPY FROM STDIN and COPY TO STDOUT remain available for deliberate data transfer.

Both listeners require TLS 1.2 or newer and reject plaintext. Clients still have to verify the hostname and issued CA. Certificate renewal replaces the single instance, so applications must reconnect afterward.

The managed Secret rebuilds the two protocol accounts at startup. Restoring database files cannot restore an old managed password or create additional accounts.

Backup stops the only instance

A backup stops MyDuck. Existing connections close, and new connections fail until the instance restarts. The pause depends on the database size and transfer speed, so this belongs in a planned maintenance window.

Hakopod first fences the durable operation and verifies the current database and storage identities. After the pod disappears, an isolated helper mounts the same volume. The helper has no database password, network access or listener. It copies only the database file and an existing write-ahead log, enforcing size limits and recording checksums before the normal backup service encrypts the archive.

Restore uses a different empty MyDuck database with the same version. The target is stopped, the whole encrypted archive is verified, and its catalog is checked before replacement. A durable marker prevents MyDuck from opening files left by an interrupted replacement. If archive replacement fails, the target stays stopped and isolated. After the files transfer, Hakopod reports success only after the target passes live readiness and TLS verification. A target that fails those checks remains unverified. The source database is unchanged throughout.

A successful restore still needs inspection before an application switches to it. This process is not continuous point-in-time recovery, and the backup encryption key has to be preserved separately from the cluster.

MyDuck and Oracle Free have separate gates

MyDuck and Oracle Free ship in the same self-hosted release, but their runtime contracts are different.

MyDuck is an open-source-derived, single-process DuckDB service with MySQL and PostgreSQL listeners and stopped-instance file recovery. Oracle Database Free is proprietary software managed through a namespace-scoped Oracle Database Operator. It uses TCPS, an APP schema with an upstream quota, separate data and backup-staging volumes, and Data Pump recovery at a flashback SCN.

Oracle Free also retains Oracle’s limits of 2 CPUs, 2 GB of database memory and 12 GB of user data. A larger container reservation does not raise them. It uses two equal-size volumes for data and Data Pump backup staging. Enterprise, Data Guard, RAC and public endpoints remain unavailable.

Native acceptance for one engine cannot enable the other. The alpha.56 acceptance record binds each engine to its tested source and images. MyDuck uses runtime 0.1.0-hakopod.3 at digest sha256:ad324a97360dea53f9e32cb367666b8fefa6f52377000c084a63c1712ca79873. Public endpoints have a separate outside-in qualification gate for either engine.

Read the Managed MyDuck guide for the configuration and recovery contract, the Oracle Free guide for its separate limits, and the database catalog for current availability.