Developers
Vector search,
built in
A separate vector database is a second copy of your data with its own permissions model and its own staleness. Keeping the vectors beside the graph removes both problems.
Capabilities
Everything needed for semantic retrieval
Integrated rather than adjacent, which is the difference between one system and two.
Model of your choice
Hosted or local embedding models, swappable without rebuilding everything around them.
No second datastore
Vectors live with the graph, so there is no sync job and no second set of permissions.
Chunking that respects structure
Documents split on their actual structure rather than on a fixed token count.
Fused retrieval
Vector results combined with keyword and traversal in a single ranked set.
Permission-aware
Semantic search obeys the same record-level access as everything else.
Re-embedding handled
Changing model does not mean writing a migration script.
Questions for developers
The things worth asking first
Which embedding models are supported?
Studio ships Harrier, Arctic XS and MiniLM, which run in process with no network. You can also call OpenAI, Azure OpenAI, Anthropic, Cohere, Google or any OpenAI compatible endpoint, or store vectors you compute yourself.
Can I run vector search alone?
Yes. From code you can query the vector index directly, by text or by vector. In search, vector hits are added to keyword results or rerank them, each above a similarity cutoff you set, so exact part numbers still match.
What happens when I change model?
A model is fixed per embedding index, so you create a new index with the new model and it embeds the field from the start. The graph, its nodes and your code are not touched.
Your data. Your infrastructure.