SQL is the established query language for relational databases, familiar to literally millions of users. Now, as graph databases emerge as a powerful new database architecture, the world needs a standard graph query language as well.
The mission of OpenGSQL is to offer a natural extension to SQL for graph databases, supporting graph-oriented querying and transactions, including large data analytics.
The OpenGSQL project believes the best starting point is GSQL. GSQL was developed by TigerGraph (then known as GraphSQL), through years of collaboration with industry and field testing by customers. In particular, GSQL was designed to address users’ need to easily and quickly develop complex, deep-link graph queries and graph applications.
GSQL builds on the strengths and overcomes the shortcomings of the graph query languages of 1st and 2nd generation graph databases. GSQL is the conceptual descendent of Gremlin from the Apache TinkerPop framework, Hadoop MapReduce, SQL, Cypher, and SPARQL. GSQL incorporates the best elements of these predecessors, streamlining the final product for developer productivity and maximum performance for loading, queries and complex graph analytics.
Among GSQL’s features and benefits:
- SQL-like syntax throughout, for both DDL and DML statements
- Turing completeness, so you can write any function or algorithm you need (using familiar structures like IF/THEN/ELSE, FOREACH, and WHILE)
- Procedural structure, so you can parameterized queries and call queries within queries
- Built-in parallelism, with the ACCUM clause and accumulators
- Declarative loading with built-in parallelism, to make getting data into your graph fast and easy
Since the beginning, we’ve had formal specifications available to our users. You can find it at https://docs.tigergraph.com/dev/gsql-ref
White Papers and Proposals
Community Forum – Open to Suggestions
We know the work isn’t finished. The best suggestions usually come from the field, from real users solving real problems. That’s why GSQL is now open. We have a community forum
. As the community develops, we’ll find the best way to track suggestions and to respond.
Where is GSQL headed? First we want to hear your suggestions. As we reach consensus, we’ll post our roadmap for the continual improvement of GSQL. We won’t rest until GSQL is the best graph query language for both expressiveness and ease.