Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking for a solid solution (~1GB of DB space). Speed is crucial and I'm happy to spend up to $100 a month on a decent solution. The database will be used by a series of desktop applications developed on .Net.

I've already tested both Xeround and Amazon EC2 solutions, but the results were similar and pretty disappointing.

I would highly appreciate any suggestion based on your experience.


I've recently tested an EC2 m1.xlarge and a RDS db.m1.large. Similar results as with micro instances. Tests were done from Europe and America. Results:

  • Europe to EC2/RDS - 22 min.

  • America to EC2/RDS - 8 min.

  • local to local - 10 sec.

share|improve this question
In both tests was the application running locally and connecting across the Internet to your database? Could the performance issues simply be related to the amount of data being sent between your application and the database over a relatively slow connection? In this case, it may not be so much a database performance issue as a network performance issue. (Unless you can reduce the bandwidth requirements). – Cade Roux Jan 2 '13 at 19:55
If money is not an issue and speed is crucial, why not build your own physical environment with oodles of RAM and some high performance SSDs? – swasheck Jan 2 '13 at 20:05
@CadeRoux In both cases, the test application was running locally an connecting to the cloud database. The amount of data being sent is 1 MB max. So that's not an issue. – Yeseanul Jan 2 '13 at 20:39
@swasheck Maybe I've exaggerated. Please see the edit. – Yeseanul Jan 2 '13 at 20:44
@Yeseanul 1MB of data in a single request? At 1.5Mb/s, that will take around 5.3 seconds just to download the data - assuming no overheads at the database protocol layer or IP layer, and no latency or other issues and no overheads with establishing a connection and processing the data. – Cade Roux Jan 2 '13 at 20:54

I'd like to chime in on what has been said in the question and in the comments.


Exactly one year ago today, I wrote an answer about the Xeround DB Service : Database as a service (DbaaS) over dimensions--performance, scalability, & reliability?

Granted, you have the following:

I just instantiated a Xeround Free Version Sevice and ran SHOW ENGINES; and got this

mysql> show variables like '%innodb%';
| Variable_name         | Value |
| have_innodb           | NO    |
| ignore_builtin_innodb | OFF   |
2 rows in set (0.01 sec)

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)


No InnoDB ??? Not much has changed.

How about variables for the Storage Engine?

mysql> show variables like 'xeround%';
| Variable_name                      | Value                                     |
| xeround_alloc_pages                | 1                                         |
| xeround_alloc_stats                | 0                                         |
| xeround_conditional_filtering      | off                                       |
| xeround_conf_dir                   | etc                                       |
| xeround_database_schema_size_limit | 2                                         |
| xeround_database_size_limit        | 10                                        |
| xeround_enable_client_socket_check | ON                                        |
| xeround_index_stat_is_approximate  | ON                                        |
| xeround_instance_id                | 35644                                     |
| xeround_maintenance_mode           | OFF                                       |
| xeround_query_row_cache            | 0                                         |
| xeround_record_count_adjust        | 12                                        |
| xeround_records_in_range_mode      | off                                       |
| xeround_schema_id                  | 115                                       |
| xeround_throughput_credit          | 100                                       |
| xeround_throughput_credit_seconds  | 10                                        |
| xeround_transaction_memory_limit   | 128                                       |
| xeround_transactional_ddl          | OFF                                       |
| xeround_xdapc_ip                   |                                           |
| xeround_xdapc_socket               | /opt/xeround/sys_35412/xdapc/xdapc_socket |
20 rows in set (0.01 sec)


Looking at the API, I do not believe you can tune anything. You are basically at the mercy of the Storage Engine.

I have also tried loading data into it and using the INFORMATION_SCHEMA database to report back to me space usage. For the XEROUND Storage Engine, I get back nothing. MyISAM is OK.

There are still other limitations with Xeround (Oct 12, 2012) you have to read and consider.

Amazon RDS

While the service bears the hallmarks of a well-trusted brand name, the service must still be evaluated in terms of two things:

  1. Cost
  2. Configuration
  3. Performance

While cost is at one's discretion, I will discuss the other aspects


  • You have no access to a my.cnf
  • Any variables to be configured beyond default requires an API call to the DB Parameters Group followed by a restart of the RDS Instance.
  • There are two things you cannot change no matter what Memory Class you choose
  • See my post from Aug 02, 2012 : Local database vs Amazon RDS


This goes hand-in-hand with CONFIGURATION. Any tuning aspects you wish to make are subject to the limitations and functionality of the RDS API. Not all Performance enhancements for InnoDB are possible because of Amazon's policies meant to provide a share-everything environment for normal RDS users (unless you can come up with more $$$ for more IOPs and things of this nature).


Amazon EC2 may be your best option if your want more flexibility/autonomy for

  • configuring MySQL
  • voluntarily paying
    • RAM
    • Disk
    • IOPs
  • tuning InnoDB

Given the times you just reported in the question, nothing short of due diligence is required for tuning (possibly rearchitecting) your app for Cloud Usage.

share|improve this answer

protected by RolandoMySQLDBA Jan 3 '13 at 20:32

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.