schema
强制schema，不符合schema的数据无法写入；schema可选，可以不建立schema就写入数据。
Neo4j 开源版不支持多schema
开源
部分图数据库仅提供商业版本，需要付费使用，甚至只能通过云服务使用；部分图数据库既提供社区版，也提供商业版本。社区版提供大部分功能，商业版本提供附加功能，如分布式、系统监控和专家支持等；大部分图数据库的社区版本，开放了源代码。
支持中文
一般情况下，在大多数图数据库中，实体和关系属性，都会支持中文的属性名和属性值。然而大部分图数据库，并不支持中文的实体类别和关系类型。 读者可以采用编码转换的方式，将中文转换为英文和数字，然而这会增加出现BUG的概率、解决问题的难度和产品开发周期，不建议选择该办法。如果读者的实体类别和关系名称中包含中文，需要着重考虑这一点。根据作者的经验，Neo4j支持中文，其余的图数据库，大多不支持中文的实体类型和关系名称。
多库
有的图数据库，一个部署仅支持一个数据库，且一个数据库中仅有一个图；有的图数据库，在一个部署中，可以建立多个数据库，每个库中可以有多尔个图。
如果是以下几种情况，建议选择支持多库的图数据库：
a、需要为多个客户服务，每个客户间的数据需要严格隔离；
b、同时存在多个图谱，每个图谱间的读写操作应互补干扰。
如果是下列情况，可以不考虑是否支持多库：
a、仅有一个图谱，读写操作都在这个图谱上完成。
编程语言驱动
不同的图数据库，支持的编程语言驱动不一样。语言驱动有官方驱动和社区驱动之分，一般情况下建议选择官方驱动，因为部分社区驱动可能因不再维护而不支持新版本的图数据库。
通常情况下，各图数据库对Java的支持最好，其次是Python。也有部分图数据库，比如Dgraph用Golang实现的，它对Golang的支持是最好和最及时的。如果读者因项目或代码需要，只能选择某个语言，如C++或Golang等，那么应留意该图数据库是否提供了官方的语言驱动。
数据量和读写性能
部分图数据库，有实体和关系数量的限制，比如社区版本的Neo4j限制实体和关系的数量为320亿个；部分图数据库，未实现完整的分布式存储，无法将 一个大图存储在多台机器上，比如目前所有版本的Neo4j。
所以，如果在读者的场景下，存在单个的超大图，以至于单个服务器无法存储，则不能考虑Neo4j。Dgraph在图的分布式存储，有比较优秀的设计，读者可以考虑。
可维护性
JanusGraph 是可扩展的图数据库，维护成本比较高，因为底层依赖于大数据组件。存储系统依赖于像Cassandra、HBase、BerkelyDB等等这样的存储系统，索引系统依赖于Elasticsearch、Solr、Lucene等等(查询语言: Gremlin)
