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.

Current Profiles¶

The current system uses deployment-target names:

Defaults: grafeo facade and bindings use embedded. WASM uses browser. CLI uses gql + storage.

Proposed Profiles¶

The proposed system replaces deployment-target names with persona-driven names that describe what you're building, not where it runs.

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, composable with constraints. Users can add atoms like algos if they accept the size increase.

Examples:

# AI memory developer
grafeo = { features = ["lpg", "ai"] }

# Semantic data scientist
grafeo = { features = ["rdf", "analytics"] }

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

# Browser app
grafeo = { features = ["edge"] }

# Power user: just Cypher + vector search
grafeo = { features = ["cypher", "vector-index", "wal"] }

Profile Definitions¶

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 = ["sparql", "graphql", "triple-store", "ring-index", "storage", "regex"]

Full RDF triple store with SPARQL, space-efficient indexing, and persistence. For knowledge engineers working with ontologies and linked data. The triple-store atom enables the storage layer, and ring-index adds compact indexing (which pulls in succinct-indexes automatically).

Note: owl-schema and rdfs-schema currently only exist in grafeo-server. Promoting them to the engine level for this profile is an open question.

Analytics¶

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

27 graph algorithms (PageRank, Louvain, SSSP, Dijkstra, BFS/DFS, centrality, community detection, MST, flow, isomorphism, structural analysis, clustering), search indexes, and data import. Combine with LPG or RDF depending on the dataset.

AI¶

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

Structured memory for LLMs, agents, and RAG pipelines. Temporal history tracks how the graph evolves, CDC enables change feeds, and search indexes support vector/text retrieval.

Note: embed (ONNX embedding generation, ~17 MB) is deliberately excluded from this profile. Most AI memory use cases (grafeo-memory, MCP, LangChain) bring embeddings via API calls. Opt in explicitly with features = ["ai", "embed"] if you need in-process embedding.

This would redefine the current ai group. In 0.5.39, ai = ["vector-index", "text-index", "hybrid-search", "cdc"] at the engine level (without temporal). The proposed definition adds temporal and removes cdc's implicit inclusion (it becomes explicit). This change has not been made yet.

Edge¶

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

Minimal profile for browser, mobile, and resource-constrained environments. Compact store for pre-built read-only datasets, lightweight regex, smallest possible binary (~500 KB gzipped for WASM).

Enterprise¶

enterprise = ["auth", "tls", "metrics", "tracing", "sync", "replication", "push-changefeed"]

Production operations: authentication, encryption in transit, observability, and data replication.

Important: This profile only applies to grafeo-server. Auth, TLS, sync, replication, and push-changefeed are defined exclusively in the grafeo-server workspace. metrics and tracing are available as individual atoms in the engine, but the enterprise umbrella is server-scoped. On grafeo-server, this additionally enables all transport layers (HTTP, GWP, Bolt, Studio).

Migration from Current Profiles¶

Deprecation path:

1. Add new profile names as aliases alongside old names
2. Emit cfg deprecation warnings for old names
3. Update all binding defaults to use new names
4. Remove old names after one major version

Default feature question: What should grafeo = { version = "..." } give you? Currently it maps to embedded. Under the new system, the default needs to be decided (likely lpg).

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¶

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 complete list of individual feature flags (Layer 2) that profiles are composed from. Status indicates whether the atom exists in the codebase today.

Query Languages¶

Storage¶

Graph Model¶

Search and AI¶

Temporal and Change Tracking¶

Import¶

Execution¶

Note: Block-STM parallel transaction execution is compiled unconditionally (see grafeo-engine/src/transaction/parallel.rs). It is not gated behind a feature flag.

Operations (grafeo-server only)¶

Transports (grafeo-server only)¶

Regex¶