ClearDB’s Database-as-a-Service (DBaaS) model presents an attractive option for rapid deployment of managed database assets in the cloud.  If you’re thinking of using ClearDB (now partnered with Datavail) to power your cloud-based application’s database, you’ll want to understand the pros and cons of our multi-tenant (Community) versus single-tenant (Developer and Production) editions for housing your data.  Both approaches have merit, and by understanding the strengths of each approach you can arrive at a choice that’s a best fit for your specific requirements.
It might be helpful to think of our multi-tenant Community datastores like housing your data in an apartment complex.  You have your own space in the building, but you share walls with other families.  You enjoy cost benefits from this arrangement and it’s usually a simple task to secure a new lease and start moving in, but sometimes a neighbor throws a party and the noise affects your quality of life.  You also must agree to a series of common rules when living in an apartment complex, so you don’t have full control over your environment.
Under the right circumstances, our multi-tenant Community edition can deliver lower costs plus general reliability and adequate performance.  This is especially true when your operational requirements are not particularly rigid.  For instance, a typical WordPress blog with low to modest load, powered by a Community edition database, can deliver a good end user experience with database response times from milliseconds to seconds, depending on the overall utilization of the database cluster.  For scenarios where slight fluctuations in response times are acceptable, Community edition datastores are a great way to lower your cloud expenditures.  Our shared Community datastores are designed to prevent any one user’s task from monopolizing cluster resources such as memory, CPU, bandwidth, etc., but this tier of service will still be subject to varying performance as the load from individual tenets changes.
As mentioned previously, housing multiple database tenants on a single cluster can also introduce environmental restrictions.  For efficiency purposes, our Community datastore clusters share a single database engine.  This means there are certain MySQL features that are restricted in our shared environments; for example, use of triggers, user-defined functions and stored procedures are not allowed with our Community edition.  Some configurations must be set globally across a cluster and cannot be set differently for each tenant; for example, the localization settings of the database software is fixed for all Community edition tenants on a given cluster.
With all those Community edition efficiencies comes benefits beyond just lower costs.  For example, scaling your Community datastore to a higher level plan is an instant process that requires no downtime and no data migration process.
If multi-tenant cloud datastores are like housing your data in an apartment complex, then single-tenant cloud datastores are like buying your data a single-family home.  While the power of your infrastructure may determine whether your data lives in a cozy 2-bedroom cottage or a luxurious mansion on 20 acres of land, there are certain universal benefits to single-tenant that apply in all cases.  As the single inhabitant of your castle, you can expect an improved quality of life plus more control over your environment.
ClearDB’s single-tenant DBaaS options, the Developer and Production editions, do not have the limitations noted in the discussion of our Community edition.  The absence of shared resources means Developer and Production tenants enjoy consistent performance that can’t be impacted by noisy neighbors.  That’s an extremely important benefit for mission critical applications that must deliver an optimal and consistent user experience.
You’ll also gain a number of environmental control benefits with single-tenant cloud datastores, such as the ability to lock down a cluster with client-side certificates, or use of IP whitelisting.  With the Developer and Production editions, there is simply less need to enforce restrictive access controls to prevent co-mingling of information. The ‘simpler’ environment of single-tenant systems also translates to easier diagnosis and remediation of issues, should they occur.  From an operations standpoint, there is no need for concern about how actions such as restarts or backups will affect other users.
The majority of our DBaaS users find multi-tenant restrictions absolutely acceptable for their small to moderate workloads.  Some use multi-tenant databases for test/dev or staging environments, opting for the more powerful single-tenant services for their production workloads.  For mission critical workloads and critical applications, single-tenant datastores are almost always the better choice.
Both multi-tenant and single-tenant environments have their merits, so a simple analysis of your own requirements up-front can help you choose the optimal path forward.  As with any deployments, you are urged to choose wisely as changing the deployment model after the fact is seldom painless and will likely require downtime to perform a database migration.