高级亚马逊Web服务用户更喜欢自我管理运行在亚马逊弹性计算云上的数据库，而不是数据库即服务产品，至少现在看是这样的。
上周，AWS超级用户在线活动群组创立会议的演示中，关注超级用户如何在AWS上运行数据库。大多数演讲者表示他们在弹性计算云(EC2)上运行类似Cassandra和MySQL这样的自我管理数据库，而不是使用亚马逊的数据库即服务(DBaaS)平台，比如关系型数据库服务(RDS)以及DynamoDB。
然而，一些IT专家在此次活动中也表示有过DBaaS体验，而且一些仍旧在自我管理和DBaaS选择中保持中立态度。
美国加州一家提供在线社交学习平台的公司Edmodo，在将其MySQL操作从EC2上自我管理实例转移到RDS时，收获颇多。该公司的运营总监Jack Murgia表示：“在我们决定从RDS退出时，我们学到了更多。”
2011年春天，Edmodo为两百万用户服务，而且得到了风投公司的重大投资，他们将这笔资金用来雇佣Murgia，从而同拥有十个开发者的团队共同工作。Murgia介绍：“基本上我走过一扇门，就有一个数据库，一个熟练员工和一个苦工。”这些都运行在EC2上。Murgia进来后，人员配置上并没有一个数据库管理员。
跟着亚马逊RDS一路走来，其提供了一次使用MySQL管理繁忙的初创企业的机会。2011年秋天，该公司完成了到RDS的迁移。Murgia谈到RDS时说：“我们能够通过点击一些按钮，创建开发和质量保证环境，随着那年秋天负载的不断增加，用鼠标点几下就可以读取副本，改变域名系统记录。”
但是在多有效区域故障恢复的时候，RDS部署遇到了障碍。
“我们发现多AZ故障恢复在绝大部分时间都是失败的，”Murgia说，“有时候即便是计划中的故障恢复我们发现复制都是失败的，而且那个时候唯一的选择就是提出新的副本。”
主数据库有八个副本，每一个新的副本用时大约一小时，这也意味着Edmodo再一次服务于用户之前，要有一整天的宕机时间。因此公司重组了，准备转到RDS上一个单独的熟练员工，如果有什么失败了就要计划新的副本。RDS在2013年六月开始提供服务水平协议(SLA)，这也让Edmodo寻求一种继续使用服务的方式。
但是随着Edmodo不断发展，该公司从外包公司引入了DBA，在2011年到2013年雇佣了更多的系统管理员。那时候，该公司拥有了内部运行EC2上自服务数据库的技能，逐渐离开RDS，转向自服务MySQL环境。
Murgia说：“我们的双手被RDS“黑盒”绑架。”如果Edmodo管理自己的MySQL和副本，IT团队可以促进副本到一个精通的员工，将所有的副本指向这个精通的员工并且重新启动并运行。相反，该公司致力于恢复数据库时，没有基础设施的控制就会出现失败。
“这是一种不得不做的妥协，”Murgia说道，“可能你不具备技能，可能你只是一个小的初创公司，但是随着你开始获得这些技能，并且开始提升性能和可用性标准，这就会成为问题。”
超级用户活动会议上的另一个演讲来自Stackdriver的IT专家，这是一家位于美国波士顿的公司，提供AWS监控即服务。这家公司通过Cassandra集群迎来了一个转折点，而且考虑了两种替代方案：扩展现有的集群或者部署亚马逊DynamoDB DBaaS。
“我们有非常繁重的工作负载，涉及数以亿计的数据点，而且Cassandra对于各种写操作过多的工作负载有很好的支持，”Joey Imbasciano说道，他是Stackdriver的云平台工程师，“Cassandra中的建模时间系列数据设计模式也是众所周知的，因此我们知道我们不会有任何问题。”
Cassandra另一个吸引人的特性就是能够以编程的方式删除数据，这样就可以让数据库保持一种可管理的规模，而且无需人工介入。Stackdriver也考虑了MySQL和RDS，但是感觉NoSQL更适合自身的数据集。该公司也在部署Cassandra的18个月前就关注DynamoDB。
“那时候，厂商锁定是我们尽力去避免的，”Imbasciano说道，“此外，我们做了一点成本估算，并且发现那时候使用Dynamo的成本要稍高一点。”
Stackdriver开始是三节点的Cassandra闭环，现在已经增长为36节点，随着其继续增长，该公司会再一次关注DynamoDB。“优势很明显，”Patrick Eaton说道，他是Stackdriver的架构师，“焦点就是自动化。升级是自动化的。亚马逊的全天候支持人员处理浙西额事情，他们可以在你需要时进行扩展。”