Skip to main content

StorageConfig

StorageConfig defines the backing store for an index and all of its per-index keystores. It is immutable and has no public default constructor — instances are created via the static factory methods below. A single StorageConfig is shared across the client and all indexes it manages. CyborgDB supports three backing stores: in-memory (ephemeral), local disk (RocksDB-backed), and S3 (or any S3-compatible store such as MinIO).

Static Factories

Example Usage

For more info, you can read about supported backing stores here.

CachePolicy

CachePolicy controls which categories of data a disk-backed store keeps cached in memory for faster access.

S3Options

S3Options configures an S3 backing store created via StorageConfig::S3.
Path-style addressing is selected automatically when endpoint is set (MinIO/Ceph/R2); otherwise virtual-hosted addressing is used.

S3Credentials

S3Credentials holds explicit credentials for an S3 backing store.

GPUConfig

GPUConfig is an enum that specifies which operations should use GPU acceleration. It uses bitflags that can be combined using the | (OR) operator.

Enum Values

Example Usage


DeviceConfig

DeviceConfig class holds the configuration details for the device used in vector search operations, such as the number of CPU threads and GPU acceleration settings.

Constructor

Parameters

Methods

Example Usage


DistanceMetric

The DistanceMetric enum contains the supported distance metrics for CyborgDB. These are:

IndexDiskIVF

IndexDiskIVF configures a DiskIVF index — the single index type supported in CyborgDB. It replaces the older IndexConfig family. Pass an instance to CreateIndex when you want explicit control over dimensionality or storage precision; otherwise the default-config overload of CreateIndex constructs one for you.

Constructor

Parameters

Methods

Example Usage


StoragePrecision

StoragePrecision controls the on-disk dtype of rerank vectors for a DiskIVF index.

TrainingState

TrainingState reports the lifecycle state of an index’s training.
While an index is in the Training state, queries transparently fall back to the untrained (exhaustive) path.

IndexType

The IndexType enum defines the supported index types in CyborgDB. CyborgDB now supports a single index type, DiskIVF:

Array2D

Array2D class provides a 2D container for data, which can be initialized with a specific number of rows and columns, or from an existing vector.

Constructors

  • Array2D(size_t rows, size_t cols, const T& initial_value = T()): Creates a 2D array with specified dimensions, initialized with the given value.
  • Array2D(std::vector<T>&& data, size_t cols): Initializes the 2D array from a 1D vector (move semantics).
  • Array2D(const std::vector<T>& data, size_t cols): Initializes the 2D array from a 1D vector (copy).
  • Array2D(std::initializer_list<std::initializer_list<T>> init_list): Initializes from a nested initializer list (e.g., {{1, 2}, {3, 4}}).
  • Array2D(Array2D&& other) noexcept: Move constructor - transfers ownership without copying.
  • Array2D(): Default constructor - creates an empty array (0 rows, 0 columns).
The copy constructor is deleted. Use Clone() or move semantics to copy an Array2D.

Access Methods

  • operator()(size_t row, size_t col) const: Access an element at the specified row and column (read-only).
  • operator()(size_t row, size_t col): Access an element at the specified row and column (read-write).
  • size_t rows() const: Returns the number of rows.
  • size_t cols() const: Returns the number of columns.
  • size_t size() const: Returns the total number of elements.

Example Usage


TrainingConfig

The TrainingConfig struct defines parameters for training an index, allowing control over convergence and memory usage.

Constructor

Parameters

Struct Members

Note: The struct members are stored in this order (different from constructor parameter order):

QueryParams

The QueryParams struct defines parameters for querying the index, controlling the number of results, probing behavior, and reranking.

Constructor

Parameters

Higher n_probes values may improve recall but could slow down query time, so select a value based on desired recall and performance trade-offs.
filters use a subset of the MongoDB Query and Projection Operators. For instance: filters: { "$and": [ { "label": "cat" }, { "confidence": { "$gte": 0.9 } } ] } means that only vectors where label == "cat" and confidence >= 0.9 will be considered for encrypted vector search. For more info on metadata, see Metadata Filtering.

QueryResults

QueryResults class holds the results from a Query operation, including IDs, distances, and metadata for the nearest neighbors of each query. Results are vector-based and immutable after construction.

Getter Methods

Methods

ResultView

The ResultView struct provides read-only access to results for a single query:

Example Usage


ItemID

ItemID is a type alias for unique identifiers used throughout CyborgDB.
ItemID is used to uniquely identify vectors and items within an encrypted index. Currently implemented as std::string for flexibility and human-readable identifiers.

Item

Item struct holds the individual results from a Get operation, including the requested fields.

ResultFields

ResultFields enum specifies which fields to include in query results.

ItemFields

ItemFields enum defines the fields that can be requested for an Item object.
By default, ids are always included in the returned items.

KeyContext

KeyContext carries the key material for a data operation. It holds the 32-byte index KEK and, for RBAC deployments, a 16-byte user identifier. A bare 32-byte index key (the index_key) implicitly converts to a KeyContext, so most callers pass the key directly; RBAC users construct one explicitly with their own user_kek and user_id.
Operations that require the root index KEK (such as DeleteIndex and user management) reject a per-user KeyContext. See Managing Users for RBAC details.

KMSBlob

KMSBlob describes how an index’s Key-Encryption-Key (KEK) is wrapped by an external KMS. It is persisted per index via the module-level KMS functions (see the KMS reference). This is primarily for service-layer deployments; embedded SDK users supplying their own KEK can ignore it.