Skip to main content
Use this page when a term in a guide or API response is unfamiliar.

​
Scope

​
Database

A separate workspace for data, typically one per customer or environment. A query searches only the database you specify.

​
Collection

A named group of content within a database, typically one per end-user, team, or agent. Omit it and HydraDB uses the database’s default collection, which is created on the first write. A query that names another collection does not read the default one. See Multi-tenancy for how scoping affects writes and reads.

​
Multi-tenancy

Serving several customers or users while keeping their data separate. Use databases for separate customer workspaces and collections to organize data within them. Your application chooses which each caller may access.

​
ACL and principal

An access-control list (ACL) names who may retrieve a document. Each entry is a principal: a user, group, or domain represented by a string. Queries must send the caller’s principals to enforce document permissions. See Access Control.

​
Content

​
Knowledge

Shared context your agents work from: documents, files, and content from apps. See Knowledge.

​
Memory

Information to remember between conversations: a preference, past exchange, or saved fact. Your application chooses which user collection to store it in. See Memories.

​
Source

One ingested item: a file, an app record, or a memory. Each source has an id you use to check status, inspect, update, or delete it.

​
App source

A record your app or connector already parsed, such as a Slack message or a Jira ticket, sent with typed fields instead of as a file. See App Sources.

​
Chunk

A passage of a source, sized for retrieval. Queries return ranked chunks, and you pass them to your model.

​
Infer

A memory flag. With infer: true, HydraDB extracts the preference or fact from raw input such as dialogue or event logs. With infer: false (the default), it stores exactly what you send.

​
Processing

​
Ingestion

Sending content to HydraDB, through the ingest endpoint or a connector.

​
Indexing

Processing content so it can be searched. It runs in the background after ingestion; check the source status before querying newly added content.

​
Entity

A named person, organization, service, or topic found in content. Entities are connected by relationships in the context graph.

​
Retrieval

​
Retrieval

Finding relevant passages and source details for a question. Your model uses these results to write an answer.

​
Semantic search and embeddings

Semantic search matches by meaning rather than exact words. An embedding is the numerical representation of text used to compare meanings.

​
BM25

The keyword-ranking method HydraDB uses to score text by its matching words.

​
RAG

Retrieval-augmented generation: search for relevant content, then include it in a model’s prompt so the answer can use that content.

​
Reranking

Reordering search candidates by their relevance to the question. The default query_by mode: matching by meaning and BM25 keyword matching, blended by alpha. query_by: "text" uses BM25 alone. See Semantic Search.

​
Fast, thinking, and auto

Query mode values. fast is one low-latency pass. thinking expands the query, reranks, and pulls in forceful relations. auto, the default, picks one per query.

​
Context graph

A record of the entities and relationships HydraDB extracts from content, returned with query results as graph_context. See Context Graphs.

​
Graph traversal and hops

Following relationships between entities or stored items. One hop is one connection; multi-hop traversal follows a chain of connections.

​
Triplet

One edge of the context graph: a source entity, a relation, and a target entity, such as “billing policy, governs, failed payment handling”.

​
Forceful relations

Links between sources that you declare at ingest with relations, for when two sources belong together but their text does not say so. Returned in additional_context in thinking mode.

​
Deprecated aliases

database and collection were previously called tenant_id and sub_tenant_id. Wherever you meet an old name (a request field, a route, a webhook payload), it is a deprecated alias, and it keeps working. A request that sends both names with different values is rejected with 400.
One exception: in the indexing webhook payload, tenant_id and database do NOT carry the same value. database is the name you ingested into; tenant_id is an identifier for it. Everywhere else (request fields, routes, query parameters), they remain interchangeable. See Webhooks.
Prefer the canonical names in new integrations. See Multi-tenancy for the full compatibility contract.