White Paper

Amazon
Aurora
TiDB
A Guide to Distributed
Database Architectures
Table of Contents

Introduction 3

Comparing Database Architecture 4

TiDB Architecture 4

Amazon Aurora Architecture 5

Comparative Analysis 5

Comparing Database Scalability 5

Scaling TiDB 6

Scaling Amazon Aurora 8

Comparative Analysis 10

Comparing Database Reliability 12

TiDB Reliability 13

Amazon Aurora Reliability 13

Comparative Analysis 14

Multi-Tenant Environments: A Unique Deployment Scenario 15

Placement Rules 15

Resource Control 16

Comparing Pricing and Costs 16

TiDB Pricing 16

Amazon Aurora Pricing 17

Comparative Analysis 17

Conclusion 18

Appendix: Feature Comparison Table 19

Amazon Aurora vs. TiDB 2

Introduction

Businesses are increasingly reliant on robust Amazon Aurora, part of Amazon Web
and scalable database solutions to manage Services (AWS), is a fully-managed relational
their growing data needs. Two prominent DBaaS available in both MySQL- and
technologies have emerged to offer unique PostgreSQL-compatible versions. It’s
features and capabilities: TiDB and Amazon typically used in a wide range of applications,
Aurora. from small-scale projects to large enterprise
systems. Its performance and compatibility
TiDB is an advanced open-source, distributed with existing MySQL and PostgreSQL
SQL database that’s MySQL compatible and applications make it a go-to choice for
can be deployed as a fully-managed, businesses looking to migrate their existing
Database-as-a-Service (DBaaS). TiDB is relational databases to the cloud.
designed to offer horizontal scalability, strong
consistency, and high availability. It also Both TiDB and Amazon Aurora offer
supports Hybrid Transactional/Analytical MySQL-compatible solutions that represent
Processing (HTAP) capabilities, allowing for significant advancements in database
both transactional and analytical processing technology. However, they cater to different
within the same database. TiDB stands out for needs and use cases. TiDB’s HTAP capabilities,
its high performance and scalability for both strong consistency, and read/write scalability
read and write workloads, making it a model make it ideal for real-time,
versatile choice for businesses dealing with data-intensive applications. On the other
large-scale, complex data scenarios. hand, Amazon Aurora’s read performance
and ease of management make it suitable
Typically, TiDB is used in scenarios where for a broad range of applications, particularly
businesses require strong consistency and where compatibility with MySQL or PostgreSQL
real-time analytics on a massive data is a high priority.
footprint. It’s well-suited for industries like
e-commerce, gaming, and financial services, This white paper dissects and evaluates the
where there is a need to handle large volumes distinct characteristics, performance metrics,
of transactions while simultaneously scalability options, cost-effectiveness, and
performing analytical queries on the same ease of use of both database platforms. It
dataset. Its cloud-native architecture also provides valuable insights for organizations
makes it a popular choice for organizations in their quest to optimize data management
who want the flexibility and scalability of cloud and operational efficiency.
computing.

Amazon Aurora vs. TiDB 3

Comparing Database Architectures
When comparing the architectural differences between TiDB and Amazon Aurora, we need to dive
into two distinct approaches to database design and management. Both database architectures
rely on the concept of a clear separation between compute and storage layers. This design is
pivotal for large scale cloud-based databases as it offers significant advantages in scalability,
reliability, and cost-efficiency over traditional monolithic architectures.

TiDB, developed by PingCAP, offers a distributed SQL architecture that emphasizes horizontal
scalability across multiple scaling vectors. On the other hand, Amazon Aurora leverages an
approach similar to a traditional relational database but with significant enhancements for
storage scalability. These architectural distinctions underscore the varied approaches to data
management, scalability, and performance optimization. They also reflect the diverse needs and
challenges faced by modern businesses in data handling and processing.

TiDB Architecture
TiDB’s strength is found in its approach to separating compute and storage. The TiDB cluster
consists of three main components, as shown in the below diagram:

1. TiDB server: A stateless SQL layer that’s

MySQL compatible and decouples
compute from storage to simplify scaling.
Each node can take both reads and writes.

2. Placement Driver (PD) server: A cluster

manager that dynamically balances the
data load in real time while mitigating
hotspots and providing for the
implementation of customized scheduling
policies.

3. Storage server: A distributed storage layer

that offers built-in high availability and
strong ACID consistency that can
auto-scale to hundreds of nodes and
petabytes of data.

Amazon Aurora vs. TiDB 4

TiDB’s architecture allows for scalability across • Data consistency: TiDB uses the
multiple vectors such as data volume, Raft consensus algorithm for strong data
concurrency, and query complexity, while also consistency, whereas Amazon Aurora re-
maintaining strong consistency with the lies on a quorum system for writes across
added benefits of cloud management. multiple AZs.

• Flexibility: TiDB’s MySQL compatibility and

Amazon Aurora its distributed nature offer flexibility in
Architecture deployment and scalability. Amazon
Aurora is more tightly integrated with the
Amazon Aurora’s architecture also
AWS ecosystem.
implements separation of compute and
storage layers. The components of Amazon
This section provided a high-level overview of
Aurora include:
the architectures of TiDB and Amazon Aurora.
Subsequent chapters will dive deeper into
1. Aurora database engine: Custom-built for
performance, scalability, and other critical
the cloud, it processes queries and
aspects of these database systems.
transactions.

2. Distributed, fault-tolerant storage:

Automatically replicated across multiple
Comparing Database
Availability Zones (AZs). Scalability
TiDB’s architecture is uniquely designed to
Aurora’s design focuses on read performance,
address scalability across three critical
data durability, and scalability of data volume,
vectors: data volume, concurrency, and
with an emphasis on automating
workload complexity.
administrative tasks.

Comparative Analysis
Both TiDB and Amazon Aurora offer horizontal
scalability. Amazon Aurora’s compute tier is
reminiscent of a more traditional
single-primary, multi-read model. TiDB’s
architecture offers the benefit of a multi-write
and multi-read implementation. Additional
considerations include:

Amazon Aurora vs. TiDB 5

Scaling TiDB
Scalability in TiDB is achieved through three core components of the database: TiKV for data
volume, TiDB server for concurrency, and TiFlash for workload complexity, as illustrated below.

Data Volume Scalability with TiKV

TiKV is a distributed key-value storage engine at the heart of the TiDB platform. It is responsible for
storing the actual data in a distributed manner, in addition to:

• Scalability: TiKV enables TiDB to scale horizontally with data volume. As the amount of data
grows, you can simply add more TiKV nodes to the cluster. This distributes the data across a
larger set of nodes, preventing any single node from becoming a bottleneck.

• Database sharding: TiKV automatically splits data into small, manageable chunks or “regions.”
As the data volume increases, these regions are distributed across the TiKV nodes in the
cluster, ensuring balanced data distribution and storage scalability.

Amazon Aurora vs. TiDB 6

Concurrency Scalability both transactional and analytical

with TiDB Server workloads efficiently, scaling as the

complexity and requirements of these
TiDB server is the SQL layer of the TiDB platform, workloads increase.
where SQL queries are processed. The TiDB
server translates SQL queries into key-value TiDB’s architecture is adept at scaling across

operations for TiKV. multiple dimensions – handling larger data

volumes through TiKV, managing higher

The TiDB server is stateless and can be scaled concurrency through the TiDB server, and

out to increase the number of read and write addressing complex analytical workloads with

connections that can be handled concurrently. TiFlash. This multi-vector scalability makes

By adding more TiDB server nodes, the system TiDB a versatile and robust choice for busi-

can handle more concurrent requests, nesses facing diverse and evolving data

distributing the load and preventing any single management challenges.

node from being overwhelmed by too many

requests.

Workload Complexity
Scalability with TiFlash
TiFlash is a columnar storage extension of TiDB,
designed to efficiently process complex
analytical queries. It can also handle:

• Complex workloads: TiFlash allows TiDB to

scale with the complexity of the workload.
For analytical queries that involve large
scans, aggregations, and calculations,
TiFlash provides faster query processing by
leveraging its columnar storage
architecture.

• Real-time HTAP: TiFlash synchronizes data

in real-time from TiKV, enabling HTAP. This
means that the same platform can handle

Amazon Aurora vs. TiDB 7

Scaling Amazon Aurora
Amazon Aurora’s architecture is designed to provide scalability across different vectors, primarily
focusing on data volume and read concurrency, as shown in the below diagram.

This scalability is achieved through two key components: Aurora’s distributed storage for data
voume and the addition of replica instances for read concurrency.

Data Volume Scalability with Amazon Aurora’s

Distributed Storage
Amazon Aurora uses a distributed, fault-tolerant, self-healing storage system that
automatically scales as the volume of data increases. This storage layer is independent of the
compute layer, allowing for greater flexibility and scalability. It also enables:

Amazon Aurora vs. TiDB 8

• Automatic scaling: One of the standout handling write operations while the read
features of Amazon Aurora’s storage replicas handle the read queries.
system is its ability to automatically scale
in 10GB increments, up to a maximum of • Enhanced availability: In addition to pro-
128TB. This means that the storage viding scalability for read operations, these
capacity grows with the database’s needs, replicas also enhance the overall availabil-
without requiring manual intervention or ity and fault tolerance of the
downtime for scaling. database. If the primary instance fails, one
• Data distribution and durability: Amazon of the read replicas can be quickly
Aurora stores copies of the data in multiple promoted to become the new primary,
AZs, ensuring high durability and ensuring minimal disruption.
availability. This distributed nature of the
storage also contributes to the overall Amazon Aurora’s architecture addresses
performance and scalability of the scalability through its innovative distributed
database, as it allows for parallel and storage system. It effortlessly scales with data
distributed processing of data. volume and through the use of read
replicas, which provide scalability for
read-heavy workloads. This dual approach
Read Concurrency allows Amazon Aurora to handle large and
Scalability with Replica growing datasets efficiently while maintaining
Instances high performance and availability for
read-intensive applications.
Amazon Aurora allows for the creation of up
to 15 read replicas to handle high read
traffic. These replicas share the same
underlying storage as the primary instance,
which minimizes replication lag and ensures
data consistency. Additional capabilities
include:

• Load balancing and read scaling: The

read replicas can be used to balance the
read load, effectively scaling the
database’s capacity to handle high levels
of read traffic. This is particularly useful for
applications with high read-to-write ratios,
where the primary instance can focus on

Amazon Aurora vs. TiDB 9

 Comparative Analysis
TiDB and Amazon Aurora architectures present distinct approaches to database scalability, each
tailored to different use cases and performance needs. The below diagram and table demonstrate
the results seen in PingCAP’s own comparative testing.

Amazon Aurora TiDB

Single-point write, there is a single-machine Multi-point write, scalable, 300,000 + QPS

bottleneck, 20,000 QPS

Single point of failure can affect the cluster, 100% A single point of failure affects only 1/n flow, RTO 30s
write traffic, RTO 120s

Applications require read-write separation Multi-point read and write, the application does not
need read-write separation

Amazon Aurora vs. TiDB 10

TiDB offers a comprehensive scalability replicas, which can significantly improve
solution across three vectors: data volume, performance for read-heavy applications.
concurrency, and workload complexity. Its However, Amazon Aurora’s architecture shows
components—TiDB Server, TiKV, and limitations in write scalability, as it relies on a
TiFlash— provide horizontal scalability for both single primary instance for write operations.
transactional and analytical workloads, a This design choice positions Amazon Aurora as
feature enhanced by its real-time HTAP an optimal solution for applications with high
capabilities. This makes TiDB particularly read-to-write ratios, where the priority is on
suitable for scenarios that demand managing large datasets and ensuring high
simultaneous transactional processing and read performance, but it may not be as
real-time analytics, offering a balanced effective for write-intensive workloads.
approach for handling large datasets, high
concurrency, and complex queries. While both TiDB and Amazon Aurora provide
robust scalability, their architectural
In contrast, Amazon Aurora focuses on scaling differences make them suitable for different
data volume and read concurrency. Its types of workloads: TiDB for balanced read/
architecture excels in automatically scaling write scenarios and real-time analytics, and
storage to manage large data volumes. It can Amazon Aurora for read-heavy applications
also enhance read throughput via read with large data storage requirements.

Amazon Aurora vs. TiDB 11

 Comparing Database
Reliability
Comparing the reliability of TiDB and Amazon
Aurora involves examining how each
database handles data durability, fault
tolerance, and overall system stability.

Amazon Aurora TiDB

99.99% uptime 99.99% uptime

Service Level Agreement (SLA)

Zero within region Zero within region

Recovery Point Objective (RPO)

Less than 120 seconds within Less than 30 seconds within

Recovery Time Objective (RTO)
region region

Supported Supported from v6.5 GA

Point-in-Time Recovery (PiTR)

Supported (backtrack) Supported

Flashback

Not supported; brief downtime Continuous availability

Multi-Master Write
during failover

Amazon Aurora vs. TiDB 12

TiDB Reliability • Fault tolerance: In the event of a server
failure, other TiDB servers can continue
TiDB’s distributed architecture inherently to handle requests without any data loss,
enhances its reliability. Data is stored and as the data resides in the distributed TiKV
replicated across multiple nodes in the TiKV nodes.
layer, which means that the failure of a single
node does not lead to data loss. By default, • Scalability and load balancing:
data is replicated three times. For added Being stateless, TiDB servers can be easily
durability, the replica count is user scaled out to handle increased loads. This
configurable. Additional capabilities include: scalability ensures that the system can
maintain performance and reliability even
• Automatic failover: TiDB provides under heavy workloads.
automatic failover mechanisms. If a TiKV
node fails, the system automatically elects • Simplified maintenance and upgrades:
new leaders for the affected data regions, The stateless servers can be upgraded,
ensuring continuous availability. maintained, or replaced without impacting
the availability or integrity of the data. This
• Consistency and isolation guarantees: simplifies operational tasks and reduces
TiDB offers strong consistency and isolation the risk of downtime.
guarantees, which are crucial for
transactional reliability. It uses the Raft
consensus algorithm for data replication,
Amazon Aurora Reliability
ensuring consistency across multiple
replicas. Amazon Aurora’s distributed, self-healing
storage system automatically replicates data
across multiple AZs. This design provides high
TiDB’s Stateless Compute data durability and availability, reducing the

Layer risk of data loss through:

The compute layer in TiDB, represented by • Read replica failover: Amazon Aurora
the TiDB servers, is stateless. This means that enhances reliability through its read
these servers do not store any data replicas. In the event of a primary instance
themselves; instead, they process SQL queries failure, Amazon Aurora can promote a read
and interact with the TiKV nodes for data replica to a primary instance, minimizing
storage and retrieval. TiDB’s stateless downtime.
compute layer impacts overall reliability in the
following ways:

Amazon Aurora vs. TiDB 13

• Backup and recovery: Amazon Aurora • Single points of failure: TiDB’s distributed
provides continuous backup to Amazon S3 architecture minimizes single points of
and supports point-in-time recovery (PiTR). failure. By contrast, Amazon Aurora’s write
This ensures data can be recovered to any operations are dependent on the primary
second over a retention period, enhancing instance, which is a potential vulnerability,
data protection. though mitigated by its backup and
recovery features.
• Isolation and durability: While Amazon
Aurora offers ACID compliance and Both TiDB and Amazon Aurora offer high levels
isolation levels, its focus on read scalability of reliability, but their approaches differ. TiDB’s
means write operations are concentrated distributed architecture provides inherent
on the primary instance. This could be a redundancy and fault tolerance, while Aurora
single point of failure, albeit mitigated by its relies on its robust storage system and
robust backup and recovery mechanisms. effective backup and recovery mechanisms to
ensure data durability and system stability.

Comparative Analysis
TiDB’s distributed nature across multiple
components (i.e., TiKV, TiDB server, and TiFlash)
offers a high degree of fault tolerance and
data redundancy. On the other hand, Amazon
Aurora relies on its robust storage layer and
multi-zone replication for data durability. Both
systems also provide the following capabilities:

• Failover and recovery: TiDB’s failover is

within its distributed nodes, while Amazon
Aurora uses read replica promotion.

• Data protection: Continuous backup and

PiTR are strong suits of Amazon Aurora,
while TiDB ensures data protection through
its distributed architecture and real-time
synchronization.

Amazon Aurora vs. TiDB 14

Multi-Tenant Environments: A Unique
Deployment Scenario
TiDB provides two very interesting features: Placement Rules and Resource Control. When utilized
together, these features enable sophisticated data management and isolation, particularly
useful in multi-tenant environments, as illustrated in the below diagram.

These features, unique to TiDB and not available in Amazon Aurora, allow for fine-grained control
over data placement and resource allocation, making TiDB an attractive option for scenarios
requiring complex multi-tenancy configurations.

Placement Rules
Placement Rules in TiDB are designed to control the physical location of data within the cluster.

Amazon Aurora vs. TiDB 15

They allow administrators to specify how data allocation for multi-tenancy.
is distributed across various nodes. This is
crucial for optimizing performance,
Comparing Pricing
ensuring data locality, and complying with
data sovereignty and isolation requirements.
and Costs
Comparing the pricing of TiDB and Amazon
With Placement Rules, you can dictate where Aurora involves understanding their
data is stored based on factors like region, respective pricing models. These models are
zone, or host. This is particularly useful in influenced by resource usage, storage,
multi-tenant environments where different network, and additional features. It’s
tenants’ data may need to be isolated or important to note that pricing can vary based
stored in specific locations for legal or on region, instance types, and specific
performance reasons. configurations, and both services may offer
different pricing tiers or discounts for
long-term commitments.
Resource Control
Resource Control in TiDB manages and
TiDB Pricing
allocates system resources like CPU and
memory. It enables the logical grouping of TiDB’s fully-managed cloud deployment
queries and transactions, allowing for options utilize a resource-based pricing model.
differentiated resource allocation and Costs are incurred based on the compute and
management. storage resources consumed. This includes
the size and number of TiDB, TiKV, and TiFlash
By using Resource Control, administrators can nodes. Additional pricing elements include:
ensure that different tenants or workloads
receive appropriate resources. This is key in a • Scalability and flexibility: The pricing can
multi-tenant setup where preventing resource scale with the usage, meaning you pay
contention and ensuring fair resource more as you scale your resources up and
distribution are critical. pay less when you scale down, offering
flexibility for varying workloads.
The combination of Placement Rules and
Resource Control for multi-tenant • Additional costs: Additional costs may
deployments is a feature unique to TiDB. include network bandwidth, backup
Amazon Aurora, while offering robust storage, and data transfer fees. These
performance and scalability features, does costs can vary depending on the amount
not provide the same level of fine-grained of data transferred and the specific use
control over data placement and resource case. Some of these costs are represented

Amazon Aurora vs. TiDB 16

 by a unit of measure called a Request Unit to scale read operations, these replicas are
(RU). There are various TiDB services that charged similarly to primary instances.
utilize the RU measure for their cost
structure. These include inbound data
migration and outbound change data Comparative Analysis
capture (CDC). TiDB’s pricing is more focused on the overall
resource usage, including compute and
• Free tier: TiDB offers a free tier in the form storage nodes. Amazon Aurora’s pricing
of TiDB Serverless for up to 5GB of data and is heavily instance-based, with additional
50 million RUs per month. This allows charges for storage and I/O operations. Below
developers to experiment with the service are some more key differences:
before committing to a paid plan.

• Scalability costs: Both services scale their

costs with usage, but the way they scale
Amazon Aurora Pricing
differs. TiDB offers more granularity in
Amazon Aurora pricing is primarily based on scaling compute and storage
the instances you run. This includes the cost independently, which can be more
per hour for each database instance type, cost-effective for certain workloads.
which varies based on the instance’s capacity
and performance. Additional pricing elements • Backup and data transfer: Both services
include: charge for backups and data transfer, but
the specifics of these charges can vary.
• Storage and I/O costs: Apart from instance
costs, Amazon Aurora charges for • Free tiers and trials: Both services may
database storage and I/O throughput. offer free tiers or trial periods, which are
Storage costs are calculated per important for new users evaluating these
GB-month, and I/O costs are based on the platforms.
number of requests.
While TiDB and Amazon Aurora offer scalable,
• Backup and data transfer costs: Amazon pay-as-you-go pricing models, the specifics
Aurora provides automated backups, and of their pricing structures differ. This reflects
the storage for these backups is charged. their architectural differences and target use
Additionally, data transfer fees apply, cases. Users should consider their specific
especially for data transferred out of the requirements, including resource needs,
AWS environment. scalability, and additional features, to
determine the most cost-effective solution for
• Read replica costs: If you use read replicas their use case.

Amazon Aurora vs. TiDB 17

Conclusion
TiDB emerges as a highly versatile and scalable solution, particularly adept at handling complex,
data-intensive scenarios that require both transactional and analytical processing in real-time. Its
distributed architecture, encompassing TiKV, TiDB Server, and TiFlash, offers unparalleled
scalability across multiple vectors, ensuring robust performance even in the most demanding
application environments. Additionally, TiDB’s unique features for multi-tenant deployments
provide a level of data management and resource allocation not available in Amazon Aurora.

On the other hand, Amazon Aurora, with its focus on read scalability and automated management
within the AWS ecosystem, is well-suited for applications with high read-to-write ratios. Its
architecture, emphasizing data volume scalability and read concurrency, makes it a strong
contender for businesses seeking a reliable, cloud-native relational database service with high
read concurrency. However, its limitations in write scalability and less granular control over
multi-tenancy compared to TiDB might be a deciding factor for certain use cases.

Ultimately, the choice between TiDB and Amazon Aurora will depend on the specific requirements of
the workload, the desired balance between read and write operations, and the need for advanced
multi-tenancy features.

Want to explore how leading companies are adopting TiDB over Amazon Aurora and other cloud
services? Check out our Customer Story page for detailed case studies.

Amazon Aurora vs. TiDB 18

 Appendix: Feature Comparison Table

Amazon Aurora TiDB

Database Engine MySQL compatible, relational MySQL compatible, horizontally scal-

database able, distributed SQL

Deployment Options AWS AWS, GCP, Azure (self-managed),

On-Premise

Scalability Can scale up to 15 replicas, but Unlimited horizontal scaling on three

limited horizontal scaling vectors (data volume,
concurrency, workload complexity)

Performance High throughput reads, suitable for High concurrency, high throughput
transactional workloads up to a limit reads and writes, supports HTAP

Availability Highly available active/passive Highly available active/active

clustering with automatic failover clustering by default with automatic
failover

Security Secure by default with multiple layers Multi-level security features, including
of security encryption at rest and in transit

Management Fully-managed DBaaS with 24/7 sup- Fully-managed DBaaS with 24/7
port support

Pricing Pay-as-you-go based on Pay-as-you-go based on resource

instance type and storage usage

MySQL Compatibility Yes, compatible with MySQL protocol Yes, compatible with MySQL protocol
and syntax and syntax

Data Migration Supported through AWS Database Supported through TiDB Lightning and
Migration Service Data Migration tools

Monitoring Monitoring and logging through AWS Comprehensive monitoring and

CloudWatch alerting

Backup and Restore Automatic backups and PiTR Automatic backups and PiTR

Support for Secondary Indexes Yes Yes

Support for Views Yes Yes

Support for Stored Procedures and Yes No

Functions

Support for Triggers Yes No

Amazon Aurora vs. TiDB 19

 About

PingCAP is the company behind TiDB, the most

advanced open-source, distributed SQL
database. TiDB powers modern applications
with a streamlined tech stack, elastic scaling,
real-time analytics, and continuous access
to data—all in a single database. With these
advanced capabilities, growing businesses can
focus on their future growth instead of complex
data infrastructure management. Some of the
world’s largest companies across technology,
financial services, travel, Web3, and gaming
trust TiDB to handle their business-critical
workloads. Headquartered in Silicon Valley,
PingCAP is backed by Sequoia Capital, GGV
Capital, Access Technology Ventures, Coatue
Management, and others. For more information,
please visit pingcap.com.