gStore: a graph store for RDF data with a SPARQL front end

A triple store for RDF, with SPARQL in front

gStore is described as an open-source graph database engine, or triple store, born for managing large RDF datasets with the SPARQL query language. It works with Linux systems and amd64, arm64 and loongarch processors.

The framing matters because RDF and SPARQL are specific. A triple is a subject, a predicate and an object, the data model the semantic web is built on, and SPARQL is the query language for it. gStore is not a general property graph database with a SPARQL-ish interface, and it is not a graph engine that happens to accept triples. It stores RDF properly, in n-triples format, and answers SPARQL against it.

The provenance is academic and stated up front. gStore is a collaborative effort between the Data Management Lab of Peking University, the University of Waterloo and contributors from the open source community. The formal help document is published in English and Chinese as a PDF, and there is a formal experiment result document as well, which for a database engine is an unusual thing to ship and tells you the project has been benchmarked in a way the authors are willing to publish.

There is also a citation request. If you use gStore in your research, the README asks you to cite the paper gStore: a graph-based SPARQL query engine by Zou, Ozs(u), Chen, Shen, Huang and Zhao in The VLDB Journal, volume 23, pages 565 to 590, 2014. A second BibTeX entry is provided for citing the repository itself.

For a reader today, the age of that paper is a signal to check the changelog rather than to assume the 2014 behaviour. The default branch is 1.4, and the changelog entry for 1.4 marked stable is dated 2025-12-01, so the engine has moved considerably since the VLDB paper.

What changed in the 1.4 release line

The changelog in the README describes what the 1.4 line changed, and it reads like a maintenance and operations release rather than a feature release.

The bin directory structure was reconstructed, retaining only the gserver service and gconsole operation modes. A task operation management module was added, with support to cancel time-consuming query operations, which is a real feature for a graph engine where a single SPARQL query can run unbounded. The memory management mechanism was reconstructed around on-demand memory block application, which the changelog says reduces the memory copying process and increases the efficiency of batch addition by more than 100 percent.

The custom function module was refactored, with a built-in function pfn.fun_name supporting select calls. A static gcc installation package was added to support the use of custom functions, and rpm and deb packages were added so that gstore can be installed with the rpm and dpkg commands rather than from a tarball.

The last item in the changelog is cut off in the documentation available here, which is worth noting as a documentation gap rather than a criticism: the changelog entry begins an optimization item and the text ends.

The release history in the repository metadata is older than the changelog. The listed GitHub releases are v0.7.2 from 2018-11-04, v0.7.1 from 2018-10-18 and v0.7.0 from 2018-10-14, each described as a highly available graph database system. So the tagged releases on GitHub stop in 2018 while the default branch is 1.4 and the changelog records a stable 1.4 in December 2025, with the last push on 2026-04-09. The repository is not archived, so the work is continuing, but there is no tag that matches the branch you would actually build. Plan on building from the branch rather than pinning to a release.

Getting the engine: Docker, source or a mirror

There are three ways in, and the README recommends different ones for different situations.

For users in mainland China, the project is hosted on gitee, the Chinese code cloud, and that is recommended for faster download. The address is gitee.com/PKUMOD/gStore. The GitHub repository is also available, and you can download gStore.zip and decompress it.

The Docker route is a single pull:

$ docker pull pkumodlab/gstore-docker:latest

The complete instructions are in a separate Docker deployment document in the docs directory.

From source, you clone the repository and follow the installation instructions document:

git clone https://github.com/pkumod/gStore.git

The Dockerfile in the repository is worth reading even if you use the prebuilt image, because it tells you what the build needs. It is a two stage build on ubuntu:20.04. The builder stage installs build-essential, wget, a set of Boost development packages for regex, system and thread, libcurl and its OpenSSL development package, libssl-dev, libzmq3-dev, pkg-config, zlib1g-dev, uuid-dev, libjemalloc-dev and libreadline-dev. It then builds CMake 3.23.2 from source rather than using the distribution package, and compiles the project with make pre, make and make pfnbuild, which is the custom function build target.

Two details in there are notable. ZeroMQ and OpenMPI appear in the runtime image, and the presence of libzmq3-dev suggests a message queue interface for distributed operation, which fits the highly available graph database system framing of the older release notes. And jemalloc is used as the allocator, which is a common choice for a workload with many small allocations, and a graph index is exactly that kind of workload.

The runtime stage is a second ubuntu:20.04 image with only the shared libraries and a compiler, and the built binaries are copied in from the builder stage.

Loading n-triples and running a query from the console

The data format is specific and the documentation is explicit about it. RDF data should be provided in n-triple format, and the README notes that XML is not currently supported. Queries must be provided in SPARQL 1.1 syntax.

The n-triples example in the README uses a prefix declaration and blank node identifiers:

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .	
_:a  foaf:name   "Johnny Lee Outlaw" .
_:a  foaf:mbox   <mailto:[email protected]> .
_:b  foaf:name   "Peter Goodguy" .
_:b  foaf:mbox   <mailto:[email protected]> .
_:c  foaf:mbox   <mailto:[email protected]> .

The values wrapped in angle brackets are URIs of an entity, the values in double quotes are literals representing the value of an attribute of the entity, and the ^^ suffix indicates the type of the value.

The most important limitation is stated plainly. Not all syntax in SPARQL 1.1 is parsed and answered in gStore, and the example given is that property paths are beyond the capabilities of the gStore system. That single fact shapes how you evaluate the engine, because property paths are common in real SPARQL and a query that uses one will not behave as you expect.

The operational sequence uses two binaries. The server runs in the background with:

# -b running in the background
bin/gserver -b

And the console client connects to it:

# default username is root, password is 123456
bin/gconsole -u root

From the console you create a database from a data file, list the databases, switch to one and run a query:

gStore[no database]> create lubm data/lubm/lubm.nt; 

gStore[no database]> showdbs;

gStore[no database]> use lubm;

gStore[lubm]> sparql data/lubm/lubm_q1.rq;

The example data is the LUBM dataset, the standard benchmark for RDF engines, which is a good sign for anyone planning to compare query engines.

The default credentials are root and 123456, which the README states in a comment. Change them before the server is reachable by anything but you.

Where the SPARQL support stops, and the known issues list

gStore is candid about its limits, and the documentation structure tells you where to look. The README points to a FAQ document for frequently asked questions, and says that known bugs and limitations are listed in a BUGS document and a LIMIT document in the docs directory. Those two files are the ones to read before committing, more than the README itself.

The property path limitation is the headline, and it is not a small one. Property paths are what let a SPARQL query express path expressions over the graph, a way of asking about connected resources that are not directly related. A workload that relies on them will need to be rewritten or answered differently.

The input format restriction compounds it. n-triples only, with XML not currently supported. Most RDF tools can export to n-triples, so this is a conversion step rather than a wall, but it does mean the ingestion path assumes you are prepared to serialise your data into the simplest possible RDF syntax, which is verbose and loses some conveniences of the richer serialisations.

There is a further limitation that comes from the data model itself rather than from the implementation. A triple store is a poor fit for data whose shape is not a graph, and the reverse is true of a relational schema. The choice of gStore is a statement that your data is RDF-shaped, which usually means it comes from a semantic web pipeline, an ontology-backed domain, or a link data set.

One more practical constraint is worth flagging. The engine is described as highly available in the release notes, and the Dockerfile pulls in ZeroMQ and OpenMPI, but the documentation available here does not describe the clustering configuration, the replication model, or the failure behaviour. If you are evaluating this for a multi node deployment, that is the first thing to ask about, because the distributed behaviour is where a graph engine's real differences live, and the README does not cover it.

The FAQ, BUGS and LIMIT documents, plus the online documentation with the project roadmap, are the right places to close these gaps.

Licence, maintenance and how this compares

The licence is the BSD 3-Clause, and the README points out that several third party libraries ship under their own licences, with the LICENSE file holding the details. That is the correct arrangement for a C++ engine that vendors Boost, jemalloc, ZeroMQ and other components, and the practical effect is that the gStore code itself is permissive while you still need to comply with the terms of what it links.

On maintenance, the picture is mixed and should be stated plainly. The repository is not archived and the last push was on 2026-04-09. The changelog records 1.4 as stable on 2025-12-01. The GitHub release tags, however, stop at v0.7.2 in November 2018. So the project is alive on the branch, the branch has a named stable release, and there is no tag that corresponds to it. Anyone pinning a version in a deployment has to pin a commit rather than a tag, which is workable but worth knowing before you write the deployment script.

The comparison with the other RDF stores comes down to what you need. The mainstream alternative in this space is a triple store built for the same job with a different emphasis, and the practical differences show up in three places: how completely SPARQL 1.1 is implemented, whether the engine is designed to be embedded in an application or only accessed over a protocol, and what the concurrency and durability behaviour is under load. gStore's distinguishing features as documented are a C++ implementation with its own memory management and a custom function mechanism that lets you register user defined functions callable from select, which is a genuine extension point that a plain SPARQL endpoint does not offer.

The academic angle is a real asset in a research context. The published experiment document and the LUBM example mean you can compare gStore against other engines on a standard benchmark with published numbers, rather than trusting a vendor's own claim. For an evaluation, that is worth more than any feature checklist.

For a production service, the open question is operational rather than functional. A single node gStore with the console credentials changed and a schema of queries you have verified against the LIMIT document is a reasonable deployment. A clustered deployment needs the availability documentation, which this repository does not put in the README.

Editorial conclusion

Adopt gStore if you already have RDF data in n-triples form and need a SPARQL engine you can run on your own hardware, particularly for research or benchmark workloads where the LUBM dataset and the published experiment report matter. Do not adopt it if your data is in a different RDF serialization, since XML is not currently supported, or if your queries need property paths or the rest of SPARQL 1.1, which gStore does not answer. Verify first that your query set avoids the unsupported constructs, that the default console credentials are changed before any exposure, and that the 1.4 branch you build matches the documentation you read.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. pkumod/gStore on GitHub
3. Project website
4. README
5. Releases