byoc-architecture#23280
Open
wildpcww wants to merge 1 commit into
Open
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
ti-chi-bot
Bot
added
contribution
|
@wildpcww: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces documentation for TiDB Cloud BYOC (Bring Your Own Cloud), adding a detailed architecture section in architecture-concepts.md and updating the onboarding overview in byoc-onboarding-overview.md to link to it. The review feedback focuses on aligning the new content with the style guide by preferring active voice, writing in the second person, maintaining consistent capitalization in lists, removing redundant paragraphs, and using relative paths for internal links.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Comment on lines
+97
to
+107
| TiDB Cloud BYOC (Bring Your Own Cloud) is designed for organizations that need stronger control over data location, cloud resources, network boundaries, and compliance posture while still using TiDB Cloud as a managed service. With BYOC, the TiDB Cloud control plane is managed by PingCAP, while the TiDB data plane runs in your own cloud account. | ||
|
|
||
| BYOC provides the following features: | ||
|
|
||
| - **Customer-owned data plane**: keeps TiDB service resources, data storage, and network boundaries in your cloud account. | ||
| - **Managed operations**: uses TiDB Cloud for deployment, scaling, monitoring, upgrades, backup, and lifecycle management. | ||
| - **Flexible high availability**: supports both Single-AZ and Multi-AZ deployments so you can choose between lower-latency zonal deployment and higher-resilience regional deployment. | ||
| - **Cloud-account-level controls**: lets you apply your own cloud policies for networking, security, auditability, and compliance. | ||
| - **Private connectivity**: supports private network access patterns such as VPC peering, depending on your BYOC configuration. | ||
|
|
||
| To meet different workload requirements, TiDB Cloud BYOC supports both Single-AZ and Multi-AZ deployments, enabling you to choose between lower-latency zonal deployment and higher-resilience deployment across multiple availability zones. |
Contributor
There was a problem hiding this comment.
To improve readability and adhere to the style guide, let's make the following enhancements:
- Change the passive voice "is managed by PingCAP" to active voice ("PingCAP manages...").
- Capitalize the first letter of the descriptions in the bullet list for consistency.
- Remove the redundant paragraph about Single-AZ and Multi-AZ deployments, as this is already covered in the "Flexible high availability" bullet point.
Suggested change
| TiDB Cloud BYOC (Bring Your Own Cloud) is designed for organizations that need stronger control over data location, cloud resources, network boundaries, and compliance posture while still using TiDB Cloud as a managed service. With BYOC, the TiDB Cloud control plane is managed by PingCAP, while the TiDB data plane runs in your own cloud account. | |
| BYOC provides the following features: | |
| - **Customer-owned data plane**: keeps TiDB service resources, data storage, and network boundaries in your cloud account. | |
| - **Managed operations**: uses TiDB Cloud for deployment, scaling, monitoring, upgrades, backup, and lifecycle management. | |
| - **Flexible high availability**: supports both Single-AZ and Multi-AZ deployments so you can choose between lower-latency zonal deployment and higher-resilience regional deployment. | |
| - **Cloud-account-level controls**: lets you apply your own cloud policies for networking, security, auditability, and compliance. | |
| - **Private connectivity**: supports private network access patterns such as VPC peering, depending on your BYOC configuration. | |
| To meet different workload requirements, TiDB Cloud BYOC supports both Single-AZ and Multi-AZ deployments, enabling you to choose between lower-latency zonal deployment and higher-resilience deployment across multiple availability zones. | |
| TiDB Cloud BYOC (Bring Your Own Cloud) is designed for organizations that need stronger control over data location, cloud resources, network boundaries, and compliance posture while still using TiDB Cloud as a managed service. With BYOC, PingCAP manages the TiDB Cloud control plane, while the TiDB data plane runs in your own cloud account. | |
| BYOC provides the following features: | |
| - **Customer-owned data plane**: Keeps TiDB service resources, data storage, and network boundaries in your cloud account. | |
| - **Managed operations**: Uses TiDB Cloud for deployment, scaling, monitoring, upgrades, backup, and lifecycle management. | |
| - **Flexible high availability**: Supports both Single-AZ and Multi-AZ deployments so you can choose between lower-latency zonal deployment and higher-resilience regional deployment. | |
| - **Cloud-account-level controls**: Lets you apply your own cloud policies for networking, security, auditability, and compliance. | |
| - **Private connectivity**: Supports private network access patterns such as VPC peering, depending on your BYOC configuration. |
References
- Avoid passive voice overuse and unnecessary repetition. Capitalize list items consistently. (link)
Comment on lines
+113
to
+117
| - **TiDB Cloud control plane**: provides the TiDB Cloud console, organization and project management, billing, lifecycle orchestration, monitoring views, alerting, and maintenance workflows. | ||
| - **BYOC data plane**: runs the TiDB service and related infrastructure in your cloud account. TiDB Cloud operates this environment based on the permissions granted during BYOC onboarding. | ||
| - **TiDB Service VPC**: hosts TiDB service components that serve application traffic. | ||
| - **Observability Service VPC**: hosts observability components used to collect metrics, logs, and operational data for the BYOC deployment. | ||
| - **Application VPC**: hosts your applications. You manage this VPC and configure network connectivity to access the BYOC TiDB service. |
Contributor
There was a problem hiding this comment.
Let's capitalize the first letter of the descriptions in the bullet list for consistency and change the passive phrase "permissions granted" to active voice ("permissions you grant").
Suggested change
| - **TiDB Cloud control plane**: provides the TiDB Cloud console, organization and project management, billing, lifecycle orchestration, monitoring views, alerting, and maintenance workflows. | |
| - **BYOC data plane**: runs the TiDB service and related infrastructure in your cloud account. TiDB Cloud operates this environment based on the permissions granted during BYOC onboarding. | |
| - **TiDB Service VPC**: hosts TiDB service components that serve application traffic. | |
| - **Observability Service VPC**: hosts observability components used to collect metrics, logs, and operational data for the BYOC deployment. | |
| - **Application VPC**: hosts your applications. You manage this VPC and configure network connectivity to access the BYOC TiDB service. | |
| - **TiDB Cloud control plane**: Provides the TiDB Cloud console, organization and project management, billing, lifecycle orchestration, monitoring views, alerting, and maintenance workflows. | |
| - **BYOC data plane**: Runs the TiDB service and related infrastructure in your cloud account. TiDB Cloud operates this environment based on the permissions you grant during BYOC onboarding. | |
| - **TiDB Service VPC**: Hosts TiDB service components that serve application traffic. | |
| - **Observability Service VPC**: Hosts observability components used to collect metrics, logs, and operational data for the BYOC deployment. | |
| - **Application VPC**: Hosts your applications. You manage this VPC and configure network connectivity to access the BYOC TiDB service. |
References
- Avoid passive voice and maintain consistent capitalization in lists. (link)
Comment on lines
+119
to
+121
| Each BYOC region is deployed and operated independently. When a BYOC region is added, TiDB Cloud provisions the required regional resources in your cloud account. Because each BYOC region has its own data-plane setup, regions do not share a single TiDB Service VPC or Observability Service VPC. | ||
|
|
||
| Your applications connect to a BYOC TiDB instance from your application environment. Depending on your BYOC configuration, connectivity can use private or controlled public access patterns. For private access, BYOC can use VPC peering or other private connectivity options. |
Contributor
There was a problem hiding this comment.
Let's rewrite these paragraphs to use active voice and second person ("you"), which makes the documentation more engaging and direct.
Suggested change
| Each BYOC region is deployed and operated independently. When a BYOC region is added, TiDB Cloud provisions the required regional resources in your cloud account. Because each BYOC region has its own data-plane setup, regions do not share a single TiDB Service VPC or Observability Service VPC. | |
| Your applications connect to a BYOC TiDB instance from your application environment. Depending on your BYOC configuration, connectivity can use private or controlled public access patterns. For private access, BYOC can use VPC peering or other private connectivity options. | |
| TiDB Cloud deploys and operates each BYOC region independently. When you add a BYOC region, TiDB Cloud provisions the required regional resources in your cloud account. Because each BYOC region has its own data-plane setup, regions do not share a single TiDB Service VPC or Observability Service VPC. | |
| Your applications connect to a BYOC TiDB instance from your application environment. Depending on your BYOC configuration, you can use private or controlled public access patterns. For private access, you can use VPC peering or other private connectivity options. |
References
- Write in second person ("you") and prefer active voice. (link)
Comment on lines
+30
to
+32
| TiDB Cloud BYOC uses a split-plane architecture. The TiDB Cloud control plane is managed by PingCAP, while the TiDB data plane runs in your own cloud account. | ||
|
|
||
| > **Note:** | ||
| > | ||
| > This architecture defaults to a Multi-AZ deployment for production high availability, but also supports a Single-AZ deployment for Proof of Concept (POC) or cost optimization scenarios. | ||
|
|
||
|  | ||
| Before you start onboarding, review the [TiDB Cloud BYOC architecture](https://docs.tidb.io/tidbcloud/architecture-concepts/?plan=byoc#tidb-cloud-byoc) to understand the BYOC control plane, data plane, network connectivity model, and high availability options. |
Contributor
There was a problem hiding this comment.
Let's use active voice ("PingCAP manages...") and convert the absolute URL to a relative path to ensure the link works correctly across different documentation environments (e.g., staging, local preview).
Suggested change
| TiDB Cloud BYOC uses a split-plane architecture. The TiDB Cloud control plane is managed by PingCAP, while the TiDB data plane runs in your own cloud account. | |
| > **Note:** | |
| > | |
| > This architecture defaults to a Multi-AZ deployment for production high availability, but also supports a Single-AZ deployment for Proof of Concept (POC) or cost optimization scenarios. | |
|  | |
| Before you start onboarding, review the [TiDB Cloud BYOC architecture](https://docs.tidb.io/tidbcloud/architecture-concepts/?plan=byoc#tidb-cloud-byoc) to understand the BYOC control plane, data plane, network connectivity model, and high availability options. | |
| TiDB Cloud BYOC uses a split-plane architecture. PingCAP manages the TiDB Cloud control plane, while the TiDB data plane runs in your own cloud account. | |
| Before you start onboarding, review the [TiDB Cloud BYOC architecture](/tidb-cloud/architecture-concepts.md?plan=byoc#tidb-cloud-byoc) to understand the BYOC control plane, data plane, network connectivity model, and high availability options. |
References
- Avoid passive voice and use relative paths for internal links. (link)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First-time contributors' checklist
What is changed, added or deleted? (Required)
Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions.
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?