Amazon RDS vs. Xeround Cloud DB – Head-to-Head Feature Comparison

Contrary to common perception, Amazon RDS is not a truly elastic cloud database service, but rather an implementation of MySQL on EC2 (in other words, it’s just MySQL running on ordinary EC2 instances). In comparison, Xeround is a native cloud database, which provides automatic scaling, elasticity and high availability, alongside the simplicity, automation and ease-of-use of a Database-as-a-Service.

Key Differentiators Between Xeround and Amazon RDS:

1. Rule-based Auto Scale up & down with no downtime vs. Amazon RDS manual scaling with down time
2. Pay per actual usage vs. pay per instance size, resulting in over subscription
3. Xeround never fails – even when Amazon’s instance fails. Xeround offers a highly available, self-healing, database, with no downtime. Amazon RDS cannot guarantee no downtime, both planned (4 hour / week maintenance) and unplanned.
4. Unlimited database size vs. limited to Amazon RDS instance sizes
5. Database configuration does not require code changes to your application (replication etc.)
6. Xeround offers up to 700% higher throughput and less than 1/10 the latency of RDS for heavy-duty MySQL applications – see our benchmark showing Xeround vs. Amazon RDS performance.

Feature / Function	Xeround Cloud DBaaS	Amazon RDS	MySQL on EC2
MySQL Compatibility
Scalability
Linear Out / In (?)		Partialy (Read Replicas)	Partialy (Read Replicas)
The throughput and size of Xeround cloud database can scale out – and in – linearly, for BOTH read/write. By contrast, Amazon only provides partial read replicas scaling – where scaling out is done via adding more Read replicas, which allow more throughput for Read purposes, but not for OLTP. This method also introduces ACID compliance issues (see Clustering feature below).
Elastic (?)
Xeround’s cloud database can grow and shrink based on load, with no downtime and without any changes required in the application.
Auto Scale (?)	(Up, Down, Out, In)
Xeround’s cloud database offers automatic throughput elasticity – where the database throughput is able to grow and shrink based on load with no downtime or the application being aware of the process.
Application Transparency (?)
Xeround’s cloud database allows for complete Application Transparency – where no code changes are required to support scaling. In Amazon’s case, when scaling, the application is responsible for distributing the load between the read replicas, and the master. This requires some sort of load balancing framework to be put in place in the code.
Clustering
Clustering Model (?)	Symmetric* (No Masters / Slaves – All Masters)	Master / Read Replicas	Multi-Master / Master Slave
Symmetric Clustering Model means all nodes are equal. Records are spread equally between the servers, and replicated. All replicas are master records.
Write / Update Conflicts (?)	No Conflicts	No Conflicts	Conflicts Possible in Multi Master
When the same data is updated on multiple nodes, and synchronization between servers is asynchronous, there is a conflict, which cannot be easily resolved. This violates the ACID properties.
Read Concurrency (?)		Yes for Master; Latency for Replicas	Yes for Master; Latency for Slave
When using asynchronous replication, there is always some latency between the operation executed on the master to the operation being reflected on the replica. This creates some inconsistency for read on the replica (ACID Violation).
Availability and Recovery
Self-healing (?)
Xeround cloud database can automatically identify and isolate failures and heal itself from a server failure without the application needing to be aware of the failure.
Failover (?)		Optional	Optional
Xeround cloud database is distributed and maintains multiple replicas of the data. Therefore, in case of failure, be it network, hardware or software, the database continues to work with its existing resources. In parallel, new resources are allocated to ensure full productivity.
Distribution
Multi-zone (?)			(Special Configuration)
Xeround database can be distributed on multiple availability zones providing both lower latency per zone as well as survive failures of an entire zone.
Caching
Write / Read (?)		Partial Read	Partial Read
Xeround uses memory caching for both read and write. In Amazon’s case, Partial read means some of the data is cached for read.
DBaaS & Web Management Console (?)
Xeround cloud database is available as a service, with management console, automatic provisioning and configuration.
Pay-Per-Use (?)
Xeround charges by actual use. Your database automatically scales out when you need to and shrinks back when you don’t- so you only pay for what you use, with no need for overprovisioning, subscribing to larger instances only to ensure service in sporadic peak performance times.

BE UP & RUNNING WITH XEROUND IN MINUTES!

Have additional questions?

Email us at info@xeround.com if you have any feedback or additional questions.

You may also wish to see how we compare against Salesforce’s database.com.