Managed databases
Manage released database engines, including MyDuck, Oracle Free and fixed-topology Vitess.
Hakopod Cloud (beta) runs managed PostgreSQL and Redis in eligible workspaces. Self-hosted installs can run all eight engines once an operator installs each engine's controller. Use the latest release with separate operator setup for controllers, storage and placement. Follow the database overview for a visual explanation.
Manage the database separately#
Managed PostgreSQL 17/18, Redis 8, MySQL 8.4, MongoDB 8.0 and ClickHouse 26.3 have their own compute, storage, operation status and credentials. They are managed separately from applications. Application replica counts do not control database replication or failover. Connecting a database updates the application's saved connection and requires a redeployment.
| Engine | Standalone | Clustered |
|---|---|---|
| PostgreSQL | One database instance. | A primary and replicas, primary recovery, and private read/write and read-only endpoints. |
| Redis | One Redis instance. | Data distributed across shards, with replicas. Requires a cluster-aware client. |
| MySQL | One database member and one Router. | Three, five or seven voting members and two Routers, with separate primary and replica routes. |
| MongoDB | One replica-set member. | Three, five or seven voting members. Requires a replica-set-capable driver. |
| ClickHouse | One data member. | Replicated shards and three Keeper members. Distributed tables combine data across shards. |
| Vitess | One shard, one tablet and one vtgate. | One, two, four or eight shards, one to five replicas per shard, two vtgate gateways and at most 48 tablets. |
| MyDuck | One DuckDB file served by one Linux amd64 instance through MySQL and PostgreSQL wire protocols. | Unavailable. There is no cluster, replica or automatic failover mode. |
| Oracle Database Free | One proprietary, no-cost Oracle Free database with an APP schema. | Unavailable. Free does not provide a Data Guard cluster. |
Replicas need real compute and storage. A cluster on one worker or VM cannot remain available if that worker, VM or its shared disk is lost.
Architecture and engine guides#
Follow a request through the Go API and durable workers, choose routes and connection pools, configure credentials and TLS, and plan recovery and cutover.
The PostgreSQL guide explains CloudNativePG and PgBouncer. The Redis guide covers slot routing, resize evidence and per-shard recovery. Each expanded-engine guide below records its own implementation and acceptance boundary.
Released and deferred engines#
Self-hosted alpha.56 adds Managed MyDuck and Oracle Database Free to PostgreSQL, Redis, MySQL, MongoDB, ClickHouse and Vitess. Cloud alpha.35 packages the same database support. Packaging does not guarantee capacity in shared Cloud: the current shared service cannot provision Oracle Free or Vitess, and MyDuck availability remains capacity-dependent. The alpha.56 acceptance record covers the new MyDuck and Oracle Free qualification. Vitess keeps its alpha.55 native and shared HTTP evidence; alpha.56 carries the unchanged Vitess runtime, operator, images, build and installer after an exact source-delta review and shared CI regressions. Neon and Supabase remain deferred.
| Engine | Development model | Current boundary |
|---|---|---|
| MySQL | Standalone or Group Replication, with MySQL Router. | Included in alpha.50. Requires the pinned controller and eligible AMD64 workers. Private connections require TLS; public endpoints remain disabled. |
| MongoDB | Standalone or clustered replica sets; the driver discovers members. | Included in alpha.48. Native development checks cover lifecycle, resizing, election/quorum, recovery, bindings and TLS renewal. Install the qualified controller before provisioning. |
| ClickHouse | Standalone or replicated shards with three Keeper members. | Included in alpha.52. Private TLS, application bindings, topology monitoring and per-shard recovery into a separate target. Requires the pinned controller and eligible workers; public endpoints remain disabled. |
| Oracle Database | Free standalone with TCPS and an APP schema. | Included in self-hosted alpha.56 through a namespace-scoped Oracle Database Operator. Free is proprietary, no-cost software limited to 2 CPUs, 2 GB of database memory and 12 GB of user data. Enterprise, Data Guard and public endpoints remain unavailable. The current shared Cloud service cannot provision Oracle Free. |
| Vitess | Private sharded MySQL with explicit VSchema routing and fixed topology. | Included since self-hosted alpha.55; alpha.56 carries the released support forward. Cloud alpha.35 packages it, but the current shared Cloud service cannot provision Vitess. Qualified Linux amd64 workers, approved capacity and native backup storage are required. ARM64, public endpoints and online resharding remain unavailable. |
| MyDuck | One persistent DuckDB database with MySQL and PostgreSQL wire-protocol listeners. | Included in self-hosted alpha.56 on Linux amd64 with runtime image digest sha256:ad324a97360dea53f9e32cb367666b8fefa6f52377000c084a63c1712ca79873. Cloud alpha.35 packages it; shared Cloud availability depends on eligible worker capacity and runtime setup. There is no replica, automatic failover, in-place resize, managed pooling or public endpoint contract. |
| Neon | Self-hosted PostgreSQL compute, pageservers, safekeepers, controller and proxy. | Full-stack implementation and recovery checks are in progress. Creation, clustering and public access remain unavailable. |
| Supabase | Self-hosted PostgreSQL, Auth, APIs, Storage, Functions, Studio and pooling. | Full-stack startup, compound recovery and rotation remain unqualified. Creation and public access remain unavailable. |
Oracle Enterprise will require an eligible customer license, a digest-pinned image and a registry-credential reference scoped to the database's project and environment. Do not put a registry password or license document in database configuration.
Connection routing depends on the database engine. PostgreSQL and MySQL expose separate write and replica routes. PgBouncer pools PostgreSQL connections; it does not infer query intent. Redis and MongoDB need compatible discovery-aware clients. ClickHouse needs Distributed tables or explicit shard routing for queries across shards.
Released versions do not provide dedicated public database endpoints. Public endpoints for self-hosted PostgreSQL are unreleased. Public endpoints for MySQL, ClickHouse and Oracle remain disabled while testing continues. Cloud does not offer public database endpoints. Private networking does not replace TLS: clients must verify the database hostname and the issued CA. A copied connection URL alone does not configure private CA trust.
Review a Redis resize#
Before changing the shard count, review the proposed resources and take a recent backup that passes verification. Before resizing, Hakopod checks cluster health and which shards own each slot. It then waits for the cluster to reach the requested layout. Application replica changes never resize the Redis cluster.
Back up to a destination you choose#
Configure an eligible S3-compatible destination for manual, hourly or daily backups. Backups are verified archives, separate from database replicas. Redis archives preserve values and expiry. Each shard is captured consistently; the entire cluster is not captured as one transaction.
Restore, inspect, then switch#
- Restore a verified archive into a separate managed database. The source stays available.
- Inspect the restored data and acknowledge that review before replacing a connection.
- Switch by replacing the application's saved connection, then redeploying it.
The restored copy contains data from the backup’s recovery point. New writes are not copied to it automatically. Coordinate application writes and take a fresh backup if needed before switching connections. The switch may require downtime.
Import from Docker or stage a PostgreSQL upgrade#
Import an eligible Docker PostgreSQL or Redis archive while the original application remains on Docker. The archive must match its reviewed metadata and checksum. PostgreSQL 17-to-18 upgrades use a separate logical copy for checking before connection replacement. See the pinned implementation guide for eligible archive formats, destination requirements, limits and controller installation.
Cloud capacity and setup#
Hosted Cloud applies workspace memory and storage quotas, places databases on approved nodes and requires the relevant approvals. Capacity determines which topology fits. Account signup does not guarantee compute allocation. Self-hosted and BYO installations require operator setup of the matching engine, pinned database controllers, worker runtime and storage.
The current shared Cloud service cannot provision Oracle Free or even the smallest standalone Vitess database because its existing worker lacks the required capacity. Cloud alpha.35 packages both engines but does not add that capacity. MyDuck is lighter, but shared availability still requires eligible worker capacity and runtime setup. Account signup does not guarantee any database allocation.
Cloud BYO relay archive uploads are not supported by this implementation. Use the direct node HTTPS API with the CLI. Prices and launch dates for the unreleased additions have not been announced.