<\/span>Why Companies Choose a DBaaS Solution<\/span><\/h2>\n\n\n\nA company might choose a DBaaS solution for several reasons. However, at the top of the list for many are scalability, availability, and performance. It\u2019s important to note that these three factors are present in all DBaaS product offerings, though each offering provides a different level of each factor. The level of any one of these is defined by the underlying technology that the DBaaS offering is based on. It\u2019s helpful to think of these characteristics as tunables, with each on its own sliding scale. We\u2019ll define the scale with the stop points of Basic, Advanced, and Extreme. <\/p>\n\n\n\n
In the example below, we use this scale to represent defined product classifications or verticals with the AWS offerings and TiDB.<\/p>\n\n\n\n
<\/p>\n\n\n\n![\"Product](\"https:\/\/lh6.googleusercontent.com\/p7NYIZfRiwO0z9rPbUMdvjAOEVhANXcOg17N5fBOjPDUk2KCTJvAqZ2VqkpOML9ECvLpLbJm7pGw_LCbc3-b6QfTeW8Umvt2sxDXMZp9o5WeDYonOVJ9UyM7jCPEwyBWf4NhjD2KO6RHyNxKUrm7Xx0\")
<\/figure>\n\n\n\nFigure 1. Product classifications between Amazon RDS, Amazon Aurora, and TiDB.<\/em><\/p>\n\n\n\nWith the understanding that each of these products has measurable and distinct patterns of scalability, availability, and performance, we can take our labels of Basic, Advanced, and Extreme and use those as product verticals in the DBaaS market.<\/p>\n\n\n\n
<\/span>DBaaS Scalability<\/span><\/h2>\n\n\n\nLet\u2019s now take a look at the three characteristics of scalability, availability, and performance and how they map to the three verticals of Basic, Advanced, and Extreme. We\u2019ll start with Scalability in the following diagram. <\/p>\n\n\n\n
<\/p>\n\n\n\n![\"Scaling](\"https:\/\/lh6.googleusercontent.com\/59o6PaKaInh_p8GsVrrJSj8yDbpW5BMhvtIAYJ3btQxsCXPbcW2IyqvZFPE0PKNhZDL9feLJoOSypz1cJA9SgJzTBK-0iUoV1CfyviJyKLAkwG24yd1dRJyJxkq72kSYxYq5i6kubPEha-aEuVQOtyk\")
<\/figure>\n\n\n\nFigure 2. Scaling capabilities mapped across Amazon RDS, Amazon Aurora, and TiDB.<\/em><\/p>\n\n\n\nFrom the diagram above, we can see that the Basic Scaling vertical is primarily based on vertical scaling and the scaling of read traffic. Vertical scaling is the ability to move from smaller database instances to larger database instances. For many, this works until they out grow the capacity of the largest available cloud database instance. They can squeeze out another level of scalability by separating out their read-only traffic and sending it to replicated databases known as read replicas. But this only helps them with read traffic. Their write workload is still bound by the capacity of the single node designated as the primary in their replication architecture. <\/p>\n\n\n\n
At this point, growing further means they\u2019ll need to move up to something with higher scalability and more advanced features. In the Advanced Scaling vertical, we have features such as the separation of compute and storage<\/a> as well as the ability to scale data volumes horizontally<\/a>. These capabilities provide significant improvements in the ability to scale-out data volume. However, the Advanced Scaling product class is still bound by the inability to scale writes. Even at this level of product sophistication, the architecture of the systems in this class still only allows for read workload scaling. This helps with read concurrency, but it does not help with write workload concurrency.<\/p>\n\n\n\n<\/span>DBaaS Availability<\/span><\/h2>\n\n\n\nWhen considering availability, we notice that the same architectural characteristics impacting the scaling capabilities also impact the availability capacity within each product class. <\/p>\n\n\n\n
<\/p>\n\n\n\n![\"Availability](\"https:\/\/lh3.googleusercontent.com\/5o4JhlfbIoZXt0J-YxkR4xXZwihDZXOS9lFPWOZINpNIlOx0VvrTEAeLRGHpvsPKBhk1Y8Jf_GUp1tFczmGlGPS3fSntq1HfzAR6-JoDaA6HYD5N7s-4KTQzXwsWKru2peecaEl7GOYQmK2Zx2laHbc\")
<\/figure>\n\n\n\nFigure 3. Availability capabilities mapped across Amazon RDS, Amazon Aurora, and TiDB.<\/em><\/p>\n\n\n\nThe primary \/ secondary replication architecture of the Basic and Advanced tiers define the minimum failover time during an outage. Contrast this with the Extreme product class\u2014where all database nodes are capable of reads and writes simultaneously<\/a>\u2014and we see a clear advantage from an availability perspective.<\/p>\n\n\n\n<\/span>DBaaS Performance<\/span><\/h2>\n\n\n\nIn keeping with the established theme, we again see how similar platform characteristics also directly impact performance.<\/p>\n\n\n\n
<\/p>\n\n\n\n![\"Performance](\"https:\/\/lh4.googleusercontent.com\/k_-_DNwhfkna1kGDG0G7Tr3j_ZeVjFREBu5znWFnpVJkpdG7FstjFHMr1u5C6Wf-DubDJLARuxFUky5qze8sBize_dS52QVIQIoOTRMD6dGlAb0uqQEblEa3Ojoca2XfMGx-5Bs33A9FdmWCL05TJfU\")
<\/figure>\n\n\n\nFigure 4.<\/em> Performance capabilities mapped across Amazon RDS, Amazon Aurora, and TiDB.<\/em><\/p>\n\n\n\nOnly scaling read traffic means that there is a performance plateau measured in writes per second. This plateau will also create a defined limitation on the number of concurrent transactions that can be processed at any given time. Extreme Scaling DBaaS products do not experience this write or concurrency limitation. In the case of TiDB, all database-compute nodes service read and write traffic simultaneously. Plus, you have the ability to scale the number of database-compute servers up or down, whenever you choose.<\/p>\n\n\n\n
The final advantage that a platform in the Extreme category\u2014such as TiDB\u2014delivers is the ability to handle mixed workloads<\/a>. TiDB allows for the storage of data in row and columnar formats, facilitating both transactional and analytical workloads on the same data.<\/p>\n\n\n\n<\/span>Comparing AWS and GCP DBaaS Offerings with TiDB<\/span><\/h2>\n\n\n\nNow that we understand the unique capabilities within each product vertical, let\u2019s align the product offerings from both AWS and Google GCP to these verticals. While both cloud providers do offer a breadth of database vendor options in the Basic DBaaS category, we are going to focus exclusively on their MySQL and PostgreSQL offerings, as illustrated in the below diagram.<\/p>\n\n\n\n
<\/p>\n\n\n\n![\"Comparing](\"https:\/\/lh5.googleusercontent.com\/SKIBGLEo1dNePDU9SE_awCIyOa8xgdkeJFgCwQwPXwsTKf3wMcclkMWEzR6lXojY9AoD1xR0MNiLVEYvM-1lyUNP1mBtpPnFv3zqgUod5s2ZBRovUkkcmRnnYjE2sfKjqzIW-pPe9D-4KzE3Xye9Df0\")
<\/figure>\n\n\n\nFigure 5. Comparing AWS and GCP MySQL and PostgreSQL offerings with TiDB.<\/em><\/p>\n\n\n\nThe first thing we notice in the chart above is that both cloud providers are pretty much equal in their offerings for a Basic DBaaS. AWS offers RDS in MySQL and PostgreSQL. Meanwhile, GCP offers CloudSQL in MySQL and PostgreSQL variants. But we start to notice differences when we scale up to the middle tier, or Advanced levels of scaling, performance, and availability. <\/p>\n\n\n\n
The Amazon RDS Aurora option is available in both MySQL and PostgreSQL. However, on the GCP side, the only comparable option in this category is AlloyDB, which is a PostgreSQL-compatible DBaaS. There is no MySQL option offered in GCP for this product class. The gap becomes even more interesting when we look at the Extreme vertical. This is the vertical where distributed SQL databases<\/a> shine. Between both vendors, the only option offered in this vertical is Spanner from GCP.<\/p>\n\n\n\n<\/span>TiDB: Scalability, Availability, and Performance for Extreme Workloads <\/span><\/h2>\n\n\n\nThe areas where we have identified product gaps are telling us a few things. First, we know that there are workloads in production in those product gaps. Those workloads are running on bespoke custom-built, self-managed solutions. Second, those solutions often employ technologies like manual sharding to accomplish scale numbers measured in 10s to 100s of terabytes of data. The costs and risk levels associated with these solutions are immense. This is where an option such as TiDB brings significant value.
PingCAP, the company behind TiDB, offers a scalable, highly-available, and performant cloud DBaaS called TiDB Dedicated<\/a>\u2014and it\u2019s deployable in both AWS and GCP. The TiDB database employs a distributed, horizontally scalable architecture that enables it to handle massive workloads across multiple nodes. Its use of distributed transactions<\/a> \uadf8\ub9ac\uace0 fully-automated horizontal sharding<\/a> allows for linear scalability and high availability. This makes TiDB Dedicated suitable for applications with demanding performance requirements. <\/p>\n\n\n\nTiDB Dedicated handles operational tasks, such as database setup, configuration, monitoring, and maintenance, by default. This can relieve the burden of managing and maintaining the database infrastructure, allowing companies to focus on their core business activities. <\/p>\n\n\n\n
<\/figure>\n\n\n\nFigure 1. Product classifications between Amazon RDS, Amazon Aurora, and TiDB.<\/em><\/p>\n\n\n\n With the understanding that each of these products has measurable and distinct patterns of scalability, availability, and performance, we can take our labels of Basic, Advanced, and Extreme and use those as product verticals in the DBaaS market.<\/p>\n\n\n\n Let\u2019s now take a look at the three characteristics of scalability, availability, and performance and how they map to the three verticals of Basic, Advanced, and Extreme. We\u2019ll start with Scalability in the following diagram. <\/p>\n\n\n\n <\/p>\n\n\n\n Figure 2. Scaling capabilities mapped across Amazon RDS, Amazon Aurora, and TiDB.<\/em><\/p>\n\n\n\n From the diagram above, we can see that the Basic Scaling vertical is primarily based on vertical scaling and the scaling of read traffic. Vertical scaling is the ability to move from smaller database instances to larger database instances. For many, this works until they out grow the capacity of the largest available cloud database instance. They can squeeze out another level of scalability by separating out their read-only traffic and sending it to replicated databases known as read replicas. But this only helps them with read traffic. Their write workload is still bound by the capacity of the single node designated as the primary in their replication architecture. <\/p>\n\n\n\n At this point, growing further means they\u2019ll need to move up to something with higher scalability and more advanced features. In the Advanced Scaling vertical, we have features such as the separation of compute and storage<\/a> as well as the ability to scale data volumes horizontally<\/a>. These capabilities provide significant improvements in the ability to scale-out data volume. However, the Advanced Scaling product class is still bound by the inability to scale writes. Even at this level of product sophistication, the architecture of the systems in this class still only allows for read workload scaling. This helps with read concurrency, but it does not help with write workload concurrency.<\/p>\n\n\n\n When considering availability, we notice that the same architectural characteristics impacting the scaling capabilities also impact the availability capacity within each product class. <\/p>\n\n\n\n <\/p>\n\n\n\n Figure 3. Availability capabilities mapped across Amazon RDS, Amazon Aurora, and TiDB.<\/em><\/p>\n\n\n\n The primary \/ secondary replication architecture of the Basic and Advanced tiers define the minimum failover time during an outage. Contrast this with the Extreme product class\u2014where all database nodes are capable of reads and writes simultaneously<\/a>\u2014and we see a clear advantage from an availability perspective.<\/p>\n\n\n\n In keeping with the established theme, we again see how similar platform characteristics also directly impact performance.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 4.<\/em> Performance capabilities mapped across Amazon RDS, Amazon Aurora, and TiDB.<\/em><\/p>\n\n\n\n Only scaling read traffic means that there is a performance plateau measured in writes per second. This plateau will also create a defined limitation on the number of concurrent transactions that can be processed at any given time. Extreme Scaling DBaaS products do not experience this write or concurrency limitation. In the case of TiDB, all database-compute nodes service read and write traffic simultaneously. Plus, you have the ability to scale the number of database-compute servers up or down, whenever you choose.<\/p>\n\n\n\n The final advantage that a platform in the Extreme category\u2014such as TiDB\u2014delivers is the ability to handle mixed workloads<\/a>. TiDB allows for the storage of data in row and columnar formats, facilitating both transactional and analytical workloads on the same data.<\/p>\n\n\n\n Now that we understand the unique capabilities within each product vertical, let\u2019s align the product offerings from both AWS and Google GCP to these verticals. While both cloud providers do offer a breadth of database vendor options in the Basic DBaaS category, we are going to focus exclusively on their MySQL and PostgreSQL offerings, as illustrated in the below diagram.<\/p>\n\n\n\n <\/p>\n\n\n\n Figure 5. Comparing AWS and GCP MySQL and PostgreSQL offerings with TiDB.<\/em><\/p>\n\n\n\n The first thing we notice in the chart above is that both cloud providers are pretty much equal in their offerings for a Basic DBaaS. AWS offers RDS in MySQL and PostgreSQL. Meanwhile, GCP offers CloudSQL in MySQL and PostgreSQL variants. But we start to notice differences when we scale up to the middle tier, or Advanced levels of scaling, performance, and availability. <\/p>\n\n\n\n The Amazon RDS Aurora option is available in both MySQL and PostgreSQL. However, on the GCP side, the only comparable option in this category is AlloyDB, which is a PostgreSQL-compatible DBaaS. There is no MySQL option offered in GCP for this product class. The gap becomes even more interesting when we look at the Extreme vertical. This is the vertical where distributed SQL databases<\/a> shine. Between both vendors, the only option offered in this vertical is Spanner from GCP.<\/p>\n\n\n\n The areas where we have identified product gaps are telling us a few things. First, we know that there are workloads in production in those product gaps. Those workloads are running on bespoke custom-built, self-managed solutions. Second, those solutions often employ technologies like manual sharding to accomplish scale numbers measured in 10s to 100s of terabytes of data. The costs and risk levels associated with these solutions are immense. This is where an option such as TiDB brings significant value. TiDB Dedicated handles operational tasks, such as database setup, configuration, monitoring, and maintenance, by default. This can relieve the burden of managing and maintaining the database infrastructure, allowing companies to focus on their core business activities. <\/p>\n\n\n\n<\/span>DBaaS Scalability<\/span><\/h2>\n\n\n\n
<\/span>DBaaS Availability<\/span><\/h2>\n\n\n\n
<\/span>DBaaS Performance<\/span><\/h2>\n\n\n\n
<\/span>Comparing AWS and GCP DBaaS Offerings with TiDB<\/span><\/h2>\n\n\n\n
<\/span>TiDB: Scalability, Availability, and Performance for Extreme Workloads <\/span><\/h2>\n\n\n\n
PingCAP, the company behind TiDB, offers a scalable, highly-available, and performant cloud DBaaS called TiDB Dedicated<\/a>\u2014and it\u2019s deployable in both AWS and GCP. The TiDB database employs a distributed, horizontally scalable architecture that enables it to handle massive workloads across multiple nodes. Its use of distributed transactions<\/a> \uadf8\ub9ac\uace0 fully-automated horizontal sharding<\/a> allows for linear scalability and high availability. This makes TiDB Dedicated suitable for applications with demanding performance requirements. <\/p>\n\n\n\n