关系数据模型的另一个好处在于它的简单性、适合联机事务处理（OLTP）、支持数据独立性。但是关系数据模型特别是RDBMS同样存在许多的不足之处。详细内容请参考下文：
一．对“现实世界”实体的表达能力比较弱
规范化通常导致表与“现实世界”中的实体不对应，它将“现实世界”中的实体分割成几张表来显示，以物理表示法来反映实体结构，这样效率会比较差，常常要在查询处理中进行很多连接操作。
二．语义过载
关系模型表达数据和数据间关系的构造只有一种——表。例如，为了表达实体A和实体B之间的多对多（*:*）关系、我们需要创建三张表，两个分别用于表达实体A和B，第三张表用于表达实体间的关系。它没有一种机制来区分实体和关系，也无法区分在实体间存在的不同种类的关系。例如，一个1:*关系可能是Has、Supervises、Manages等等。如果可以进行区分，也许我们就可以将语义构建到操作中。所以，我们说关系模型语义过载了。
三.不能很好的支持业务规则
很多商业化系统不能完全支持实体和参照完整性、域等业务规则，所以需要将它们内置到应用程序中。这样当然是危险的，而且容易导致做重复的工作。更糟糕的是，可能还会引起不一致现象。而且，在关系模型中不支持其他类型的业务规则，这又意味着它们需要被构建到DBMS或应用程序中。
四．有限的操作
关系模型只有一些固定的操作集，例如面向集合和记录的操作，操作是在SQL规格说明中提供的。但是，SQL目前不允许指定新的操作。因此，在给许多“现实世界”对象的行为建模就有了太多的限制。例如，一个GIS应用程序典型的使用点、线、线组、多边形和一些处理距离、交叉点和包含关系的操作。
五．处理递归查询困难
数据的原子性意味着在关系模型中不允许出现重复的数据组，这样就导致了处理递归查询极为困难。递归查询就是那些有关表和自身直接或间接的关系的查询。为了解决这个问题，SQL可以嵌入在一个高级程序设计语言中，由高级程序设计语言来提供支持反复操作的功能。而且，很多RDBMS提供了具有类似结构的报表书写程序。不管是哪种情况，都是应用程序而不是系统的内在功能提供了所需的功能。
六．阻抗失配
直到最新版本的SQL标准，都缺少完全的计算功能。为了解决这个问题并且提供更多的灵活性，SQL标准提供嵌入式SQL来帮助开发更加复杂的数据库应用程序。但是，这引起了阻抗不匹配（impedance mismatch）的问题，因为我们将两种不同的程序设计模式混合在了一起。
1.SQL是一种处理行数据的声明性语言，而诸如C语言这样的高级语言则是过程化的语言，一次只能处理一行数据。
2.SQL和3GL使用不同的模型来表达数据。比如，SQL提供内置的数据类型Date（日期型）和Interval（时间间隔型），而在传统的编程语言中却没有这样的类型。因此，就需要应用程序在两种表示法之间进行转换。而这样做无论从程序设计的工作量还是运行时资源的使用来看都是低效的。而且，由于我们使用两种不同的系统，因此，不可能将类型检测作为一个整体自动进行。
注：SQL标准(SQL3)通过引入许多新的特征已经弥补了上文中讲述的一些不足之处。
