To configure the repository to backup its contents on disk, we can add a persist parameter with value true:

<repository id="default">
  <title>Default Repository</title>
  <sailstack>
	 <sail class="org.openrdf.sail.memory.MemoryStore">
		<param name="persist" value="true"/>
	 </sail>
  </sailstack>
  <acl worldReadable="true" worldWriteable="true" />
</repository>

If this parameter is set to value true, the repository will create an on-disk data dump (in the Sesame datadir), which will be read back into the main repository upon (re)initialization - for example, when the server is restarted.

By default, the in-memory store persistence mechanism synchronizes the disk backup directly upon any change to the contents of the store. That means that directly after any change (upload, removal) completes, the disk backup is updated.

It is possible to configure a synchronization delay however. This can be useful if your application performs several transactions in sequence and you want to prevent disk synchronization in the middle of this sequence. The synchronization delay is specified as a parameter of the sail as follows:

<sailstack>
  <sail class="org.openrdf.sail.memory.MemoryStore">
    <param name="persist" value="true"/>
	 <param name="syncDelay" value="1000"/>
  </sail>
</sailstack>

In the above example the synchronization is set to a delay of 1,000 milliseconds. This means that after every completed update the disk synchronization is delayed for 1,000ms. If in that time a new change operation (an upload or removal) is started, the synchronization is further delayed until after that operation completes (and so forth).

To configure an in-memory repository with RDF Schema entailment, we need to add an additional Sail to the Sail stack of the repository. The name of the Sail that performs inferencing for in-memory repositories is org.openrdf.sail.inferencer.MemoryStoreRDFSInferencer and it is configured as follows:

<sailstack>
  <sail class="org.openrdf.sail.inferencer.MemoryStoreRDFSInferencer"/>
  <sail class="org.openrdf.sail.memory.MemoryStore"/>
</sailstack>

The Native Repository uses on-disk indexes to speed up querying. It uses B-Trees for indexing statements, where the index key consists of four fields: subject (s), predicate (p), object (o) and context (c). The order in which each of these fields is used in the key determines the usability of an index on a specify statement query pattern: searching statements with a specific subject in an index that has the subject as the first field is signifantly faster than searching these same statements in an index where the subject field is second or third. In the worst case, the 'wrong' statement pattern will result in a sequential scan over the entire set of statements.

By default, the native repository only uses one index, with a subject-predicate-object-conctext (spoc) key pattern. However, it is possible to define more indexes for the native repository, using the triple-indexes parameter This can be used to optimize performance for query patterns that occur frequently:

<repository id="native">
  <title>Native Repository</title>
  <sailstack>
	 <sail class="org.openrdf.sail.nativerdf.NativeStore">
		<param name="triple-indexes" value="spoc, posc"/>
  </sailstack>
  <acl worldReadable="true" worldWriteable="true" />
</repository>

The subject, predicate, object and context fields are represented by the characters 's', 'p', 'o' and 'c' respectively. Indexes can be specified by creating 4-letter words from these three characters. Multiple indexes can be specified by separating these words with commas, spaces and/or tabs. For example, the string "spoc, posc" specifies two indexes; a subject-predicate-object-context index and a predicate-object-subject-context index.

Of course, creating multiple indexes speeds up querying, but there is a cost factor to take into account as well: adding and removing data will become more expensive, because each index will have to be updated. Also, each index takes up additional disk space.

The native store automatically creates/drops indexes upon (re)initialization, so the parameter can be adjusted and upon the first refresh of the configuration the native store will change its indexing strategy, without loss of data.