Storing Embeddings

Before you can search embeddings, you have to store them. In a vector database, storing an embedding means saving the vector together with an ID and metadata — as a single record — and letting the database index it for fast similarity search later. Getting this step right is what makes retrieval both accurate and quick.

💡 In one line: Storing an embedding means saving it as a record — ID + vector + metadata — that the database indexes for fast similarity search.

What Does "Storing" Mean?

Each embedding becomes a record in the database. The database keeps the vectors in a special index so that, later, a query can find the nearest ones quickly — without scanning every record.

Anatomy of a Stored Record

A record usually has three parts:

  • ID — a unique key, used to update, delete, or look up the record.
  • Vector — the embedding itself (a fixed-length list of numbers).
  • Metadata (payload) — extra fields: the original text, source, tags, timestamps — used for filtering and for returning content.

Upsert: Insert or Update

The core write operation is upsert — insert if the ID is new, update if it already exists. Writes are usually batched (many records at once) for efficiency.

The Ingestion Pipeline

Getting data in typically looks like this.

Whiteboard
Whiteboard diagram


Keep the Source Text in Metadata

A vector is not human-readable, so always store the original text (and its source) in the metadata. That's what you'll return to the user — or feed back to the LLM in a RAG system — after retrieval. The vector finds it; the metadata is what you actually use.

Dimension Consistency

Every vector in a collection must share the same dimension, produced by the same embedding model. Mixing models or dimensions breaks search — the vectors would live in incompatible spaces.

Storage & Efficiency

  • Size ≈ number of vectors × dimensions × bytes per number. (e.g. 1M vectors × 768 dims × 4 bytes ≈ 3 GB.)
  • float32 (4 bytes) is the default; quantization (int8, binary) shrinks storage with modest quality loss.
  • Batch your upserts for speed.
  • Normalise vectors if you'll search with cosine similarity.

Code Example


 
Best Practices
 
     
  • Chunk long documents before embedding.
    •  
  • Store the text and source in metadata.
    •  
  • Use stable, unique IDs.
    •  
  • Batch inserts; choose float32 or quantized based on scale.
    •  
 
Summary
 
     
  • Storing an embedding saves it as a record: ID + vector + metadata.
    •  
  • The core write is an upsert (insert or update), usually batched.
    •  
  • Always keep the original text in metadata — the vector isn't readable.
    •  
  • All vectors in a collection must share the same dimension and model.
    •  
  • Plan for storage size, and use quantization to save space at scale. EOF echo created