Stardog Logo

Stardog is the world’s leading Knowledge Graph platform for the Enterprise. Stardog makes it fast and easy to turn enterprise data into knowledge.

Check out the Quick Start Guide to get Stardog installed and running in five easy steps.


Stardog 5.2 (9 January 2018) supports the RDF graph data model; SPARQL query language; property graph model and Gremlin graph traversal language; OWL 2 and user-defined rules for inference and data analytics; virtual graphs; geospatial query answering; and programmatic interaction via several languages and network interfaces.

Stardog is made by hand with skill, taste, and a point of view in DC, Boston, Heidelberg, Madison, Moscow, Hanalei, South Dakota, Porto, Manchester, PA, Columbia, MO, Pittsburgh, San Francisco, and Oakland. 🌟🐶

To learn more about where we’ve been and where we’re headed, consult the RELEASE NOTES and milestones.

Downloading & Support

Download Stardog to get started. The Stardog support forum is the place to report bugs, ask questions, etc.


There are several open source components of Stardog; feel free to submit pull requests: stardog-docs, stardog.js, stardog-groovy, stardog-spring, stardog.rb, and stardog-clj. Many thanks to Stardog customers, users, contributors, testers, etc. You know who you are, and so do we. Thank you![1] You can also help by editing these docs on Github if you spot a problem.

Enterprise Support

Customers with Enterprise Premium Support have access to some extra capabilities and services. Enterprise Premium Support is available as of Stardog 3 release. Email for details.

Real-time Support

Get access to the core Stardog development team in real-time via voice or chat. Let us help you get the most from Stardog, 24/7. Our core team has more semantic graph application and tool development experience than any other team on the planet. Other vendors shunt you off to inexperienced level one techs. We’ve never done that and never will.

Private Maven Repositories

See Using Maven for details; this includes a per-customer, private Maven repository, CDN-powered, for 24/7 builds, updates, and feature releases.

We’re also tying Maven and Docker together, providing private Docker repositories for customers, which allows us to build out clusters, custom configurations, best practices, and devops tips-and-tricks into custom Docker images…​so that you don’t have to.

Private Docker Repositories

Docker-based deliverables not only shortens your development and devops cycles but keeps you up-to-date with the latest-greatest versions of Stardog, including security fixes, performance hot fixes, and deployment best practices and configurations.

Priority Bug Fixes

With Maven and Docker in place, we’ve got a software delivery mechanism ready to push priority bug fixes into your enterprise as soon as they’re ready. We’ve averaged one Stardog release every two weeks since 2012. Enterprise Premium Support customers can now take advantage of our development pace in a controlled fashion.

Priority Feature Releases

We hate holding new features in a feature branch, especially for mundane business reasons; we want to release new stuff as soon as possible to our customers. With Enterprise Premium Support, we can maintain a disruptive pace of innovation without disrupting you.

Quick Start Guide


It just doesn’t get any easier than this: Stardog runs on Java 8. Stardog runs best on, but does not require, a 64-bit JVM that supports sun.misc.Unsafe.


We optimize Stardog out-of-the-box for ease and simplicity. You should take additional steps to secure it before production deployment. It’s easy and it’s smart, so just do it. In case that’s not blunt enough:

Stardog ships with an insecure but usable default setting: the super user is admin and the admin password is "admin". This is fine until it isn’t, at which point you should read the Security section.

Upgrading to Stardog 5

If you are upgrading to Stardog 5 from any previous version, please see Migrating to Stardog 5 for details about auto-migrating on-disk indexes.

Package Managers

As of version 5.0.6 Stardog is available in rpm and deb packages and apt and yum respositories have been setup to make installation easier.

Debian Based Systems

To install Stardog using apt-get run the following commands:

curl | apt-key add
echo "deb stable main" >> /etc/apt/sources.list
apt-get update
apt-get install -y stardog

This will first add the Stardog gpg key to the systems and then fetch and install the latest Stardog deb package.

RPM Based Systems

To install Stardog using yum run the following commands:

curl > /etc/yum.repos.d/stardog.repo
yum install -y stardog

Package Layout

The packages require that OpenJDK 8 and all of its dependecies are installed on the system. The package managers will install them if they are not already there. Stardog is then configured to start on boot via systemd and thus it can be controlled by the systemctl tool as shown below:

systemctl start stardog
systemctl restart stardog
systemctl stop stardog

To customize the environment in which stardog is run the file /etc/ can be altered with key value pairs, for example:

export STARDOG_HOME=/var/opt/stardog
export STARDOG_JAVA_ARGS="-Xmx8g -Xms8g -XX:MaxDirectMemorySize=2g"

Linux and OSX

First, tell Stardog where its home directory (where databases and other files will be stored) is:

$ export STARDOG_HOME=/data/stardog

Note: If using a package manager this line is added to the /etc/ file.

If you’re using some weird Unix shell that doesn’t create environment variables in this way, adjust accordingly. If STARDOG_HOME isn’t defined, Stardog will use the Java user.dir property value.

You should consider the upgrade process when setting STARDOG_HOME for production or other serious usage. In particular, you probably don’t want to set the directory where you install Stardog as STARDOG_HOME as that makes upgrading less easy. Set STARDOG_HOME to some other location.

Second, copy the stardog-license-key.bin into the right place:

$ cp stardog-license-key.bin $STARDOG_HOME

Of course stardog-license-key.bin has to be readable by the Stardog process.

Stardog won’t run without a valid stardog-license-key.bin in STARDOG_HOME.

Third, start the Stardog server. By default the server will HTTP on port 5820.

$ ./stardog-admin server start

Fourth, create a database with an input file:

$ ./stardog-admin db create -n myDB data.ttl

Fifth, query the database:

$ ./stardog query myDB "SELECT DISTINCT ?s WHERE { ?s ?p ?o } LIMIT 10"

You can use the Web Console to search or query the new database you created by visiting http://localhost:5820/myDB in your browser.

Now go have a drink: you’ve earned it.


Windows…​really? Okay, but don’t blame us if this hurts…​The following steps are carried out using the Windows command prompt which you can find under Start  Programs  Accessories  Command Prompts or Start  Run  cmd.

First, tell Stardog where its home directory (where databases and other files will be stored) is:

> set STARDOG_HOME=C:\data\stardog

Second, copy the stardog-license-key.bin into the right place:

> COPY /B stardog-license-key.bin %STARDOG_HOME%

The /B is required to perform a binary copy or the license file may get corrupted. Of course stardog-license-key.bin has to be readable by the Stardog process. Finally, Stardog won’t run without a valid stardog-license-key.bin in STARDOG_HOME.

Third, start the Stardog server. By default the server will expose HTTP on port 5820.

> stardog-admin.bat server start

This will start the server in the current command prompt, you should leave this window open and open a new command prompt window to continue.

Fourth, create a database with some input file:

> stardog-admin.bat db create -n myDB data.ttl

Fifth, query the database:

> stardog.bat query myDB "SELECT DISTINCT ?s WHERE { ?s ?p ?o } LIMIT 10"

You can use the Web Console to search or query the new database you created by hitting http://localhost:5820/myDB in your browser.

You should drink the whole bottle, brave Windows user!

Using Stardog

Stardog supports SPARQL, the W3C standard for querying RDF graphs, as well as a range of other capabilities, including updating, versioning exporting, searching, obfuscating, and browsing graph data.


Stardog supports SPARQL 1.1 and also the ( [OWL 2 Direct Semantics entailment regime].

To execute a SPARQL query against a Stardog database, use the query subcommand with a query string, a query file, or the name of a stored query:

$ stardog query myDb "select * where { ?s ?p ?o }"

By default, all Stardog CLI commands assume the server is running on the same machine as the client using port 5820. But you can interact with a server running on another machine using a full connection string:

$ stardog query http://myHost:9090/myDb "select * where { ?s ?p ?o }"

Detailed information on using the query command in Stardog can be found on its man page. See Managing Stored Queries section for configuration, usage, and details of stored queries.

Path Queries

Stardog extends SPARQL for path queries which can be used to find paths between two nodes in a graph. Path queries are similar to SPARQL property paths that recursively traverse a graph and find two nodes connected via a complex path of edges. But SPARQL property paths only return the start and end nodes of a path. Stardog path queries return all the intermediate nodes on the path and allow arbitrary SPARQL patterns to be used in the query.

Here’s a simple path query to find how Alice and Charlie are connected to each other:

$ stardog query exampleDB "PATHS START ?x = :Alice END ?y = :Charlie VIA ?p"

|    x     |     p      |    y     |
| :Alice   | :knows     | :Bob     |
| :Bob     | :worksWith | :Charlie |
|          |            |          |
| :Alice   | :worksWith | :Carol   |
| :Carol   | :knows     | :Charlie |

Query returned 2 paths in 00:00:00.056

Each row of the result table shows one edge. Adjacent edges are printed on subsequent rows of the table. Multiple paths in the results are separated by an empty row.

Path queries by default return only the shortest paths. See the Path Queries chapter for details about finding different kinds of paths, e.g. all paths (not just shortest ones), paths between all nodes, and cyclic paths.


SPARQL’s DESCRIBE keyword is deliberately underspecified. In Stardog a DESCRIBE <theResource> query retrieves the predicates and objects for all the triples for which <theResource> is the subject. There are, of course, about seventeen thousand other ways to implement DESCRIBE; we’ve implemented four or five of them and may expose them to users in a future release of Stardog based on user feedback and requests.

Query Functions

Stardog supports all of the functions in SPARQL, as well as some others from XPath and SWRL. Any of these functions can be used in queries or rules. Some functions appear in multiple namespaces, but all of the namespaces will work.

See SPARQL Query Functions for the complete list.

Federated Queries

In Stardog 3.0 we added support for the SERVICE keyword[2] which allows users to query distributed RDF via SPARQL-compliant data sources. You can use this to federate queries between several Stardog databases or Stardog and other public endpoints.

Stardog doesn’t support variables for the service URL (SERVICE ?serviceURL).

Stardog ships with a default Service implementation which uses SPARQL Protocol to send the service fragment to the remote endpoint and retrieve the results. Any endpoint that conforms to the SPARQL protocol can be used.

The Stardog SPARQL endpoint is http://<server>:<port>/{db}/query.

HTTP Authentication

Stardog requires authentication. If the endpoint you’re referencing with the SERVICE keyword requires HTTP authentication, credentials are stored in a password file called services.sdpass located in STARDOG_HOME directory. The default Service implementation assumes HTTP BASIC authentication; for services that use DIGEST auth, or a different authentication mechanism altogether, you’ll need to implement a custom Service implementation.

Querying RDBMS via Virtual Graphs

Sometimes enterprise information belongs to or in a Stardog graph but for various reasons the upstream or canonical data source should not be disturbed, consolidated, or decommissioned.

In those (and other) cases it makes sense to use Stardog’s R2RML[3] mapping feature to create virtual graphs, that is, mappings between a Stardog graph and external data sources such that Stardog will query the external data sources—​by rewriting SPARQL to SQL automatically—​as if they were actually materialized in Stardog.

See the Enterprise Data Unification chapter for configuration and usage.

Querying Geospatial Data

This works more or less like any SPARQL query, as long as the right geospatial vocabulary is used in the data.

See the Geospatial Query chapter for configuration and usage.


Stardog supports graph traversals via Gremlin Console and TinkerPop 3 APIs. You can write Gremlin traversals against TP3 APIs in many different languages. But the easiest way to use Gremlin with Stardog is via the Gremin Console.


There are many ways to update the data in a Stardog database; two of the most commonly used methods are the CLI and SPARQL Update queries, each of which are discussed below.


SPARQL 1.1 Update can be used to insert RDF into or delete RDF from a Stardog database using SPARQL query forms INSERT and DELETE, respectively.

PREFIX dc: <>
PREFIX ns: <>
  GRAPH <http://example/bookStore> { <http://example/book1>  ns:price  42 }

An example of deleting RDF:

PREFIX dc: <>

  <http://example/book2> dc:title "David Copperfield" ;
                         dc:creator "Edmund Wells" .

Or they can be combined with WHERE clauses:

PREFIX foaf:  <>

WITH <http://example/addresses>
DELETE { ?person foaf:givenName 'Bill' }
INSERT { ?person foaf:givenName 'William' }
  { ?person foaf:givenName 'Bill' }
Per the SPARQL Update spec, Stardog treats Update queries as implicitly transactional and atomic. Since Stardog does not support nested transactions, it will not (currently) support an Update query in an open transaction.[4]

Adding Data with the CLI

As of Stardog 5.2, the most efficient way to load data into Stardog is at database creation time. See the Creating a Database section for bulk loading data at database creation time. To add data to an existing Stardog database, use the add command:

$ stardog data add myDatabase 1.rdf 2.rdf 3.rdf

The optional arguments are -f (or --format) to specify the RDF serialization type of the files to be loaded; if you specify the wrong type, add will fail. If you don’t specify a type, Stardog will try to determine the type on its own based on the file extension. For example, the files that have names ending with '.ttl' will be parsed with Turtle syntax. If you specify a type, then all the files being loaded must of that same type.

If you want to add data to a named graph, specify it via the --named-graph or -g options.

Removing Data with the CLI

To remove data, use remove with the following input(s):

  1. one Named Graph, or

  2. one or more files containing RDF (in some recognized serialization format, i.e., RDF/XML, Turtle, Trig), or

  3. one Named Graph and one or more RDF files.

For example,

$ stardog data remove -g http://foo myDatabase

will remove the named graph http://foo and all its triples from myDatabase.

$ stardog data remove myDatabase 1.rdf

will remove the triples in 1.rdf from (the default graph of) myDatabase.

$ stardog data remove -g http://foo -f TURTLE myDatabase 2.rdf 3.rdf

will remove the triples in the Turtle files 2.rdf and 3.rdf from the named graph http://foo of myDatabase.

How Stardog Handles RDF Parsing

RDF parsing in Stardog is strict: it requires typed RDF literals to match their explicit datatypes, URIs to be well-formed, etc. In some cases, strict parsing isn’t ideal—it may be disabled using the strict.parsing configuration option.

However, even with strict parsing disabled, Stardog’s RDF parser may encounter parse errors from which it cannot recover. And loading data in lax mode may lead to unexpected SPARQL query results. For example, malformed literals ("2.5"^^xsd:int) used in filter evaluation may lead to undesired results.


Stardog supports graph change management capability that lets users track changes between revisions of a Stardog database, add comments and other metadata to the revisions, extract diffs between those revisions, tag revisions with labels, and query over the revision history of the database using SPARQL.

For a more detailed tutorial on using Stardog versioning, see the stardog-examples repo.

Versioning support for a database is disabled by default but can be enabled at any time by setting the configuration option versioning.enabled to true. For example, you can create a database with versioning support as follows:

$ stardog-admin db create -o versioning.enabled=true -n myDb

This option can also be set after database creation using the stardog-admin metadata set command.

The following examples give a very brief overview of this capability; see the Man Pages for all the details.

Committing Changes

Commit a new version by adding and removing triples specified in files. Different from the data add/remove commands, commit allows one to add and remove triples in one commit and to associate a commit message.

To commit changes:

$ stardog vcs commit --add add_file1.ttl add_file2.ttl --remove remove_file.ttl -m "This is an example commit" myDb

It is also possible to run an update query with a commit message:

Removals are performed before additions and queries are executed last.
$ stardog vcs commit --query update.sparql -m "This is another commit" myDb

If the database is updated through the regular data add, data remove, or query commands when versioning is enabled, a corresponding version will be created but the commit message will be empty.

Viewing Revisions

To see all revisions (commits) in a database:

$ stardog vcs list myDb
$ stardog vcs list --committer userName myDb

The output can be tweaked using --after, --before, and --committer.

Reverting Revisions

You can revert specific revisions, ranges, etc.

$ stardog vcs revert myDb
$ stardog vcs revert myDb de44369d-cc7b-4244-a3fb-3f6e271420b0

Viewing Diffs

You can also see the differences between revisions; by default, between the head version and its previous versions or the changes in a specific commit, respectively:

$ stardog vcs diff myDb
$ stardog vcs diff myDb de44369d-cc7b-4244-a3fb-3f6e271420b0
Diffs are represented as SPARQL Update queries so that they may be used as a kind of graph patch.

Using Tags

You can also create, drop, list tags, i.e., named revisions:

$ stardog vcs tag --list myDb

Querying the Revision History

The revision history of the database is represented as RDF using an extended version of the W3C PROV vocabulary and can be queried using SPARQL.[5] The following query retrieves all the versions:

SELECT ?author ?msg ?date {
  ?v a vcs:Version ;
     rdfs:comment ?msg ;
     prov:wasAttributedTo / rdfs:label ?author ;
     prov:generatedAtTime ?date

You can execute versioning queries using the vcs query command:

$ stardog vcs query myDb versioning-query.sparql

Queries executed by vcs query only query the versioning history and automatically recognizes the vcs and prov namespaces. If you would like to query the current state of the database along with the version history then you can run a regular query using a special versioning SERVICE. The following query finds the instances of foaf:Person class that has been modified in the last 24 hours:

PREFIX prov: <>
PREFIX vcs: <tag:stardog:api:versioning:>

  ?x a foaf:Person

  SERVICE vcs:service {
    ?v a vcs:Version;
       prov:generatedAtTime ?date;
       vcs:updates/(vcs:additions|vcs:removals) ?update
    GRAPH ?update {
      ?x ?p ?o
    FILTER (NOW() - ?date < 'PT24H'^^xsd:dayTimeDuration)

You can run this query using the regular query command:

$ stardog query myDb versioning-mixed-query.sparql

Note that, in this query the namespaces vcs and prov have been declared explicitly in the query. If you register these namespaces to your database then you can omit these declarations.

For more details about the Stardog versioning representation, see the stardog-examples repo.


To export data from a Stardog database back to RDF, export is used by specifying

  1. the name of the database to export

  2. optionally, the URIs of the named graphs to export if you wish to export specific named graphs only. Keywords DEFAULT and ALL can be used as values of the --named-graph parameter to export the default graph and all graphs, respectively

  3. the export format: N-TRIPLES, RDF/XML, TURTLE, TRIG. The default is N-TRIPLES. TRIG must be used when exporting the entire database if the database contains triples inside named graphs

  4. a file to export to

For example,

$ stardog data export --format TURTLE myDatabase myDatabase_output.ttl

$ stardog data export --named-graph myDatabase myDatabase_output.nt


Stardog includes an RDF-aware semantic search capability: it will index RDF literals and supports information retrieval-style queries over indexed data. See Managing Search for more details.

Searching with the Command Line

First, check out the search man page:

$ stardog help query search

Okay, now let’s do a search over the O’Reilly book catalog in RDF for everything mentioning "html":

$ stardog query search -q "html" -l 10 catalog

The results?

| Index | Score |                        Hit                        |
| 1     | 6.422 | |
| 2     | 6.422 | |
| 3     | 6.422 | |
| 4     | 6.422 | |
| 5     | 6.422 | |
| 6     | 6.422 | |
| 7     | 6.422 | |
| 8     | 6.422 | |
| 9     | 6.422 | |
| 10    | 6.422 | |

See Search for more details.


When sharing sensitive RDF data with others, you might want to (selectively) obfuscate it so that sensitive bits are not present, but non-sensitive bits remain. For example, this feature can be used to submit Stardog bug reports using sensitive data.

Data obfuscation works much the same way as the export command and supports the same set of arguments:

$ stardog data obfuscate myDatabase obfDatabase.ttl

By default, all URIs, bnodes, and string literals in the database will be obfuscated using the SHA256 message digest algorithm. Non-string typed literals (numbers, dates, etc.) are left unchanged as well as URIs from built-in namespaces (RDF, RDFS, and OWL). It’s possible to customize obfuscation by providing a configuration file.

$ stardog data obfuscate --config obfConfig.ttl myDatabase  obfDatabase.ttl

The configuration specifies which URIs and strings will be obfuscated by defining inclusion and exclusion filters. See the example configuration file in the stardog-examples Github repo.

Once the data is obfuscated, queries written against the original data will no longer work. Stardog provides query obfuscation capability, too, so that queries can be executed against the obfuscated data. If a custom configuration file is used to obfuscate the data, then the same configuration should be used for obfuscating the queries as well:

$ stardog query obfuscate --config obfConfig.ttl myDatabase myQuery.sparql > obfQuery.ttl


The Stardog Web Console is a responsive web app for the Stardog Server and for every Stardog database that makes administration and interaction with data quick and easy; you can access it at http://foo:5820 where foo is the name of the machine where Stardog is running.

A Screenshot Tour…​

Seriously, this is a lot more fun if you just download the damn thing and hit it with a browser!