Smarter agents. One database.

HelixDB is an open-source graph database with native vector and full-text (BM25) search, built in Rust on object storage. Your data is one labeled property graph, and vector, text, and secondary indexes are access paths over properties on its nodes and edges. There is no separate graph store, vector store, or search cluster to keep in sync, and relationships are searchable as well as entities.

Store memories as nodes with indexed properties for tenant and lifecycle fields, such as isLatest or expiresAt, and use edges for provenance, entities, and version history. To recall, traverse to the memories an agent is allowed to see, then run vector and BM25 search inside that set, all in one transaction.

Yes, through prefiltered search. A graph traversal, such as the documents a user can access, or an indexed tenant property defines the exact candidate set, and vector or BM25 ranking runs only inside it in the same request. Nothing outside that set is returned. Your queries enforce the scope, and vector and text indexes can be partitioned per tenant.

No. Your application computes embeddings and, if it runs both searches, combines the vector and BM25 results. HelixDB stores the vectors, runs approximate vector search and BM25 search, and can scope both to a graph traversal in the same request.

There are official SDKs for Rust, TypeScript, Python, and Go. There is no text query language: you build queries with typed SDK builders, or write the JSON directly, and send them inline to POST /v2/query with no compile or deploy step. The earlier HelixQL (HQL) language is archived.

Yes. Embed the engine in a Rust, TypeScript, or Python process, or run the local server as a single node in Docker or Podman on memory, disk, or S3-compatible storage. Helix Cloud is the managed, highly available option. Every mode runs the same queries through the same SDKs. The Go SDK connects over HTTP only, and bring-your-own-cloud (BYOC) is coming soon.

Yes. The HelixDB skills teach coding agents the CLI, SDKs, and query patterns, and helix chef installs them along with the docs MCP, and helix init offers to. At runtime, agents can query Helix Cloud through one MCP endpoint, mcp.helix-db.com/mcp, where every write and admin change needs a confirmation step. Agents that register through that endpoint get a one-month sandbox database. Database MCP is available on Helix Cloud only.

Each request runs as one ACID transaction with serializable snapshot isolation, and graph, vector, and text lookups share that snapshot. A write batch commits or rolls back as a whole, and conflicting writes fail at commit. On Helix Cloud, reads served by readers can briefly lag the writer; send a writer-only request when you need read-after-write.

Yes. The helix-db repository is licensed under Apache 2.0, and self-hosting or embedding it is free. Helix Cloud plans start at $5/month for 200K reads and 100K writes, with unlimited storage and opt-in overage. On the Growth plan, you can run a dedicated cluster billed by the hour.

Direct requests to the gateway need a read-only or read-write API key, and rotating or revoking a key takes effect immediately. MCP and CLI access use WorkOS sign-in or scoped service credentials instead. Traffic is encrypted with TLS, and data at rest uses the object-storage provider's server-side encryption. SSO/SAML, role-based access, audit logs, and AWS PrivateLink are on the roadmap.