Configuring a Repository

Before you start adding or changing the parameter values, we recommend planning your repository configuration and familiarizing yourself with what each of the parameters does, what data structures GraphDB supports, what configuration values are optimal for your setup, etc.

Configure a repository through the GraphDB Workbench

To configure a new repository, complete its properties form.



If you need a repository with enabled SHACL validation, you must enable this option at configuration time. SHACL validation cannot be enabled after the repository has been created.

Edit a repository

Some of the parameters you specify at repository creation time can be changed at any point.

  1. Click the Edit icon next to a repository to edit it.

  2. Restart the repository for the changes to take effect.

Configure a repository programmatically


GraphDB uses an RDF4J configuration template for configuring its repositories. RDF4J keeps the repository configurations with their parameters modeled in RDF. Therefore, in order to create a new repository, the RDF4J needs such an RDF file.

To configure a new repository programmatically:

  1. Fill in the graphdb.ttl configuration template that can be found in the /configs/templates directory of the GraphDB distribution. The parameters are described in the Configuration parameters section. Here is an example:

    # Example RDF4J configuration template for a GraphDB repository named "wines"
    @prefix rdfs: <> .
    @prefix rep: <> .
    @prefix sail: <> .
    @prefix xsd: <> .
    <#wines> a rep:Repository;
        rep:repositoryID "wines";
        rep:repositoryImpl [
            rep:repositoryType "graphdb:SailRepository";
            <> [
                <> "";
                <> "false";
                <> "";
                <> "true";
                <> "false";
                <> "false";
                <> "true";
                <> "true";
                <> "32";
                <> "10000000";
                <> ("default" "iri");
                <> "none";
                <> "default";
                <> "";
                <> "true";
                <> "0";
                <> "0";
                <> "false";
                <> "file-repository";
                <> "rdfsplus-optimized";
                <> "storage";
                sail:sailType "graphdb:Sail"
        rdfs:label "" .

Configuration parameters

This is a list of all repository configuration parameters. Some of the parameters can be changed (effective after a restart), some cannot be changed (the change has no effect) and others need special attention once a repository has been created, as changing them will likely lead to inconsistent data (e.g., unsupported inferred statements, missing inferred statements, or inferred statements that cannot be deleted).

Parameter name


Default value


Specifies the default namespace for the main persistence file. Non-empty namespaces are recommended, because their use guarantees the uniqueness of the anonymous nodes that may appear within the repository.

Can be changed.

Enables or disables the mechanism for consistency checking. If this parameter is true, consistency checks are defined in the rule file and applied at the end of every transaction. If an inconsistency is while committing a transaction, the whole transaction will be rolled back.

Can be changed.


Default namespaces corresponding to each imported schema file, separated by semicolon. The number of namespaces must be equal to the number of schema files from the imports parameter. Example: graphdb:defaultNS ";"

Warning: This parameter cannot be set via a command line argument.
Cannot be changed.

Enables or disables the owl:sameAs optimization.

Warning: This parameter needs special attention.
Can change in the UI depending on the ruleset.

Possible value: true, where GraphDB will build and use the context index.

Can be changed.

Enables or disables the storage. The literal index is always built as data is loaded/modified. This parameter only affects whether the index is used during query answering.

Can be changed.

Enables or disables mappings from an entity (subject or object) to its predicates; enabling it can significantly speed up queries that use wildcard predicate patterns.

Can be changed.

Enables or disables the full-text search index. In general, searching is performed via SPARQL queries using a pattern like this:

?value onto:fts (query index limit)

Can be changed.

Comma-delimited list of languages that should have a specific index with an appropriate analyzer for full-text search.

Possible values: default, iri, ar, bg, bn, br, ca, ja, ko, zh, ku, cz, da, de, el, en, es, et, eu, fa, fi, fr, ga, gl, hi, hu, hy, id, it, lt, lv, ne, nl, no, pt, ro, ru, sr, sv, ta, te, th, tr
default, iri
Can be changed.

The index in which the string literals (xsd:string) are indexed.

Possible values: none, default, or a 2-letter language code.

Can be changed.

The index in which the IRIs are indexed for full-text search.

Possible values: none, default, or a 2-letter language code.

Can be changed.


Defines the bit size of internal IDs used to index entities this parameter can be left at its default value. However, if using very large datasets containing over 2 31 entities, set this parameter to 40. Be aware that this can only be set when instantiating a new repository, and that converting an existing repository from 32 to 40-bit entity widths is not possible.

Possible values: 32 and 40.
Cannot be changed.

Defines the initial size of the entity hash table index entries. The bigger the size, the fewer the collisions in the hash table, and the faster the entity retrieval. The entity hash table will adapt to the number of stored entities once the number of collisions passes a critical threshold.

Warning: Once initially set, this parameter cannot be changed by the user.


Tip: Schema files can be either a local path name, e.g., ./ontology/myfile.rdf or a URL, e.g., If this parameter is used, the default namespace for each imported schema file must be provided using the defaultNS parameter.

A list of schema files that will be imported at startup. All statements found in these files will be loaded in the repository and will be treated as read-only. The serialization format is determined by the file extension:

  • .brf => BinaryRDF

  • .n3 => N3

  • .nq => N-Quads

  • .nq => N-Quads

  • .nt => N-Triples

  • .owl => RDF/XML

  • .rdf => RDF/XML

  • .rdfs => RDF/XML

  • .trig => TriG

  • .trix => TriX

  • .ttl => Turtle

  • .xml => TriX

Example: graphdb:imports "./ont/owl.rdfs;./ont/ex.rdfs"
Cannot be changed.

Enables or disables caching of the literal languages and data types. If the caching is on and the entity pool is restored from persistence, but there is no such cache available on disk, it is created after the entity pool initialization.

Can be changed.


Colon-separated list of predicates (full URLs) that GraphDB will not try to process with the registered GraphDB plugins. (Predicates processed by registered plugins are often called “Magic” predicates). This optimization will speed up the data loading by providing a hint that these predicates are not magic.


Sets the maximum number of results returned from a query after which he evaluation of a query will be terminated; values less than or equal to zero mean no limit.

0; (no limit)
Can be changed.

Sets the number of seconds after which the evaluation of a query will be terminated; values less than or equal to zero mean no limit.

0; (no limit)
Can be changed.


In this mode, no modifications to the data or namespaces are allowed.

Possible value: true, puts the repository in read-only mode.
Can be changed.


In this mode, no modifications to the data or namespaces are allowed.

Possible values: file-repository, weighted-file-repository.
Cannot be changed.

Sets of axiomatic triples, consistency checks and entailment rules, which determine the applied semantics.

Possible values: empty, rdfs, owl-horst, owl-max, and owl2-rl, and their optimized counterparts rdfs-optimized, owl-horst-optimized, owl-max-optimized, and owl2-rl-optimized. A custom ruleset is chosen by setting the path to its rule file .pie.
Warning: This parameter needs special attention.



Specifies the folder where the index files will be stored.

Can be changed.


Possible value: true; if set, a QueryEvaluationException is thrown when the duration of a query execution exceeds the timeout parameter and a log entry is made. When this is set to false, no log entry is made.

Can be changed.


Under Setup ‣ Namespaces in the GraphDB Workbench, you can view and manipulate the RDF namespaces and prefixes for the active repository. Each GraphDB repository contains the following predefined prefixes:





The GeoNames Ontology makes it possible to add geospatial semantic information to the Word Wide Web. Over 11 million geonames toponyms have a unique URL with a corresponding RDF web service.


As with RDFS, properties in OWL are used to link things together. OWL provides a rich and complex vocabulary for saying things about these links. It allows you to construct some fairly complex, but useful, relationships among classes.


GraphDB extends SPARQL with the Graph Path Search functionality that allows you to not only find complex relationships between resources but also explore them and use them as filters to identify graph patterns.


The RDF Schema for the RDF vocabulary terms in the RDF Namespace, defined in RDF 1.1 Concepts.


A general-purpose language for representing simple RDF vocabularies on the Web, RDF Schema is a semantic extension of RDF. It provides mechanisms for describing groups of related resources and the relationships between these resources.


GraphDB provides support for 2-dimensional geospatial data that uses the WGS84 Geo Positioning RDF vocabulary (World Geodetic System 1984).


Generally representing datatypes.


XPATH functions on datatypes.


Beside the standard SPARQL functions operating on numbers, GraphDB offers several additional functions, allowing users to do more mathematical operations.


SPIN is a W3C Member Submission that has become the de-facto industry standard to represent SPARQL rules and constraints on Semantic Web models. SPIN also provides meta-modeling capabilities that allow users to define their own SPARQL functions and query templates. Finally, SPIN includes a ready to use library of common functions.


GraphDB supports Jena simple functions analogs.



GraphDB supports Jena list functions analogs.


GraphDB supports Jena aggregate functions analogs.


GraphDB supports Jena property functions analogs.


GeoSPARQL defines a vocabulary for representing geospatial data in RDF, and it defines an extension to the SPARQL query language for processing geospatial data.


On top of the standard GeoSPARQL functions, GraphDB adds a few useful extensions based on the USeekM library.


At present, there is just one SPARQL extension function.


XPATH namespace used for some mathematical functions.


XPATH namespace used for some functions that manipulate maps.


XPATH namespace used for some functions that manipulate arrays.


Parameter namespace for an RDF4J repository configuration consisting of a single RDF subject of type rep:Repository.


Parameter namespace for an RDF4J SailRepository repository implementation, which is the main implementation for direct access to a local RDF database.


Parameter namespace for the Sail configuration.


Reserved GraphDB repository configuration namespace.

Reconfigure a repository

Once a repository is created, it is possible to change some parameters, either by editing it in the Workbench or by setting a global override for a given property.


When you change a repository parameter, you need to restart GraphDB for the changes to take effect.

Using the Workbench

To edit a repository parameter in the GraphDB Workbench, go to Setup ‣ Repositories and click the Edit icon for the repository whose parameters you want to edit.

Global overrides

It is also possible to override a repository parameter for all repositories by setting a configuration or system property. See Engine properties for more details on how to do it.

Rename a repository

Using the Workbench

Use the Workbench to change the repository ID. This will update all locations in the Workbench where the repository name is used.