Python SDK
brinicle provides two Python packages:brinicle— The core library with in-process C++ engine (installed viapip install brinicle)brinicle-client— HTTP client for the brinicle server (installed viapip install brinicle-client)
Core Library
The core library provides direct in-process access to the vector engine without needing a separate server.Installation
Usage
HTTP Client
The HTTP client communicates with a brinicle server instance and supports both synchronous and asynchronous operations.Installation
Synchronous Client
Asynchronous Client
API Reference
Both sync and async clients provide the same methods:Vector Engine Methods
| Method | Description |
|---|---|
health_check() | Check server status |
list_indexes() | List all indexes |
create_index(index_name, dim, delta_ratio, params) | Create a new index |
delete_index(index_name, destroy) | Delete or close an index |
get_index_status(index_name) | Get index status |
load_index(index_name) | Load existing index from disk |
init(index_name, mode) | Initialize ingest session |
ingest(index_name, external_id, vector) | Ingest a single vector |
ingest_batch(index_name, ids, vectors, dim) | Batch ingest (binary) |
finalize(index_name, optimize, params) | Finalize ingest session |
delete_items(index_name, external_ids, return_not_found) | Delete items |
rebuild(index_name, params) | Rebuild index compact |
search(index_name, query_vector, k, efs) | Search for nearest neighbors |
optimize(index_name) | Optimize HNSW graph |
ItemSearch Methods
| Method | Description |
|---|---|
create_item_index(index_name, dim, delta_ratio, params, lexical_config) | Create an item search index |
init_item_ingest(index_name, mode) | Initialize item ingest session |
ingest_item(index_name, external_id, vector, fields) | Ingest a single item with metadata |
search_items(index_name, query, filters, k, efs) | Search items with text query and filters |
delete_item_index(index_name, destroy) | Delete or close an item index |
get_item_index_status(index_name) | Get item index status |
Autocomplete Methods
| Method | Description |
|---|---|
create_autocomplete_index(index_name, dim, delta_ratio, params, autocomplete_config) | Create an autocomplete index |
init_autocomplete_ingest(index_name, mode) | Initialize autocomplete ingest session |
ingest_autocomplete(index_name, key, vector) | Ingest a single autocomplete entry |
search_autocomplete(index_name, query, k) | Search for autocomplete suggestions |
delete_autocomplete_index(index_name, destroy) | Delete or close an autocomplete index |
get_autocomplete_index_status(index_name) | Get autocomplete index status |
ItemSearch (HTTP Client)
The HTTP client provides ItemSearch methods that communicate with the brinicle server’s ItemSearch API. ItemSearch enables structured search over items with lexical fields, combining vector similarity with metadata filtering. This is ideal for product catalogs, document collections, and any dataset where you need to search by both content and structured attributes. Unlike the basic vector search which operates on raw embeddings, ItemSearch lets you ingest items with human-readable fields such as titles, descriptions, and categories, then perform filtered searches that combine full-text matching with vector similarity. Each item index is backed by its own vector index, so you still benefit from brinicle’s high-performance HNSW graph for similarity lookups. The difference is that ItemSearch adds a lexical configuration layer that controls how text fields are tokenized and matched, allowing you to fine-tune relevance for your specific domain.Creating an Item Index
Usecreate_item_index to create a new item search index with an optional lexical configuration. The lexical_config parameter controls how text fields are analyzed during ingestion and search — you can specify which fields are searchable, how they are tokenized, and whether stemming or stop-word removal should be applied. If omitted, a default configuration is used that treats all text fields as searchable with standard tokenization.
Ingesting Items
Initialize an item ingest session withinit_item_ingest, then ingest items with their vectors and metadata fields using ingest_item. Each item consists of an external ID, a vector matching the index dimension, and a dictionary of string fields. Fields listed in the searchable_fields of your lexical_config will be indexed for full-text search, while other fields are stored but not searchable. After all items are ingested, call finalize to build the index.
Searching Items
Search for items using a text query with optional structured filters viasearch_items. The query parameter provides the text query which is matched against the searchable fields defined in the lexical configuration. The filters parameter accepts structured conditions with must and must_not keys that narrow results by exact field values or ranges. You can control the number of results with k and the search beam width with efs for fine-grained recall/latency trade-offs.
Managing Item Indexes
You can close or permanently destroy item indexes, and check their status at any time. Closing an index preserves its data on disk for later reloading, while destroying it permanently removes all data. The status check returns the index name, dimension, and whether a rebuild is needed after recent ingestions.Autocomplete (HTTP Client)
The HTTP client provides Autocomplete methods that communicate with the brinicle server’s Autocomplete API. Autocomplete indexes are optimized for fast prefix matching, making them ideal for search boxes, tag suggestion, and any interface where users type partial queries and expect instant results. Unlike ItemSearch which combines vector similarity with text matching, Autocomplete focuses on sub-millisecond prefix lookups over string keys. Each autocomplete index stores a set of string keys and their associated vectors. When a user types a partial query, the engine searches for keys that begin with the typed prefix and returns the closest matches ranked by vector similarity. This allows you to build autocomplete experiences that are both fast and semantically relevant — for example, typing “iph” could suggest “iPhone 15 Pro Max” based on both the prefix match and the semantic proximity to other electronics products.Creating an Autocomplete Index
Usecreate_autocomplete_index to create a new autocomplete index with an optional autocomplete configuration. The autocomplete_config parameter controls how suggestions are matched and ranked — for example, you can set the minimum prefix length before suggestions are returned, the maximum number of suggestions, and whether to apply fuzzy matching for typo tolerance. If omitted, sensible defaults are used that work well for most use cases.
Ingesting Autocomplete Entries
Initialize an autocomplete ingest session withinit_autocomplete_ingest, then ingest entries using ingest_autocomplete. Each entry consists of a key string and its associated vector. The key is the text that users will search for by prefix — for example, a product name. The vector provides the semantic representation used to rank suggestions when multiple prefix matches are found. After all entries are ingested, call finalize to commit the data and build the prefix index.
Searching Autocomplete Suggestions
Search for autocomplete suggestions by providing a partial query string viasearch_autocomplete. Results are ranked by a combination of prefix match quality and vector similarity, ensuring that the most relevant suggestions appear first. The method is designed for sub-millisecond response times, making it suitable for interactive type-ahead interfaces.
Managing Autocomplete Indexes
Manage autocomplete indexes by closing or destroying them, and checking their status. The status check returns the index name, dimension, whether the prefix index is built, and whether a rebuild is needed. This is particularly important for autocomplete indexes because the prefix index must be rebuilt after ingestion to reflect new entries.Error Handling
Choosing Between Core and Client
| Aspect | Core Library (brinicle) | HTTP Client (brinicle-client) |
|---|---|---|
| Architecture | In-process | Client-server |
| Latency | Lowest (no network) | Network overhead |
| Deployment | Embedded in your app | Separate server process |
| Language | Python only | Any language (via HTTP) |
| Concurrency | GIL-limited | Server handles concurrency |
| Use case | Single-app, low-latency | Multi-service, microservices |