一个是另一个的子集吗？
绝对没有；两者最终都以关系或图形的数学概念为模型。两种模型都是超通用的，基本上没有你不能用任何一种表示的信息内容。这意味着尽管它们可能在许多语法糖方面有所不同，并且它们鼓励您对数据进行建模/思考的方式（就像编程语言不同一样）它们都具有相同的“表达能力”。
您在问题中描述的是一种图形建模方法（vertex 和edge 表）。图的实现是关系可以表达的一个子集。类似地，我可以使用图形数据库模拟表和行，但我会选择一个特定的实现——这并不能证明关系数据是图形数据的子集。
所以第一个见解是它们具有大致相等的表达能力。您可以在其中任何一个中建模任何东西。所以你应该问的真正问题是为什么你会选择其中一个？
为什么你会选择一个而不是另一个？
所有数据库的存在都是为了方便数据访问。简而言之，您存储它以便获取数据。但是，您究竟需要如何获取数据？有许多不同的访问模式。一般来说，数据库的设计空间巨大。每当数据库做出某个决定时，它往往会自动使其在某些事情上变得更好，而在其他事情上变得更糟。例如，当您在关系数据库中创建索引时，您只是加快了读取速度，但降低了写入性能，因为必须维护索引。
所以，当谈到“图形还是关系？”这个问题时- 您应该首先弄清楚您的数据是什么样的，以及您的数据访问模式是什么样的。如果您知道这些东西是什么，那么您可以评估一堆数据库，查看他们做出的选择，然后选择最适合您需要的数据库。然后，如果 DBMS 做出的选择会使某些访问模式变得困难、错误或缓慢——您可以为该数据集避免使用该 DBMS。
它（部分）关于数据访问模式
当存储的数据是图时，图数据库往往比关系数据库更好，当数据访问模式涉及大量图遍历时，或两者兼而有之。 （See this other answer I wrote 更深入地讨论为什么会这样）。该链接还提供了您特定问题的答案：“图形数据库是否以某种方式构建其存储或优化其查询，以提供无法从关系数据库获得的性能特征？”
你说：我可以使用 SQL 查询这个图，必要时使用递归子查询，必要时在事务中使用多个单独的查询。 -- 所以从技术上讲这是正确的，但让我们来看看示例来了解为什么关系可能不够好。假设我有一个图（在 RDBMS 中，一个节点表，一个边表，它们之间有一个连接键）。假设我选择了一个节点，并且我想识别距离该节点 6 到 8 跳之间的所有内容。这是执行此操作的密码：
match (myChosenNode {id: 'foo'})-[r:relationshipType*6..8]->(y) return y;
我真的很想看到你把它写成 SQL。这是可能的，但它困难而且复杂。而且它的性能也会像狗一样，因为您将在大量数据上加入大量数据。
酸
现在就 ACID 保证好了，Neo4J provides transactions with ACID guarantees。但是，对于不同的图形数据库，答案会有所不同，尤其是在 Hadoop/HBase 之上实现的那些。那里有 YMMV，所以请检查每个数据库的细则。
确实，RDBMS 有许多您通常不会在图形数据库中找到的特性，例如触发器和某些类型的约束。作为一个长期的 RDMBS 书呆子，我对丢失这些东西并不高兴，我认为它们很有价值。
总结
对我以及与我共事的许多其他工程师来说，这主要归结为：
- 您的数据是什么？
- 您的访问模式是什么？
如果您的数据是图，或者您的访问模式涉及大量图遍历，您可能应该使用图数据库。如果您的数据更加表格化，或者您的访问模式更倾向于批量扫描，那么您应该使用 RDBMS。归根结底，它们是具有不同利基的两种不同工具。如果你在他们的优势领域使用它们，你会很高兴。如果您只是“因为可以”而使用 RDBMS 对图形进行建模，那么您将受苦。如果您使用图形数据库对每个图形中的每个节点进行大量批量扫描，您将受到影响。与大多数技术一样，这只是使用正确的工具来完成工作。