Managed Vitess
Understand tablets, vtgate, VSchema, topology services and the native acceptance still required.
Under construction; native runtime acceptance pending. Vitess is not available merely because the source accepts a specification. This guide records the current proposed implementation and the checks needed before availability can be announced.
What the stack contains#
Vitess runs MySQL behind tablets and a query-routing layer. It is separate from MySQL InnoDB Cluster.
| Component | Responsibility | Current allocation |
|---|---|---|
| MySQL and vttablet | Store shard data and expose the tablet to Vitess | Configured MySQL CPU/memory plus 100m CPU and 256Mi for each tablet process. |
| vtgate | Route client queries using the keyspace, shard map and VSchema | One standalone or two clustered gateways, each 250m CPU and 256Mi. |
| vtctld | Control-plane operations | One at 500m CPU and 256Mi. |
| vtorc | Observe and recover shard primary topology | One per shard at 500m CPU and 256Mi. |
| etcd | Store topology metadata | Three members, each 100m CPU, 256Mi and a 1Gi volume. |
| Namespace-scoped operator | Reconcile the database's native resources | One at 100m CPU and 256Mi. |
The data-volume request applies to every MySQL member. Admission adds replacement and recovery headroom to steady requests. vtctld and vtorc each use one Go processor and a 192MiB memory target within their allocation. The operator is namespace-scoped because the upstream operator's topology TLS trust is process-wide; sharing one process across different database issuers would mix those trust boundaries. Native RBAC and cross-namespace refusal still need acceptance.
The source pins operator 2.16.0 and Vitess 23.0.6, whose Lite image includes MySQL 8.4.6. Any necessary credential or replication-verification patch must be built, pinned and validated before release; an upstream version label alone does not establish that property.
Choose the data layout deliberately#
The current configuration contract supports one standalone tablet in one shard, or a cluster with 1, 2, 4 or 8 shards and one to five replicas per shard. At most 48 tablets are allowed. Each MySQL member needs at least 500m CPU and 1Gi memory, plus the supporting allocations above.
Multiple shards require explicit table entries with integer hash sharding columns. A valid VSchema tells vtgate where rows belong. Creating infrastructure shards without table routing metadata is insufficient.
The following is a source-contract example, not an available deployment recipe:
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"
Use a real approved native backup destination ID and revision when the runtime becomes available. The destination is required for member recovery. The placeholder above intentionally cannot pass ID validation. Table names and sharding columns are configuration metadata; credentials and arbitrary controller flags do not belong in this table.
The proposed transaction mode is SINGLE. Do not assume cross-shard transaction guarantees. Live resharding is outside this contract. Rebuilding a compatible separate target and reviewing cutover has a different scope from online resharding.
Routing and trust#
Applications connect to vtgate using the MySQL protocol and a restricted application account. vtgate performs query routing; its existence does not make all MySQL syntax or transaction patterns compatible with a sharded application. Validate the application's queries, key choices and retry behavior.
The implementation requires client TLS with a per-database issuer, mutually verified topology connections and verification of internal gRPC identities. MySQL replication identity checks are also required. The current upstream replication setup needs additional work to establish server identity verification; a client-to-vtgate TLS pass cannot substitute for this check.
Test unrelated issuers, wrong hostnames, plaintext refusal and renewed identities on each connection layer. Applications must receive only their restricted account and public trust. Server CA keys, topology credentials and operator credentials must remain unavailable to them.
Backup and isolated recovery#
Two recovery needs must be distinguished. Native member recovery seeds or replaces tablets using the approved backup destination. Managed user recovery restores application data into a separate compatible database and requires inspection before cutover. Both still need native acceptance.
The managed archive format includes exact engine versions, the VSchema, shard map and a bounded logical stream for each shard. Each stream has a SHA-256 checksum; the shared backup service supplies outer encryption and authentication. Per-shard read-lock captures do not establish one transactionally consistent snapshot across all shards.
Recovery must validate the complete archive before writing, retain the source, revoke existing target sessions, keep target ingress closed through inspection and prove that restored routing stays independent of the source. A shared ReadWriteOnce backup volume is not a substitute for a recovery design across nodes.
Remaining acceptance#
The implementation must prove native bootstrap, shard routing, application grants, replicated writes, primary replacement, empty-member seeding, verified internal TLS, renewal, scoped RBAC, retained source data, isolated restore and ordered cleanup. Stable tablet names and DNS must survive controller reconciliation. Test cancellation and a restart of the management process while durable work is active.
These are pending gates, not a checklist claimed as passed. No physical zone/provider resilience, throughput result or production availability is established. Oracle Enterprise and public database endpoints are unrelated work and do not become available with Vitess.
Source and upstream concepts#
In the source checkout, start with internal/database/vitess.go, internal/database/vitess_archive.go and internal/cluster/database_vitess*.go. The public repository will carry the release-qualified implementation. Use the Vitess documentation to review VSchema, vindexes, transaction modes and backup behavior for the selected version.