Feature Profiles¶

Motivation¶

Grafeo aims to be a universal graph database: property graphs, RDF, analytics, AI memory, browser, production server. But no single user needs all of that. Feature profiles let every user get exactly what they need, with zero overhead from what they don't.

There are two layers:

• Layer 1: Profiles, named groups consistent across the entire ecosystem. This is what most users interact with.
• Layer 2: Atoms, individual feature flags for power users who want precise control. Profiles are composed from these.

Profiles¶

Since 0.5.35, profiles are named after what you are building, not where it runs. They are defined in the grafeo facade crate and the binding crates.

Composition Rules¶

• Model profiles (lpg, rdf): pick one or both. These are the foundation.
• Capability profiles (analytics, ai, enterprise): stack on top of a model profile.
• Constrained profile (edge): minimal by default. Add atoms such as algos if you accept the size increase.

Examples:

# AI memory developer
grafeo = { version = "0.6", default-features = false, features = ["lpg", "ai"] }

# Semantic data scientist
grafeo = { version = "0.6", default-features = false, features = ["rdf", "analytics"] }

# Browser app
grafeo = { version = "0.6", default-features = false, features = ["edge"] }

# Power user: just Cypher and vector search with persistence
grafeo = { version = "0.6", default-features = false, features = ["cypher", "vector-index", "wal"] }

# Full production stack (grafeo-server)
# grafeo-server = { features = ["lpg", "rdf", "ai", "enterprise"] }

Profile Definitions¶

As defined in the grafeo facade crate:

LPG¶

lpg = ["gql", "cypher", "gremlin", "sql-pgq", "storage", "regex"]

All labeled property graph query languages plus persistence. The default choice for application developers working with nodes, edges, labels and properties.

RDF¶

rdf = ["triple-store", "gql", "sparql", "graphql", "storage", "regex", "shacl"]

RDF triple store with SPARQL, GraphQL, SHACL validation and persistence, for knowledge engineers working with ontologies and linked data. Every build has the LPG store, which sessions, persistence and recovery need (#544: a build with the triple store but without it lost its triples on reopen). Add the ring-index atom for compact RDF indexing (it pulls in succinct-indexes).

Note: in the lower-level crates (grafeo-core, grafeo-adapters, grafeo-engine), rdf is a deprecated alias for the triple-store atom only. The profile above applies to the facade and binding crates.

Analytics¶

analytics = ["algos", "vector-index", "text-index", "hybrid-search", "jsonl-import", "parquet-import"]

25+ graph algorithms (PageRank, Louvain, SSSP, Dijkstra, BFS/DFS, centrality, community detection, MST, flow, isomorphism, clustering), search indexes and bulk import. Combine with lpg or rdf depending on the dataset.

AI¶

ai = ["vector-index", "text-index", "hybrid-search", "cdc"]

Structured memory for LLMs, agents and RAG pipelines: vector and text retrieval plus change feeds. Point-in-time queries need no feature: a database keeps its history for the retention window it is configured with (Config::with_history_retention).

Note: embed (in-process ONNX embedding generation, about 17 MB) is deliberately not part of this profile. Most AI memory use cases bring embeddings through an API. Opt in explicitly with features = ["ai", "embed"].

Edge¶

edge = ["gql", "regex-lite"]

Minimal profile for browsers, mobile and other constrained environments, with the smallest possible binary.

Enterprise¶

enterprise = ["metrics", "tracing", "async-storage"]

Production operations. In the engine this enables observability and the async storage calls (async-storage, deprecated since 0.6.1 and removed in 0.7.0: from 0.7.0 enterprise is metrics and tracing, and async callers run wal_checkpoint() with tokio::task::spawn_blocking). On grafeo-server, enterprise additionally enables authentication, TLS, sync, replication, the push changefeed and all transports (HTTP, GWP, Bolt, Studio), which exist only in the server workspace.

Deprecated Profile Names¶

The binding defaults move to persona names before the aliases are removed, so depending on grafeo without features keeps working.

Ecosystem Matrix¶

The profile names are consistent across every project. The table below shows which profiles are available in each project, either as configurable feature flags or as the project's inherent profile alignment.

Core Engine¶

Language Bindings¶

The bindings use the same profile names, with a few differences from the facade:

• C (and C#, Dart, Go): rdf has no SHACL validation.
• WASM: lpg and rdf have no storage, rdf has no SHACL and uses the lightweight regex engine, ai has no change data capture, and analytics is ai plus algos (no bulk import).

AI / Agent Ecosystem¶

Web / Visualization¶

Protocol Libraries¶

Accelerators and Tooling¶

Legend¶

• flag: Profile is available as a configurable feature flag. User opts in.
• inherent: The project is inherently aligned with this profile. No flag needed.
• via C: Feature selection happens at C binding compile time, propagates to higher-level bindings.
• n/a: Profile does not apply to this project.
• -: Not applicable or not supported.

Atom Reference¶

The individual feature flags (Layer 2) that profiles are composed from. "(standalone)" means the atom is not part of any persona profile and is enabled on its own; some of those are part of the deprecated embedded default, as noted.

Query Languages¶

Storage¶

Graph Model¶

Search and AI¶

Temporal and Change Tracking¶

Import and Export¶

Execution¶

Operations¶

Transports (grafeo-server only)¶

Regex¶