AgensGraph is a multi-model database based on PostgreSQL RDBMS, and supports both relational and graph data models. AgensGraph enables developers to integrate the legacy relational data model and the flexible graph data model in one database. AgensGraph supports Ansi-SQL and Open Cypher. SQL queries and Cypher queries can be integrated into a single query in AgensGraph. AgensGraph provides database features essential to the enterprise database environment including ACID transactions, multi-version concurrency control, stored procedure, triggers, constraints, sophisticated monitoring and a flexible data model (JSON). ![Architecture](https://bitnine.net/documentations/images/AGArchitecture.png) AgensGraph is designed to offer all the features provided by PostgreSQL and process graph queries using Cypher, a graph query language. Internally, they are largely divided into the PostgreSQL processor and the Graph processor, both of which jointly use cache and transaction areas. Users may take advantage of better performance and more convenient implementation by simultaneously performing SQL and Cypher queries on a single query.
AgensGraph is a multi-model database. AgensGraph supports both the property graph model and the relational model. The property graph model contains connected entities, which can have any number of attributes. In AgensGraph, an entity is known as a vertex. Vertices can have an arbitrary number of attributes and can be categorized with labels. Labels are used to group vertices in order to represent some categories of vertices; i.e. representing the role of a person. Edges are directed connections between two vertices. Edges can also have attributes and categorized labels like vertices. In AgensGraph, an edge always has a start vertex and an end vertex. If a query tries to delete a vertex, it must delete all its edges first. Broken edges cannot exist in AgensGraph. ![Simple Data Model](https://bitnine.net/documentations/images/simple_model.png) In AgensGraph, several databases can be created and each database can contain one or more schemas and graphs. Schemas are for relational tables, and graph objects are for graph data. Schema name and graph name can not be the same. Vertices and edges are grouped into labels. There are two kinds of labels: vertex labels and edge labels. Users can create several graphs in a database but only one graph could be used at one time.
AgensGraph support index type including *BTree*, *Hash*, *Gist*, *Gin* in relational model. The *Gin* index can be used to efficiently search for a key or a key/value pair in a number of JSONB documents. The *GiST* and *SP-GiST* indexes are used to generate table columns of range type. User use the following statement to create index *index_name* on specified attribute using *index_type* method. The default method is *BTree*. CREATE INDEX index_name ON attribute USING index_type; The relational model index of the backend forks from **PostgreSQL 10.3** and **PostgreSQL 10.4**.
AgensGraph support transaction level isolation including *Read Commited*, *Read Uncommited*, *Repeated Read* and *Serializable*. This part of the backend forks from *PostgreSQL*.
The query planner of AgensGraph supports hash join, nested-loop join and merge join. In default, all of these joins method are enabled, and users can use the following methods to turn them off. enable_nestloop (boolean) enable_mergejoin (boolean) enable_hashjoin (boolean)
The SQL query executor processes a tree of "plan nodes". The plan tree is essentially a demand-pull pipeline of tuple processing operations. Each node, when called, will produce the next tuple in its output sequence, or NULL if no more tuples are available. If the node is not a primitive relation-scanning node, it will have child node(s) that it calls in turn to obtain input tuples. The SQL query executor of the database backend forks from **PostgreSQL 10.3**.
AgensGraph supports Ansi-SQL and Open Cypher. SQL queries and Cypher queries can be integrated into a single query in AgensGraph. Hybrid Query performs aggregation and statistical processing on table and column by using SQL query used in RDB,and the Cypher query used by GDB supports better data query than RDB’s Join operation. Since the result of a Cypher query is a relation, users can use a Cypher query in the FROM clause of SQL as if it is a subquery. It is possible to use Cypher syntax inside the FROM clause to utilize dataset of vertex or edge stored in graph DB as data in SQL statement. When querying the content of the graph DB with the cypher queries, you can use the match and where clause when you want to search using specific data of the RDB. However, the resulting dataset in the SQL queries must be configured to return a single row of results.
AgensGraph stores the relational storage in disk. Memory is used as shared-buffer to accelerate queries. The relational storage part of the database backend fork from **PostgreSQL 10.3**.
AgensGraph can also write user-defined functions in languages other than SQL and C. These other languages are generally referred to as procedural languages (PLs). In the case of functions written in procedural languages, the database server cannot interpret the function’s source text. Thus, the task is passed to a special handler that knows the details of the language. The handler performs all the tasks, including parsing, syntax analysis, and execution. The handler itself is a C language function that, like any C other functions, is compiled into a shared object and loaded on demand. Current AgensGraph has four procedural languages: PL/pgSQL, PL/Tcl, PL/Perl, and PL/Python.
Bitnine Co, Ltd.
Commercial, Open Source
Linux, OS X, Windows