#Full-Text Search Built Into the Graph

Most graph databases hand text search off to a second system. You run Elasticsearch or OpenSearch alongside the database, ship every literal into it, and keep the two stores in sync forever. Search results live in one system, your relationships in another, and joining them is your problem.

WWKG indexes your text where your graph already lives — versioned, encrypted, branch-aware, and queryable in the same SPARQL, Cypher, or GQL statement as any graph traversal. No sidecar. No sync pipeline. No second copy of your data.

#What you could not do before

In a typical graph-plus-search-engine setup:

• You operate two systems. The graph database holds the relationships; a separate search cluster holds a second copy of every textual value. Each has its own scaling, backup, and failure modes.
• You maintain a sync pipeline. Every write has to be mirrored into the search index, and any lag means search and graph disagree about what the data says.
• The search index is not versioned. You cannot ask “what would this search have returned last Tuesday?” or try an experimental analyzer on a branch without touching production.
• The search index is plaintext. The literals you were careful to encrypt in the graph are sitting readable in the search cluster.
• Combining a text match with graph structure means middleware: query the search engine, take the ids, query the graph, stitch the results in application code.

The result: full-text search is a separate system bolted onto the graph, with its own copy of your data, its own security surface, and its own operational cost.

#What WWKG enables

One index, inside the graph. WWKG keeps an inverted full-text index as part of the same content-addressed, Merkle-DAG storage as everything else. There is no second database to run, scale, or secure — and no data leaves the node to be searched.

Maintained automatically. The index updates as part of every commit — whether the write is a bulk upload or a single INSERT. Language-aware analysis (normalization, tokenization, stop-words, optional stemming) runs identically at index time and query time, so a query token matches the form that was stored. Durable branches maintain the index by default; there is no pipeline to wire up.

A first-class query citizen. Full-text search is a function in the query engine, not an external call. wwkg:textSearch binds each matching subject and its relevance score; wwkg:textMatch is a scalar filter for natural use inside a pattern. The planner treats it as an index scan, so text relevance composes with graph traversal, filtering, and reasoning in a single SPARQL, Cypher, or GQL query.

Ranked by relevance. Matches come back scored (TF-IDF), ordered by descending relevance, and bindable as ?score — so you can sort, threshold, or combine the score with graph structure however you like.

Named-graph aware. The index records which named graph each match lives in. A result tells you the graph it was found in, a search can be scoped to a graph, and the same subject across different graphs is handled correctly — full-text search that understands the shape of your data.

Time-travel search. Because the index is versioned with the data, a query can search the graph as of any point in its history — the same ASOF time-travel that applies to the rest of your queries. Ask what a search would have returned at a past commit, for audit or comparison.

Versioned and branch-aware. Try a different analyzer or reindex on an experimental branch without affecting the main branch. Merge when you are satisfied. The search index branches with your data.

Encrypted like everything else. The index is protected by the same workspace key that protects the rest of your data — before storage and before leaving the node. The literals you encrypted in the graph are not sitting in plaintext in a separate search cluster.

In the terminal and in Studio. Run wwkg graph search "customer churn" from the CLI, or use the Studio search page — both give the same ranked, index-backed results, across a branch or every branch at once.

#A concrete scenario

A team maintains a knowledge graph of products, suppliers, contracts, and support cases. An analyst needs “contracts mentioning force majeure that belong to suppliers in a region flagged for disruption.”

In a traditional setup that is two systems and glue code: query the search cluster for the phrase, collect the contract ids, query the graph for the supplier-and-region traversal, and join the two result sets in the application — keeping the search index in sync with the graph the whole time.

In WWKG it is one query. wwkg:textSearch finds the contracts matching the phrase and ranks them by relevance; the same query walks from each contract to its supplier and region and filters by the disruption flag. One execution, ranked results, against the exact branch and point in time the analyst is working on — with no second store to keep in sync.

#What makes this different

Every other graph database treats full-text search as someone else’s job: stand up a search engine, copy the text into it, keep it in sync, and stitch the results back together yourself. The search index is a separate system with a separate copy of your data and a separate security model.

WWKG treats text as part of the graph. The index is versioned with your commits, encrypted with your keys, aware of your branches and named graphs, and queryable in the same statement as any traversal. It is not bolt-on search. It is search as a native property of the knowledge graph.

#Next steps

Related features: Three Query Languages, Vector Search for Graph Workloads, and Branching and Merge Workflows. See the Vocabulary section for the terms used across the WWKG product and docs.