Managed Vitess

Self-hosted alpha.56 carries Managed Vitess forward from alpha.55. Cloud alpha.35 packages the same runtime, but the current shared Cloud service cannot provision Vitess. Self-hosted installations need the pinned controllers, private Linux amd64 workers, approved capacity and dedicated native backup storage.

What the stack contains#

Vitess runs MySQL behind tablets and a query-routing layer. It is separate from MySQL InnoDB Cluster. Hakopod's Go process owns authorization and durable operations; applications never receive Kubernetes credentials.

The data-volume request applies to every MySQL member. A native backup job adds one member-sized MySQL allocation plus 100m CPU and 512Mi for vtbackup. Admission also reserves replacement, sandbox and recovery headroom. The operator is namespace-scoped because its topology TLS trust is process-wide; sharing one process across database issuers would mix those trust boundaries.

Self-hosted alpha.56 pins Vitess 23.0.6, MySQL 8.4.6, Vitess Operator 2.16.0 and etcd 3.5.17. Hakopod's patched runtime and operator images must match the alpha.55 qualification record preserved for alpha.56. An upstream version label alone is not release evidence.

Choose the data layout deliberately#

Standalone has one shard, one tablet and one gateway. Cluster mode supports 1, 2, 4 or 8 shards, one to five replicas per shard and two gateways. The maximum is 48 tablets. Each MySQL member needs at least 500m CPU and 1Gi memory. CPU, memory, storage, topology and placement are fixed at creation; the released runtime does not resize or reshard a running database.

Multiple shards require explicit table entries with integer hash sharding columns. Hakopod generates a VSchema that tells vtgate where those rows belong. Queries without the sharding key may visit several shards, so choose the key from real query and transaction patterns.

The CLI reads a strict, versioned TOML file and submits the database settings through the shared API. Unknown fields are rejected. This example still requires operator-approved capacity and backup storage:

schema_version = 1
name = "orders-vitess"
engine = "vitess"
version = "23"
mode = "cluster"
replicas = 1
shards = 2
cpu = "500m"
memory = "1Gi"
storage_gib = 10

[tls]
mode = "required"

[placement]
spread = "nodes"

[vitess]
backup_destination_id = "replace-with-reviewed-destination-id"
backup_destination_revision = 1

[[vitess.tables]]
name = "orders"
sharding_column = "customer_id"

The native backup destination is required at creation. An installation operator must approve its immutable revision for the exact project, environment and database name, including its allowed HTTPS endpoint addresses. Credentials stay in the encrypted destination record; they do not belong in TOML or the approval file. The placeholder above intentionally cannot pass ID validation.

The transaction mode is SINGLE. Managed Vitess does not promise cross-shard transactions, distributed foreign keys or arbitrary custom vindexes. Rebuilding a compatible separate target and reviewing cutover is different from online resharding.

Choose routing and permissions separately#

Applications connect privately to vtgate on MySQL port 3306. Use app@primary for writes and primary reads, or app@replica for replica reads. Both targets use the same restricted application account. Selecting the replica target does not make that account read-only, automatically split SQL reads from writes or guarantee read-after-write consistency.

The Connections view supplies the private hostname and public CA. Clients must verify both the issuer and hostname. TLS also protects internal query and control RPCs, MySQL replication and etcd traffic. Replication uses owned DNS names so the receiving side can verify the primary identity.

The application account owns the application schema. Internal administration and replication use separate identities. Applications receive neither issuer keys, internal credentials, backup credentials nor cluster access. The alpha.55 qualification binds plaintext refusal, wrong-host and unrelated-issuer failures, renewal and primary recovery to the released source and pinned images.

Native backup and logical recovery are different#

Native physical backups seed replacement tablets when replication can no longer catch up from retained binary logs. They are written per shard to the dedicated approved destination. A listed backup is not proof that a replacement member restored successfully. Removing Hakopod's approval stops approved backup work and removes platform access; revoke the provider key separately when it must become unusable.

Logical archives serve user-directed recovery. They record exact engine versions, the VSchema and shard map, with a bounded checksummed SQL stream for each shard. The shared backup service encrypts and authenticates the outer archive. Each shard is captured under its own read lock, so the archive is not one transactionally consistent instant across every shard and is not continuous point-in-time recovery.

Restore uses a separate empty target with the same version, shard map and VSchema. Hakopod stages and authenticates every shard before executing SQL, closes target ingress, disconnects existing gateway sessions and imports with application-schema privileges. The source remains in place. The target stays isolated until an operator inspects the restored data and records that decision.

Limits and availability#

Managed Vitess targets private Linux amd64 workers. ARM64 is not qualified. It has no dedicated public Vitess endpoint, online resharding or in-place capacity changes. Native query-latency, replication-lag, cache-hit and storage-usage metrics are unavailable. Node or zone placement expresses scheduling intent and does not prove independent providers, networks, storage or power.

The self-hosted alpha.56 release carries the alpha.55-qualified Vitess runtime, controller payloads and pinned images unchanged. Its release evidence preserves the alpha.55 native and shared HTTP results, with an exact source-delta review and shared CI regressions for alpha.56. Cloud alpha.35 packages the same runtime with hosted workspace ownership, capacity, placement and backup approval checks. Shared Cloud still needs a supported dedicated worker setup path, enough capacity, native backup approval and production acceptance before it can provision Vitess. These releases establish development release behavior, not production availability, throughput or physical zone resilience.

Source and upstream concepts#

In the source checkout, start with docs/managed-vitess.md, internal/database/vitess.go, internal/database/vitess_archive.go and internal/cluster/database_vitess*.go. The alpha.56 source carries the unchanged implementation first qualified in alpha.55. The alpha.55 native and shared HTTP records remain the qualification evidence; alpha.56 adds the source-delta review and shared CI regressions. Use the Vitess documentation to review VSchema, vindexes, transaction modes and backup behavior for the selected version.