A graph database written in rust.

IndraDB consists of a server and an underlying library. Most users would use the server, which is available via releases as pre-compiled binaries. But if you're a rust developer that wants to embed a graph database directly in your application, you can use the library.

IndraDB's original design is heavily inspired by TAO, facebook's graph datastore. In particular, IndraDB emphasizes simplicity of implementation and query semantics, and is similarly designed with the assumption that it may be representing a graph large enough that full graph processing is not possible. IndraDB departs from TAO (and most graph databases) in its support for properties.

For more details, see the homepage. See also a complete demo of IndraDB for browsing the wikipedia article link graph.

• Support for directed and typed graphs.
• Support for queries with multiple hops.
• Cross-language support via gRPC, or direct embedding as a library.
• Support for JSON-based properties tied to vertices and edges.
• Pluggable underlying datastores, with several built-in datastores. Postgresql is available separately.
• Written in rust! High performance, no GC pauses, and a higher degree of safety.

We offer pre-compiled releases for linux and macOS.

• Download the latest release for your platform.
• Add the binaries to your PATH.
• Start the server: indradb-server

This should start the default datastore.

To build and install from source:

• Install rust. IndraDB should work with any of the rust variants (stable, nightly, beta.)
• Make sure you have gcc 5+ installed.
• Clone the repo: git clone [email protected]:indradb/indradb.git.
• Build/install it: cargo install.

If you want to run IndraDB in docker, follow the below instructions.

Build the image for the server:

DOCKER_BUILDKIT=1 docker build --target server -t indradb-server .

Run the server:

docker run --network host --rm indradb-server -a 0.0.0.0:27615

Build the image for the client:

DOCKER_BUILDKIT=1 docker build --target client -t indradb-client .

Run the client:

docker run --network host --rm indradb-client grpc://localhost:27615 ping

IndraDB offers several different datastores with trade-offs in durability, transaction capabilities, and performance.

By default, IndraDB starts a datastore that stores all values in-memory. This is the fastest implementation, but there's no support for graphs larger than what can fit in-memory, and data is only persisted to disk when explicitly requested.

If you want to use the standard datastore without support for persistence, don't pass a subcommand; e.g.:

indradb-server [options]

If you want to use the standard datastore but persist to disk:

indradb-server memory --persist-path=[/path/to/memory/image.bincode]

You'll need to explicitly call Sync() when you want to save the graph.

If you want to use the rocksdb-backed datastore, use the rocksdb subcommand; e.g.:

indradb-server rocksdb [/path/to/rocksdb.rdb] [options]

If you want to a datastore based on sled, use the sled subcommand; e.g.:

indradb-server sled [path/to/sled] [options]

If the sled directory does not exist, it will be created.

NOTE: The sled datastore is not production-ready yet. sled itself is pre-1.0, and makes no guarantees about on-disk format stability. Upgrading IndraDB may require you to manually migrate the sled datastore. Additionally, there is a standing issue that prevents the sled datastore from having the same level of safety as the RocksDB datastore.

It's possible to develop other datastores implementations in separate crates, since the IndraDB exposes the necessary traits to implement. For an example of this, see the postgres datastore.

NOTE: The postgres datastore only works on older (pre-1.0) versions of IndraDB.

Use make test to run the test suite. Note that this will run the full test suite across the entire workspace, including tests for all datastore implementations. You can filter which tests run via the TEST_NAME environment variable. e.g. TEST_NAME=create_vertex make test will run tests with create_vertex in the name across all datastore implementations. All unit tests will run in CI.

Microbenchmarks can be run via make bench.

A fuzzer is available, ensuring the the RocksDB and in-memory datastores operate identically. Run it via make fuzz.

Lint and formatting checks can be run via make check. Equivalent checks will be run in CI.