AgensGraph 1.1 adds graph pattern creation with MERGE

A graph application often needs to ensure that a relationship exists before proceeding with other work. Checking for the relationship and then choosing whether to create it makes graph structure part of application control flow. AgensGraph 1.1 adds a MERGE clause that expresses this intent in the query language. Its March 20 announcement describes matching a specified pattern and creating it when no such pattern exists.

The change belongs to a PostgreSQL-based database with both relational and graph models. It is not a new clause added to PostgreSQL itself. That distinction matters when reading an ecosystem announcement on the PostgreSQL website. AgensGraph's query language and distribution provide the graph behavior described here, and an ordinary PostgreSQL installation does not acquire it by applying a maintenance update.

I find the combination interesting because PostgreSQL remains my default for relational data. A graph model can justify different query syntax without making all the existing relational structure irrelevant. The useful question is how much of an application's connected data can share a database with its relational data, and what the combined query language actually expresses.

MERGE describes a graph pattern

The announcement defines MERGE in terms of a pattern. When the pattern exists, the database can match it. When it does not, AgensGraph creates the specified pattern. Optional ON MATCH and ON CREATE clauses let a query attach different behavior to those outcomes.

This puts a distinction that would otherwise appear in application branches into the graph query. The caller can describe the desired structure and provide behavior for an existing match or a newly created pattern. Reading the operation at that level is more useful than treating it as a generic synonym for insertion. The matching part is central to what the clause does.

The release announcement does not specify every concurrency or uniqueness implication of MERGE. In particular, its description alone does not establish that any chosen pattern becomes a global uniqueness constraint. A pattern-matching clause and a schema constraint answer different questions. The former describes what the query seeks and creates, while the latter defines a condition the database must enforce across relevant writes.

That boundary is important for adopting the feature accurately. The documented improvement is a way to express match-or-create graph operations and attach outcome-specific actions. Claims about stronger guarantees require the corresponding language and constraint documentation. Nothing in the short announcement supports replacing those details with assumptions drawn from a similarly named command in another database.

SQL and Cypher can share a query

The README at the 1.1.0 release tag says AgensGraph supports ANSI SQL and openCypher, and can integrate SQL and Cypher into a single query. Its multi-model claim therefore concerns query composition as well as the existence of two ways to store data. Relational data and graph data need not be accessed through entirely separate application interfaces.

The same README identifies PostgreSQL as the database on which AgensGraph is based. It lists ACID transactions, multi-version concurrency control, stored procedures, and constraints among the facilities available in that environment. These are relevant because adding a graph representation still leaves applications with ordinary database requirements. Matching relationships does not eliminate the need to coordinate changes or express data restrictions.

The practical appeal is the possibility of choosing a model for a particular part of a problem. Some information fits a relational representation, while a query about connected entities may be easier to express as a graph pattern. Supporting both languages in a query can reduce the amount of composition the application must perform outside the database.

I prefer that discussion to a claim that graph databases replace relational databases. AgensGraph's own description allows the models to coexist. The decision then concerns the meaning of the data and the queries it needs, with a concrete database implementation to evaluate.

Variable-length relationships are a separate improvement

AgensGraph 1.1 also improves variable-length edge-pattern queries. The announcement uses friends-of-friends queries to explain why this form matters. Such a query asks about relationships across a number of links, so the length of a path becomes part of the requested graph pattern.

Bitnine reports that the new version is twice as fast as 1.0 in this part of the announcement. It provides no workload definition or measurement procedure there. That is a vendor performance claim with a limited description, not evidence that every AgensGraph query doubles its throughput. The independently useful fact is that the release explicitly addresses execution of variable-length edge patterns alongside the new matching clause.

The two changes affect different parts of graph work. MERGE describes how a desired pattern relates to existing data and creation. Variable-length matching describes traversal across relationships. Keeping those subjects distinct explains more than combining them into a broad statement about graph-query improvements.

PostgreSQL integration includes external data

The release adds Hadoop FDW and a HyperLogLog datatype as external modules. Its Hadoop FDW description specifically concerns connecting to Hive systems to access HDFS files, allowing Hadoop data to be imported into AgensGraph. This extends the data available to the database without making the graph model the only subject of the release.

The versioned README also describes using PostgreSQL's extension ecosystem, with PostGIS as an example. AgensGraph's combination of graph queries, relational queries, and external modules is therefore part of a broader integration approach. Version 1.1 adds a concrete graph operation to that approach, with ON MATCH and ON CREATE giving applications explicit places to express what should happen for each matching outcome.