A graph database built for data that matters.
Temporal, verifiable, standards-compliant. RDF triples with complete history, integrated search, and fine-grained access control — in a single binary.
Install in 60 seconds Try Fluree AI: Serverless
Why Core Exists
Most databases store records. Fluree Core stores knowledge.
Traditional databases store records for one system at a time. Fluree Core stores meaning — relationships between entities, the history of every change, and the policies that govern who sees what.
It is the knowledge foundation your entire organization reasons over.
What Makes Core Different
Ten things most graph databases can’t do.
- Every transaction signed. Nothing silently altered. Every transaction is cryptographically signed and appended to an immutable ledger. Data can never be silently altered or deleted, and the full temporal history of every record remains queryable — forever.
- Policies live with the data. Access control is enforced inside the query engine, not inside application code. Attribute-based, role-based, and relationship-based policies are evaluated at query time — at the granularity of an individual triple.
- Every record knows where it came from. Every record carries proof of who created it, when, and every change since. Signatures, verifiable credentials, and lineage are first-class parts of the model — not bolt-on metadata.
- Keyword and vector search, inside the engine. Full-text ranking (BM25 with Block-Max WAND) and vector similarity (HNSW) live inside the query engine — not as external services. Search results participate in joins, filters, and aggregations like any other graph pattern.
- Infer what nobody thought to record. The engine materialises facts implied by your ontology at query time. RDFS subclass reasoning, OWL 2 RL forward-chaining, and user-defined Datalog rules derive transitive and inverse relationships automatically — so implicit structure becomes first-class.
- Built on W3C standards, all the way down. The data model remains portable, inspectable, and vendor-neutral — because it’s an open one. JSON-LD, RDF, SPARQL, OWL, and SHACL are the lingua franca of Fluree, and of every tool in the semantic ecosystem.
- Query the graph at any moment in its history. Query by transaction number, ISO-8601 timestamp, or content-addressed commit hash. Reconstruct historical state exactly as it existed when a decision was made — for audit defense, point-in-time reporting, or debugging what changed.
- Fork, rebase, merge — for data. Every branch is an independent content-addressed history. Fork production to run a schema migration or an ML experiment in isolation; diff against main; merge when ready. The same workflow developers use for code, applied to the data itself.
- One query across every source you already have. Query Iceberg, Parquet, relational databases (via R2RML), and remote SPARQL endpoints as if they were one graph — without copying data into a new silo. Fluree brings the query to the data.
- Binary, server, or library — same engine. Run Fluree as a single binary from the CLI, stand it up as a production HTTP server, or embed it as a Rust library directly inside your application — no server process, no network hop. The same engine, three surfaces.
Benchmarks
The fastest SPARQL engine on the benchmark.
SPARQLoscope is a neutral academic benchmark from ad-freiburg. 105 queries across DBLP, measuring read-write performance on commodity hardware. Fluree was the only engine to complete every query — and the fastest overall.
Geometric mean
0.28s
1.7× faster than Virtuoso. 138× faster than Oxigraph.
Successful queries
105/105
Zero failed queries. The only engine in the benchmark to finish them all.
Bulk import
2M+/s - Triples per second on a single node. Billions of triples on commodity hardware.
Head-to-head
| Capability | Neo4j · Neptune · others Typical graph DBs |
Fluree Core |
|---|---|---|
| Data model | Property graph or proprietary | Open RDF / JSON-LD, W3C-native |
| Immutability | Not built in | Native ledger — every tx signed |
| Time travel | Backups or snapshots only | Query any state by tx, time, or commit |
| Access control | Application layer or IAM | Triple-level, enforced at query time |
| Built-in search | Plugin or external service | BM25 + HNSW in the engine |
| Reasoning | External or limited | RDFS, OWL 2 RL, Datalog rules |
| Branching | Not supported | Fork, rebase, merge — like git |
| Federated queries | Not built in | Iceberg, R2RML, remote SPARQL |
| Standards compliance | Cypher or proprietary model | Full SPARQL 1.1, JSON-LD, OWL, SHACL |
| Deployment | Cloud-locked or on-prem only | Single binary — any cloud, embedded |
| Open source | Partial or closed | Yes — labs.flur.ee |
For Developers
Zero to graph
Install. Query. Ship.
Single binary. No JVM, no Python env, no Zookeeper. Pick a package manager and you’re querying a knowledge graph in under a minute — SPARQL or JSON-LD, same engine.
# 1 — install the single binary
brew install fluree/tap/fluree
# 2 — create a ledger
fluree create movies
# 3 — insert a few triples
fluree insert '@prefix ex: <http://example.org/> .
@prefix schema: <http://schema.org/> .
ex:blade-runner a schema:Movie ;
schema:name "Blade Runner" .
ex:alien a schema:Movie ;
schema:name "Alien" .'
# 4 — query
fluree query 'PREFIX schema: <http://schema.org/>
SELECT ?title
WHERE { ?m a schema:Movie ; schema:name ?title }'
Run it your way
One engine. Three surfaces.
Script from the terminal. Stand up a production API. Or embed Fluree as a Rust library directly inside your application — a surface nobody else in the graph space offers.
Deploy Anywhere
On-prem. Your cloud. Or ours.
Fluree fits the deployment model your security team already approved. Full data sovereignty, major-cloud native, or fully managed — same engine, same guarantees.