众所周知，OpenStack所有的数据持久化（除了Ceilometer外），全部依赖官方推荐的MySQL（包括Percorna、MariaDB等），但是开源关系型数据库引擎的扩展性一直都是问题，从生产环境监控中可以很容易看到，Neutron对数据库的读写压力，在OpenStack所有组件中，仅次于Nova（Keystone可以通过内存数据库来缓解75%以上的压力）。其中主要是三个部分的原因，一方面数据库引擎单点或者HA都无能解决扩展性问题，当Neutron-server进程越来越多时，就会出现，虽然有Galera集群方案，但其事务处理性能一直都是瓶颈，而且乐观锁机制也会导致API失败（Nova有db-retry，Neutron在那个时候还没有）。第二个方面，是SQLAlchemy框架本身的限制，Python社区一直都是松耦合的纯开源社区，所以导致很多企业级应用所必须的框架，没有得到企业级的维护，其中首当其冲就是SQLAlchemy，这个Python世界里排行第一的ORM解决方案，并不是一个优秀的性能出众的ORM方案（至少和我在Java世界里使用的Hibernate，各方面都差了不止一截），记得其在0.90-0.99的每个版本都存在或多或少的Bug没有修复，而且它的ORM引擎对SQL本身的优化也不是特别到位。第三个方面是Neutron社区，一直以来都存在错用SQLAlchemy的情况，在事务处理过程中使用RPC引起不必要的事务内协程切换，间接增加无谓的数据库引擎长时间维护事务的压力，大规模环境下经常导致事务Timeout、Deadlock等情况。这些情况集中于ML2和L3RouterPlugin插件的DB模块，每个Release都有大量的Race Condition曝出，然后就是Case by Case去修复，虽然这种情况自从Icehouse曝出多达10-20个同样的问题后，慢慢随着Juno、Kilo已经修复了大多问题（本人也参与讨论和修复了其中的几个Bug），但是，由于初期设计失误导致的这种情况，在后期，却需要200%-300%的时间去分析和修复，让人汗颜。
