关系数据库提出了计算机科学研究人员所熟知的范式化（normalization）。该过程要求数据库建模人员通过依赖分析来减少数据冗余，节省磁盘存储，需将关系数据库表中多次出现的数据元素拆分到各自的表中。正如不会将city（城市）作为person（个人记录）的属性来存储，而是将city和person分为两个独立的表单独进行存储。这样，查询时将这些表进行关联，根据表之间的关系（1对多，多对1，多对多关系），引入一种新型的表（连接表，通常为两个表之间的多对多关系）来执行这些连接操作。
可以说关系数据库管理系统在过去的30年里为计算机行业提供了非常好的服务，而且很可能在未来很长一段时间内继续服务下去。然而，有必要指出，这也带来了一些问题，将再次为另一种数据库管理系统搭建舞台：
● 关系数据库系统受规模的影响严重。当关系集合或表变长时，关系数据库系统的查询响应时间通常会变得越来越糟。大多数情况下不是问题，但数据规模确实很重要，而且其不足的确会受到影响。举一个反面的例子，Google Spanner，它是一种可扩展、多版本、全分布、可同步复制的数据库。
● 关系数据库是非常“反关系”（anti-relational）的。比图数据库更缺乏关系。应用领域中采用关系模型建模会变得更加复杂、更难以处理。具体而言，join操作在关系数据库管理系统用于从多个不同的集合或表中进行查询以获取数据，是极其复杂和耗资源的。系统能有效支持join操作的数量是受限的，在join爆炸（join bombs）到来之前系统已无法响应。
● 关系数据库甚至在数据入库前强加一个模式（schema），且该模式过于严格。每个用户都在域（domain）下进行操作，很难将单个数据库模式应用到整个域。从而需要一种更灵活的模式，以适应迭代式的敏捷软件开发需求。接下来将看到，下一代数据库管理系统绝不会安于现状、止步不前，而会针对上述痛点不断创新。
