SaaS 行业垂直数据库需求5点思考：成本、计费、库表量、多云、低代码

撰文｜宇婷

宇婷收到某大厂的读者来信，是关于SaaS行业垂直数据库的思考。这里为你转述。

传统的Oracle、阿里云、SQLServer 或者 AWS 数据库是面对软件而设计。但是SaaS创业公司对数据库使用，有自己的诉求。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Htap数据库是一个通用场景，几乎可以覆盖所有行业所有场景，类似OceanBase；但也有一些场景是saas特有的，比如

1，saas比software 的获客成本更低，客单价更低，因此用不起太昂贵的数据库，需要低于10元/月/租户的起步价

2，也正是因为saas 的客单价低，租户变多，导致数据库的库表数量非常多（百万级），传统的数据库很少有超过1万张表

3，随着时间的积累，数据越来越多，一个租户的应用最早可能用单体的数据库就够了，现在需要升级到分布式数据库，甚至要用HTAP数据库，在这个升级的过程中，能不能做到完全自动，不需要租户停机维护，不需要saas厂商做数据库迁移，而是由云数据库根据数据规模、负载高低自动完成升级，按实际的资源消耗进行计费，整个过程对业务无感

4，saas需要能够在任何一朵云上部署，不被云lock-in，因此需要数据库也能够（开源的通用的数据库在各个云上都有，但满足上述条件又能在各个云上部署的数据库，有点难）

5，还有一个新方向，是低代码系统，aPaaS，比较典型的场景是：频繁的DDL，希望秒级完成且不影响业务。（现在的数据库都支持的并不好）

传统的数据库表结构是由软件的开发者来定义，因此如果软件不更新，表结构是不会变的。但低代码系统里面，软件的设计、表结构的设计都是由终端用户来维护，可能随时修改，并且改了之后希望立马生效，这个操作对应数据库里面的DDL，现在频率加大了，还希望可以立即生效，不影响业务，对数据库挑战非常大。

有些aPaaS系统为了规避DDL，就在数据库之上做了一套自己的逻辑，但会增加系统的复杂度（比如Salesforce用Oracle的时候存的是一张大宽表），并且我认为不是一个特别好的做法。现在随着提供saas/低代码服务的公司越来越多，相应需求也可能产生。‍