Database as a service (DbaaS) over dimensions–performance, scalability, & reliability?

All we need is an easy explanation of the problem, so here it is.

MySql Database as a service:

  1. Amazon
  2. Xeround

Another eg. PostgreSQL Database-as-a-Service.
You can get the list of similar products here.

Does anyone have details on their performance, reliability, and scalability of these DbaaS? Reading literature on these products make them sound too good to be true. And my inner cynical sense tells me to question the claims.

How to solve :

I know you bored from this bug, So we are here to help you! Take a deep breath and look at the explanation of your problem. We have many solutions to this problem, But we recommend you to use the first method because it is tested & true method that will 100% work for you.

Method 1

The only thing I would like to comment on is Xeround

I tried out the XEROUND MySQL Instance

I found out that it only has three(3) Stroage Engines

mysql show engines;
| Engine  | Support | Comment                                                   | Transactions | XA   | Savepoints |
| Xeround | DEFAULT | Xeround MySQL storage engine                              | YES          | NO   | NO         |
| MyISAM  | YES     | Default engine as of MySQL 3.23 with great performance    | NO           | NO   | NO         |
| MEMORY  | YES     | Hash based, stored in memory, useful for temporary tables | NO           | NO   | NO         |
3 rows in set (0.01 sec)

If you want ACID-compliant transactions, you have to use XEROUND Storage Engine. Most users are familiar with InnoDB since it has been with MySQL long before Oracle and Sun became involved. There are about 50 variables to tune and monitor.

Here is everything for XEROUND

mysql show variables like 'x%';
| Variable_name                    | Value                                                  |
| xeround_transaction_memory_limit | 128                                                    |
| xeround_transactional_ddl        | OFF                                                    |
| xeround_xdapc_socket             | /opt/xeround/sys_819/v3.0.1.43/xdrm/mysql/xdapc_socket |
3 rows in set (0.01 sec)

Not much you can tune there.

You are at XEROUND’s mercy for tuning the transactional behavior


  • Can you disable the ACID compliance of XEROUND ?
  • Does XEROUND have multiple levels of Transaction Isolation to support MVCC ?
  • Are there shared or separate tablespaces per table or per user ?
  • Any limitations on the row length or the number of columns ?
  • How does XEROUND do crash recovery ?

Hey, one could only guess at these things right now.

I am sure that reading literature on the XEROUND Storage Engine turns up nothing you can do that a DBA would be expected to do for configuration, optimization, and overall tuning.

IMHO I would not use the XEROUND Storage Engine from any transactions until an adequate Whitepaper comes out on how to use it, tune it, and configure it. In addition, some internals you can understand would be nice as well. Otherwise, the XEROUND Storage Engine is just as mysterious to the public as is the Storage Engine of PostgreSQL, SQL Server, and Oracle.

As long as users only use the MyISAM Storage Engine and are not performing any ACID-compliant transactions, you should be fine.

As a good rule of thumb, stick to DB Services that will support MyISAM and InnoDB.

Note: Use and implement method 1 because this method fully tested our system.
Thank you 🙂

All methods was sourced from or, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply