Vitess runs MySQL behind a routing and control layer. It is useful when one MySQL database needs to be divided by an explicit, stable sharding key. An ordinary MySQL deployment with replicas is simpler, and replicas alone do not create shards.
Managed Vitess is included in self-hosted alpha.55. It uses private connections, fixed topology and operator-approved native backup storage. Cloud alpha.34 packages the same runtime, but the current shared Cloud service cannot provision Vitess. A dedicated worker setup path, sufficient capacity, backup approval and production acceptance are still required.
Suppose an orders table uses customer_id as its sharding column. Vitess can hash that value and route each customer’s rows to one shard. Each shard contains a different portion of the data. Replicas contain copies of their shard. With two shards and two replicas per shard, the layout has six MySQL members: one primary and two replicas for each shard. Adding a replica improves the number of copies and can provide another explicit read target, but it does not increase how much distinct data the database can hold.
Queries that include the sharding key can go directly to the right shard. Queries without it may have to visit several shards. This is why the application’s access patterns and transaction boundaries should determine the key. Choosing a larger shard count first does not solve that design problem.
The processes behind one database
Every shard has one MySQL primary and the configured number of replicas. A vttablet process sits beside every MySQL member. It manages that member and serves queries received from Vitess.
Applications connect to vtgate, which authenticates the client and uses the VSchema to route its SQL. A standalone layout has one gateway; a clustered layout has two. vtctld provides the internal control API, while one vtorc per shard watches replication and coordinates primary changes. Three etcd voters store Vitess topology records. A namespace-scoped operator reconciles the Kubernetes resources, and a separate storage controller manages the approved native backup location. Temporary vtbackup jobs create the physical copies used to seed members.
Hakopod’s Go management process continues to own authorization, the shared /api/v1 contract and durable operations in PostgreSQL. Applications never receive Kubernetes credentials. The database operator can access resources only inside that database’s namespace.
Self-hosted alpha.55 selects Vitess 23.0.6, MySQL 8.4.6, Vitess Operator 2.16.0 and etcd 3.5.17. Hakopod’s release uses patched runtime and operator images for the required TLS and backup behavior; upstream version numbers alone do not describe that build.
Connections are explicit
vtgate exposes the MySQL protocol on port 3306. A client chooses a tablet role in the database target:
app@primaryroutes writes and primary reads.app@replicaroutes reads to replicas.
Both targets use the same scoped application account. The replica target does not turn that account into a read-only user, and the gateway does not automatically inspect SQL and split reads from writes. Replica reads also do not promise read-after-write consistency. Applications should choose the target deliberately and retry failed transactions only when doing so is safe for that operation.
The Connections view supplies the private hostname and public CA. Clients must verify both the issuer and hostname. Inside the database, TLS also covers query and control RPCs, MySQL replication and etcd traffic. Replication uses owned DNS services so the receiving side can verify the primary hostname, and etcd requires client certificates.
Credentials are separated by purpose. The application identity owns the application schema. Internal administration uses a different account over a local Unix socket, and replication has its own TLS-required account. Table ACLs restrict query RPCs to the application identity. Network policy lets applications reach vtgate, while tablets, etcd and control APIs remain private. Private keys stay in namespace-owned Kubernetes Secrets, and applications receive neither the issuer key nor storage credentials.
Backup and recovery solve two different problems
Native physical backups exist to seed a MySQL member. If a tablet has been offline longer than the source retains binary logs, it needs a physical copy before it can catch up through replication. Vitess creates these backups per shard in a dedicated, operator-approved object-storage destination. The credentials must be dedicated to the database, the destination must use HTTPS, and the operator approval binds its immutable revision to the exact project, environment and database.
Logical archives serve a different recovery case. They capture application data so it can be imported into a separate, empty and compatible Vitess database. Each shard is read while holding its own read lock, so the archive is not one global instant across every shard and it is not continuous point-in-time recovery.
During logical recovery, Hakopod stages and authenticates every shard before executing SQL. It closes application ingress, disconnects existing gateway sessions, checks that the target is empty and imports with application-schema privileges. The target must have the same supported version, shard map and VSchema. Access remains closed afterward until an operator records the inspection; the source database remains in place.
Native backup state deserves the same care. A listed backup object is not proof that a replacement member has been restored successfully. Removing Hakopod’s backup approval stops new backup work and removes its Secret and allowed storage addresses, but an already running database process may still hold a credential copy. Revoking that key at the storage provider is what makes it unusable.
The initial boundaries
Managed Vitess targets private Linux amd64 workers. ARM64 is not qualified, and there is no dedicated public Vitess endpoint. Cluster mode accepts one, two, four or eight shards, with one to five replicas per shard and at most 48 MySQL members. Topology and capacity are fixed at creation. There is no online resharding or in-place capacity change.
The contract also excludes cross-shard transactions, distributed foreign-key guarantees and arbitrary custom vindexes. It does not provide accepted query-latency, replication-lag, cache-hit or storage-usage metrics. Node or zone placement expresses scheduling intent; it does not prove that providers, networks, storage or power are independent.
Recovery inspection is part of the product behavior. Operators need to inspect restored data and routing before reopening application access. Self-hosted alpha.55 passed five native cases covering lifecycle, recovery, replica reseeding, backup approval revocation and the maximum supported topology, plus shared HTTP acceptance against the same source and pinned images. Cloud alpha.34 adds hosted workspace ownership, capacity, placement and backup approval checks. Those package checks do not make Vitess available in shared Cloud. These are development releases, without a production availability or uptime guarantee.