在计算中，图形数据库是使用图形结构进行语义查询，并使用节点，边和属性来表示和存储数据的一种数据库。这种系统的一个关键概念是图形（或边，或关系），它直接关联存储中的数据项。这些关系允许存储中的数据直接链接，并且在很多情况下通过一个操作进行检索。
这与关系型数据库形成了鲜明对比，关系型数据库借助关系数据库管理系统，可以在不实现物理记录链的方面的情况下进行数据管理。例如，数据之间的链接以逻辑级存储在数据库本身中，并且可以使用关系代数操作（例如，连接）来以相关逻辑格式操作和返回相关数据。借助于物理层面的数据库管理系统（例如使用索引），关系查询的执行是可能的，这允许在不修改数据库的逻辑结构的情况下提高性能。
图形数据库通过设计可以简单快速地检索难以在关系系统中建模的复杂分层结构。图表数据库与20世纪70年代的网络模型数据库类似，都表示通用图表，但网络模型数据库在较低的抽象级别上运行，并且缺少在一系列边上的简单遍历。
图形数据库的底层存储机制可能会有所不同。一些依赖于关系引擎并将图形数据“存储”在表格中（尽管表格是逻辑元素，因此该方法在图形数据库，图形数据库管理系统和数据的数据实际存储的物理设备之间施加了另一个抽象级别）。其他的使用键值存储或面向文档的数据库进行存储，这使得它们本身就是NoSQL结构。大多数基于非关系型存储引擎的图形数据库还添加了标签或属性的概念，这些标签或属性本质上是具有指向其他文档的指针的关系。 这可以将数据元素分类以便于集体检索。
图形数据库中检索数据需要使用除SQL以外的查询语言，该语言专为处理关系系统中的数据而设计，因此不能“优雅地”遍历图。截至2017年，没有一种统一的图形查询语言像SQL一样被用于关系数据库。在多种系统，通常使用一种语言。一些标准化工作已经发生，导致像Gremlin，SPARQL和Cypher这样的多厂商查询语言。 除了具有查询语言接口之外，还可以通过应用程序编程接口（API）访问某些图形数据库。
图数据库基于图论，并拥有节点，边和属性。节点表示实体，例如人员，企业，账户或任何其他要跟踪的项目。 它们大致相当于关系数据库中的记录，关系或行，或文档数据库中的文档。边（也称为图或关系）是将节点连接到其他节点的线; 代表了他们之间的关系。 检查节点，属性和边的连接和互连时会出现有意义的模式。 边缘是图形数据库中的关键概念，代表了其他系统中不直接实现的抽象。属性是节点的相关信息。 例如，如果维基百科是节点之一，它可能与诸如网站，参考资料或以字母w开头的单词之类的属性相关，这取决于维基百科的哪些方面与给定数据库密切相关。
关系模型使用数据中的信息收集数据。 例如，可以查找所有电话号码包含区号“311”的“用户”。这可以通过搜索选定的数据存储区或表格来查找，在所选的电话号码字段中查找字符串“311”。 这在大型表中可能是一个耗时的过程，因此关系数据库提供了数据库索引的概念，它允许像这样的数据存储在较小的子表中，仅包含选定的数据和唯一的键（或主键） 它是它的一部分。 如果电话号码被编入索引，则在较小的索引表中会发生相同的搜索，收集匹配记录的**，然后使用这些**在主数据表中查找记录。 一般情况下，这些表物理存储，查找速度很快。
关系数据库本质上并不包含记录之间固定关系的想法。相反，相关数据通过将一个记录的唯一键存储在另一个记录的数据中而彼此链接。例如，包含用户电子邮件地址的表格可能包含一个名为userpk的数据项，该数据项包含与其关联的用户记录的主键。为了链接用户及其电子邮件地址，系统首先查找选定的用户记录主键，在电子邮件表中查找userpk列中的那些键（或更可能是它们的索引），提取电子邮件数据，然后链接用户和电子邮件记录以制作包含所有选定数据的复合记录。这种称为连接的操作可能在计算上花费很大。根据查询的复杂程度，连接数量以及各种键的索引，系统可能需要搜索多个表和索引，收集大量信息，然后对其进行排序以将其匹配在一起。
相比之下，图形数据库直接存储记录之间的关系。用户记录不是通过在userpk列中查找其用户**找到的电子邮件地址，而是具有直接指向电子邮件地址记录的指针。也就是说，选择一个用户后，指针可以直接跟在电子邮件记录上，不需要搜索电子邮件表来查找匹配的记录。这可以消除昂贵的连接操作。例如，如果搜索地区代码为“311”的用户的所有电子邮件地址，则引擎将首先执行常规搜索以在“311”中查找用户，但是通过遵循在“311”中找到的链接来检索电子邮件地址那些记录。关系数据库首先会找到“311”中的所有用户，提取pk列表，用这些pk对电子邮件表中的任何记录执行另一次搜索，并将匹配的记录链接在一起。对于这些类型的常见操作，图形数据库（理论上至少）显着更快。
当执行多于一个级别的搜索时，图表方法的真实价值变得明显。例如，考虑在“311”区域代码中搜索具有“订户”（将用户链 接到其他用户的表）的用户。在这种情况下，关系数据库必须首先查找区号为“311”的所有用户，然后在订户表中查找任何这些用户，然后查看用户表以检索匹配的用户。相反，图形数据库将查找“311”中的所有用户，然后通过订户关系跟随后向链路来查找订户用户。这避免了几次搜索，查找以及内存占用所有来自构建输出所需的多个记录的临时数据。从技术上讲，这种查找在O（log（n））+ O（1）时间内完成，即大致相对于数据大小的对数。相比之下，关系版本将是多个O（log（n））查找，加上更多时间来加入所有数据。
图检索的相对优势随着查询的复杂性而增加。例如，有人可能想要知道“那部与潜艇相关的电影，与那位在”飘“中扮演主角的其他演员在电影中的演员。首先，系统要找到“飘”中的演员，找到他们所在的所有电影，找到所有那些不是“飘”中主角的电影中的所有演员，然后找到所有电影他们进来了，最后把这个清单过滤到那些含有“潜艇”的描述中。在关系数据库中，这将需要通过电影和演员表进行几次单独搜索，对潜艇电影进行另一次搜索，找到这些电影中的所有演员，然后比较（大）收集的结果。相比之下，图形数据库将简单地从“飘”到克拉克盖博，收集他所在电影的链接，将这些电影中的链接收集到其他演员，然后按照这些演员的链接返回到电影列表。然后可以搜索结果列表的电影“潜艇”。所有这些都可以通过一次搜索完成。
属性为这个结构添加了另一个抽象层，这也改进了许多常见的查询。 属性本质上是可以应用于任何记录的标签，或者在某些情况下还可以应用于边缘。 例如，可以将Clark Gable标记为“演员”，然后让系统快速找到所有的演员记录，而不是导演或摄像机操作员。 如果边缘上的标签被允许，还可以将“飘”和“克拉克盖博”之间的关系标记为“主角”，并且通过搜索电影“飘”中的“主角”“演员” 数据库将制作Vivien Leigh，Olivia de Havilland和Clark Gable。 等价的SQL查询将不得不依赖表中链接人员和电影的表中添加的数据，从而增加查询语法的复杂性。 这些标签可以在某些情况下提高搜索性能，但通常在为最终用户提供额外语义数据方面更为有用。
关系数据库非常适合平面数据布局，数据之间的关系是一层或两层深度。 例如，会计数据库可能需要查找给定客户的所有发票的所有行项目，即三连接查询。 图数据库旨在包含更多链接的数据集。 它们特别适合社交网络系统，其中“朋友”关系基本上是无限的。 这些属性使图形数据库自然适用于在线系统和大数据环境中日益普遍的搜索类型。 出于这个原因，图形数据库变得非常受Facebook，Google，Twitter等大型在线系统以及记录之间深层链接的类似系统的欢迎。
与关系数据库相比，图数据库对于关联数据集往往更快，并且更直接地映射到面向对象应用程序的结构。由于它们通常不需要昂贵的连接操作（在逻辑和物理层面上对具有非优化设计的数据库执行时，这种昂贵的手段），所以它们可以更自然地扩展到大数据集。由于他们对硬性架构的依赖程度较低，因此它们更适合通过演进架构管理临时数据和更改数据。相反，关系数据库管理系统在大量数据元素上执行相同操作时通常更快，从而允许以其自然结构操纵数据。
图形数据库是图形查询的强大工具。例如，计算图中两个节点之间的最短路径。其他类似图形的查询可以以自然的方式在图形数据库上执行（例如图形的直径计算或社区检测）。