Insert vectors over HTTP
How the POST /v1/insert endpoint works: the chunk shape, how SQLite row ids become USearch keys, and when the index is written to disk.
POST /v1/insert is how data gets into memista. This guide covers the chunk
shape and what happens under the hood.
The request
curl -X POST http://localhost:8083/v1/insert \
-H "Content-Type: application/json" \
-d '{
"database_id": "my_app",
"chunks": [{
"embedding": [0.1, 0.2],
"text": "Hello world",
"metadata": "{\"source\": \"readme\"}"
}]
}'
Each chunk carries three things:
embedding— the vector. In the stock crate this is length 2; see changing embedding dimensions.text— the content the vector represents.metadata— a string (commonly JSON) stored verbatim and returned on search.
What happens on insert
- The row (text + metadata) is written to the SQLite table
chunks_<database_id>first. - The returned
chunk_idbecomes the USearch key for the vector. - After the batch, the
<database_id>.usearchindex file is saved to disk.
Because the SQLite id and the USearch key are the same integer, search can
return ranked keys and hydrate the text/metadata straight back from SQLite. See
how it works for the full picture, then
run a search.
Frequently Asked Questions
What goes into a chunk?
An embedding (a vector of f32), the text it represents, and a metadata string (typically JSON you store and get back verbatim).
When is the index saved to disk?
The