This post focuses on the question: Amazon Aurora or Google Spanner? Let's see together below.
One of our early decisions was to find a database that could be used as an inspiration for the YugaByte DB architecture. We paid close attention to two systems, namely, Amazon Aurora and Google Spanner.
1. Amazon Aurora is one of the fastest growing services in the AWS history.
Amazon Aurora is an SQL database that provides high availability. It has compatibility with popular RDBMS databases (such as MySQL and PostgreSQL), makes it easy to start and runs various applications and is the fastest growing service in AWS history. It has an extensible data store layer, but not at the query layer.
Writing is not horizontally scalable. The only way to extend the write throughput is to vertically extend all write nodes (called master nodes). Therefore, the number of write IOPS that can be processed by the database is limited.
The write is not globally consistent. Many modern Cloud prototypes are inherently global and need to deploy underlying databases across multiple regions. However, Aurora supports only multi-host deployment and the last write program (with the highest timestamp) wins when a conflict occurs. This may lead to inconsistencies.
By using subordinate copies of sacrificing consistency, you can obtain a read scaling extension. To extend the read, the application needs to connect to the slave node to implement the read. When using these slave nodes to implement read, the application needs to face the consistency semantics of the downgrade, as well as a separate connection endpoint. This makes the application architecture very complex.
2. Cloud Spanner is the only enterprise-class, globally distributed and highly consistent database service built for the Cloud.
Google Spanner is a scalable SQL database used to combine the advantages of relational database structures with non-relational level extensions for large-scale scalable and geographically distributed applications. This means that Spanner can seamlessly extend read and write, support geographically distributed applications that require global consistency and read from multiple nodes without sacrificing correctness.
However, it abandons the many familiar function sets that the RDBMS database provides for developers to expect. For example, the fact that it 'does not support foreign key constraints or triggers' is highlighted in the Google Spanner document.
We decided to adopt a mixed method.
The core storage architecture of YugaByte DB is inspired by Google Spanner, which is built for horizontal scalability and geographic distributed applications.
YugaByte DB retains the PostgreSQL compatibility query layer similar to Amazon Aurora, which supports rich function sets, as well as the most extensive use cases.
