Which embedding providers are supported?

Any OpenAI-compatible API. We ship presets for OpenAI, Anthropic, Groq, OpenRouter, Together, Venice, DeepSeek, and Ollama. The `USING ` clause picks one; `USING custom` lets you point at any compatible endpoint.

Both. `USING IVFFLAT` is recall-tunable and great for batch insert workloads; `USING HNSW` is faster on cold queries but more expensive to rebuild. Pick based on your write/read ratio.

Can I store the embedding myself instead of auto-embedding?

Yes. `WITH AUTO EMBED` is convenience; you can also write the `vec` column directly with a vector literal or via the binary protocol. Useful when your embedding pipeline already exists.

What about multimodal — images, audio?

Same shape: any embedding provider that returns a fixed-dimension vector works. The text-vs-image distinction lives in your provider config, not the engine.

How does this differ from running pgvector?

Mostly the auto-embed pipeline and the hybrid graph + vector search. pgvector gives you the index and the operators; you bring the embedding job, the keyword scorer, and the graph database for context expansion. RedDB ships those.

semantic

Vectors

Auto-embed on insert, similarity search, no vector DB to sync.

Try Vectors free See all 9 data models

What it is

Vectors on RedDB.

Vector indexes natively, with a write path that handles embedding on the way in. INSERT … WITH AUTO EMBED USING <provider> resolves text to a vector at ingest, against any OpenAI-compatible API.

Similarity search runs as SEARCH SIMILAR against the same wire protocol the rest of your app already uses. Metadata filters, hybrid full-text + vector queries, and IVF / HNSW indexing land in standard SQL surface.

Pairs with graphs — SEARCH SIMILAR … WITH CONTEXT DEPTH 2 returns nearest neighbours plus their relational neighbourhood for RAG.

Code

Write it. Read it. Same engine.

Insert

INSERT INTO notes (body) VALUES ('suspicious vpn login from new country') WITH AUTO EMBED (body) USING openai;

Query

SEARCH SIMILAR TEXT 'login anomaly' COLLECTION notes LIMIT 10;

Driver examples

Connect from your language.

Real driver code — copy-paste ready, no pseudocode.

TypeScript

import { Client } from '@reddb/client'

const db = new Client({ url: process.env.REDDB_URL })

// Auto-embed on insert — the engine calls the embedding provider
await db.query(
  `INSERT INTO articles (id, title, body)
   VALUES ($1, $2, $3)
   WITH AUTO EMBED (body) USING openai`,
  [1, 'RedDB vectors', 'Vector search and relational SQL in one engine.'],
)

// Similarity search — returns nearest neighbours by cosine distance
const { rows } = await db.query(
  `SEARCH SIMILAR TO $1 IN articles
   USING HNSW LIMIT 5`,
  ['how does vector search work'],
)
console.log(rows.map((r) => r.title))

Python

import os
import reddb  # pip install reddb-client

db = reddb.connect(os.environ["REDDB_URL"])

# Auto-embed and insert
db.execute(
    """
    INSERT INTO articles (id, title, body)
    VALUES (%s, %s, %s)
    WITH AUTO EMBED (body) USING openai
    """,
    (1, "RedDB vectors", "Vector search and relational SQL in one engine."),
)

# Similarity search
rows = db.fetchall(
    "SEARCH SIMILAR TO %s IN articles USING HNSW LIMIT 5",
    ("how does vector search work",),
)
print([r["title"] for r in rows])

Use cases

Where vectors earn their place.

RAG over docs

Customer support, internal wikis, product docs — semantic retrieval without a Pinecone sync job.
Anomaly clustering

Group similar logs / transactions / support tickets without a labelled training set.
Recommendations

User-to-product or product-to-product similarity stored next to the relational facts you join on.
Deduplication

Find near-duplicate rows that exact-match indexes don't catch (typos, formatting differences).

Build it

End-to-end walkthrough.

Four steps from empty database to a real vectors workload — each step shows the exact code and explains what the engine is doing.

Step 1

1. Create the vector collection

Declare the vector column with its dimension matching your embedding model (1536 for OpenAI ada-002, 768 for many sentence-transformers). The IVF index is tunable per workload — lists = sqrt(rows) is a sane starting point.
Step 1
```
CREATE TABLE notes (
  id     UUID PRIMARY KEY DEFAULT gen_uuid(),
  body   TEXT NOT NULL,
  meta   JSONB,
  vec    VECTOR(1536)
);

CREATE INDEX idx_notes_vec ON notes
  USING IVFFLAT (vec) WITH (lists = 100);
```

Step 2

2. Auto-embed on insert

WITH AUTO EMBED calls your configured embedding provider on the text columns listed in parentheses, populates the vec column at write time, and indexes it. You don't run a separate embedding pipeline.

Step 2

INSERT INTO notes (body, meta) VALUES
  ('suspicious vpn login from new country',
    '{"user_id":42,"severity":"high"}'),
  ('payment retry succeeded after 3 attempts',
    '{"user_id":42,"severity":"info"}')
WITH AUTO EMBED (body) USING openai;

Step 3

3. Similarity search

SEARCH SIMILAR TEXT embeds the query string with the same provider, runs k-NN against the index, and applies the WHERE filter post-retrieval. Hybrid filters (vector + structured) work in one statement — no two-system join.
Step 3
```
SEARCH SIMILAR TEXT 'login anomaly'
  COLLECTION notes
  WHERE meta->>'severity' = 'high'
  LIMIT 10;
```
Step 4

4. Hybrid search + RAG

Hybrid search combines semantic similarity with traditional keyword scoring at configurable weights. WITH CONTEXT DEPTH 1 then expands each hit by 1 graph hop — the canonical RAG retrieval pattern, in one query.
Step 4
```
SEARCH HYBRID
  TEXT 'login anomaly'        WEIGHT 0.7
  KEYWORDS 'vpn,brute-force'  WEIGHT 0.3
  COLLECTION notes
  WITH CONTEXT DEPTH 1
  LIMIT 5;
```

Engine features

What RedDB adds on top of vectors.

The engine knobs you would otherwise wire up yourself — TTL, encryption, indexes, atomic ops, eventual consistency — applied to this data model.

Auto-embed on insert (8+ providers)

WITH AUTO EMBED (col) USING <provider> resolves text to a vector at write time — OpenAI, Anthropic, Groq, OpenRouter, Together, Venice, DeepSeek, Ollama (or any OpenAI-compatible API). You don't run a separate embedding pipeline.
IVFFLAT + HNSW indexes

Two index types: IVFFLAT is recall-tunable and cheap to rebuild; HNSW is faster on cold queries but more expensive to maintain. Pick per write/read ratio.
Hybrid retrieval (vector + keyword + filter)

SEARCH HYBRID TEXT ... WEIGHT 0.7 KEYWORDS ... WEIGHT 0.3 WHERE meta->>... combines semantic similarity, BM25 keyword scoring, and structured filters in one statement. The optimiser plans the cheapest side first.
VectorRef typed pointers

A RowRef-style typed column (VectorRef) constrains values to point at vector-collection items. Useful for "this product's recommendation seed lives in notes" cross-collection patterns.
Context expansion (vector + graph)

SEARCH SIMILAR ... WITH CONTEXT DEPTH N runs vector retrieval, then expands each hit by N graph hops, returning the combined neighbourhood — the RAG retrieval shape natively.
TTL eviction

Per-row WITH TTL lets the engine evict stale embeddings — useful when source content has a natural shelf life (news articles, time-bound recommendations).
Encryption at rest (Value::Secret metadata)

Vector columns themselves are not encrypted (operations need to compute distance), but adjacent metadata columns (PII text, user identifiers) can be Value::Secret and auto-encrypt with the vault AES key.
Collection-scoped policies

A policy can restrict SEARCH SIMILAR to a subset of collections per principal — e.g. customer support sees public_docs but not internal_engineering. The engine refuses the query at parse time.
Audit log of retrievals

Every SEARCH SIMILAR can be audited with the query text, principal, and result IDs — useful for compliance ("who has searched for this content?") and debugging recommender drift.

Showcases

What vectors can do once you bring the rest of the engine in.

Cross-model correlation, algorithm flex, multi-model patterns — things that take a stack of services elsewhere.

Provider keys stay in the vault — never in your code

AUTO EMBED resolves $red.secret.openai.api_key from the vault on every insert. Application code never sees the key.

Set the provider key once via the secrets vault. Every AUTO EMBED USING openai reads it through the typed $secret reference internally — no env var to leak, no key in source, no .env in your repo. Rotate by updating the KV; running queries pick up the new value on next call.

sql

Provider keys stay in the vault — never in your code

-- Once, by an authorised principal.
SET CONFIG red.secret.openai.api_key = 'sk-...';

-- Forever after, by any service.
INSERT INTO notes (body) VALUES ($1)
  WITH AUTO EMBED (body) USING openai;
-- Engine reads $red.secret.openai.api_key from vault as a typed Value.
-- Application code holds no key; logs hold no key; query plans hold no key.

-- Hybrid retrieval same way.
SEARCH HYBRID
  TEXT $1                 WEIGHT 0.7
  KEYWORDS $2             WEIGHT 0.3
  COLLECTION docs
  USING openai            -- vault-resolved
  LIMIT $config.acme.rag.contextSize;

Cross-model RAG: vector + graph + table in one round trip

Semantic retrieval, graph context expansion, relational facts, all in one query.

User asks 'who owns passport AB1234567 and what services do they use?'. The engine vector-searches notes for semantic context, expands each hit by 1 graph hop (OWNS / USES edges), joins to the relational users + services tables, and returns the assembled context — ready for the LLM. No retrieval orchestrator service.

sql

Cross-model RAG: vector + graph + table in one round trip

WITH ctx AS (
  SEARCH SIMILAR TEXT 'who owns passport AB1234567 and what services'
    COLLECTION notes
    WITH CONTEXT DEPTH 2
    LIMIT 5
)
SELECT
  u.name           AS owner,
  s.name           AS service,
  s.tier,
  c.note_excerpt,
  c.score          AS relevance
FROM ctx c
LEFT JOIN users    u ON u.id::text = c.connected_node_id
                     AND c.connected_kind = 'user'
LEFT JOIN services s ON s.id::text = c.connected_node_id
                     AND c.connected_kind = 'service';

Auto-embed + hybrid + filter at ingestion scale

High-cardinality batch ingest with automatic embedding, no Pinecone sync.

Bulk insert 10k product records — auto-embed runs against your configured provider in batches, the IVF index is updated, structured filters and BM25 keyword scoring all stay queryable in the same statement.

sql

Auto-embed + hybrid + filter at ingestion scale

INSERT INTO products (sku, title, description, meta)
SELECT sku, title, description, meta
FROM staging_products
WITH AUTO EMBED (title, description) USING openai
ON CONFLICT (sku) DO UPDATE
  SET title       = EXCLUDED.title,
      description = EXCLUDED.description,
      vec         = EXCLUDED.vec;

-- Hybrid search the next minute.
SEARCH HYBRID
  TEXT       'lightweight running shoes for trails'  WEIGHT 0.7
  KEYWORDS   'trail,waterproof,running'              WEIGHT 0.3
  COLLECTION products
  WHERE meta->>'in_stock' = 'true'
    AND (meta->>'price')::numeric < 200
  LIMIT 20;

Migrate from

Bring vectors over from your current tool.

From

Pinecone

Stream Pinecone vectors via fetch-by-id, write them straight into a RedDB collection. Auto-embed kicks in for any new rows.

Migrate from Pinecone

red migrate vectors \
  --from "pinecone://<index>?namespace=prod" \
  --to   "reds://admin@<db>.<org>.db.reddb.io:5050" \
  --collection notes \
  --batch-size 1000

From

pgvector

A vector(N) column already maps cleanly. SELECT INTO across the wire — no re-embedding required.

Migrate from pgvector

INSERT INTO notes (id, body, vec)
SELECT id, body, embedding::vector(1536)
FROM postgres_export.notes;

Recipes

Common patterns, real driver code.

Semantic search over a knowledge base

sql

Embed at insert, retrieve by similarity, filter by metadata in one query.

sql

SEARCH SIMILAR TEXT 'how do I rotate api keys?'
  COLLECTION docs
  WHERE meta->>'product' = 'cloud'
    AND meta->>'visibility' = 'public'
  LIMIT 5;

Hybrid retrieval for RAG

typescript

Combine semantic + keyword scoring at configurable weights, expand by graph context, ship to the LLM.

typescript

const ctx = await db.query(`
  SEARCH HYBRID
    TEXT $1               WEIGHT 0.7
    KEYWORDS $2           WEIGHT 0.3
    COLLECTION docs
    WITH CONTEXT DEPTH 1
    LIMIT 8
`, [userQuestion, keywordsFromQuestion(userQuestion)])

const answer = await llm.complete({
  system: 'Answer using only the provided context.',
  context: ctx.rows,
  user: userQuestion,
})

Near-duplicate detection

python

Find records that look semantically identical (typos, formatting differences) that exact-match indexes miss.

python

from reddb import connect

db = connect("reds://admin@.../my-db:5050")

dupes = db.query("""
  SEARCH SIMILAR TEXT $1 COLLECTION customer_records
  WHERE id <> $2
  LIMIT 10
""", [record.full_name, record.id])

near = [r for r in dupes if r.score > 0.92]

Limits

What it does. What it costs.

Operational caps and durability semantics, no hand-waving.

Vector dimensions: 64–4096 (OpenAI ada-002 = 1536)
Index types: IVFFLAT (recall-tunable) and HNSW (faster cold queries)
Embedding providers: Any OpenAI-compatible API (8+ presets)
Hybrid query depth: Vector + keyword + filter + graph in one statement
Throughput: ~241k bulk ops/sec on commodity hardware (gRPC)

When NOT to use

Don't pick vectors for these.

Honest constraints — when another model fits better.

Don't auto-embed body fields that are 100s of MB

Embedding cost scales with token count. Chunk + summarise long documents application-side before letting AUTO EMBED hit the provider.
Avoid mixing dimensions in one collection

A collection holds one fixed dimension. Pick OpenAI 1536 OR sentence-transformers 768 — not both. Provider migrations require re-embedding everything.
Don't store embeddings without the source text

You will want to re-embed when the model changes. Keep the original text in the same row so a re-embed is a single UPDATE, not a join across systems.

How RedDB vectors compare.

Pinecone

Vector storage on the same engine as your other data. No 'eventual sync', no ID drift, no separate billing.
pgvector

Auto-embed on insert is built-in. You don't write the embedding pipeline yourself.

Pairs with

Vectors earns more next to these.

The data models vectors compose with — a click away.

Graphs

Hybrid retrieval (`WITH CONTEXT DEPTH N`) expands each vector hit by N graph hops — RAG context in one query.

edges Graphs guide
Documents

Document collections are the natural source — auto-embed a `body` field and the vector index sits next to the JSON.

json Documents guide
Tables

Filter by typed columns (`tenant_id`, `tier`) AND nearest-neighbour in a single hybrid query.

relational Tables guide

Questions teams ask before they pick vectors.

Explore

Every other data model on RedDB.

One engine, 9 first-class data models. Mix as needed.

Tables

Postgres-wire SQL with indexes, joins, transactions.

relational Tables guide
Documents

Schemaless JSON when structure is partial — query by path.

json Documents guide
Graphs

Native edges and traversals — multi-hop without a side-car.

edges Graphs guide
Key-Value

Configuration, feature flags, hot keys — millisecond reads.

fast state Key-Value guide
Cache

Tiered blob cache built into the engine: L1 memory + L2 durable.

tiered TTL Cache guide
Time-series

Retention, downsampling, native window queries.

metrics Time-series guide
Queues

FIFO, priority, consumer groups — durable workflow primitives.

workflows Queues guide
Probabilistic

HyperLogLog, Count-Min Sketch, Cuckoo Filter — bounded-memory analytics.

sketches Probabilistic guide

Try vectors on RedDB.

Free nano database, no credit card. Self-host under BSL 1.1 or managed Cloud — same engine, same file format.

Start free See pricing

Vectors

Vectors on RedDB.

Write it. Read it. Same engine.

Connect from your language.

Where vectors earn their place.

End-to-end walkthrough.

1. Create the vector collection

2. Auto-embed on insert

3. Similarity search

4. Hybrid search + RAG

What RedDB adds on top of vectors.

What vectors can do once you bring the rest of the engine in.

Provider keys stay in the vault — never in your code

Cross-model RAG: vector + graph + table in one round trip

Auto-embed + hybrid + filter at ingestion scale

Bring vectors over from your current tool.

Pinecone

pgvector

Common patterns, real driver code.

What it does. What it costs.

Don't pick vectors for these.

How RedDB vectors compare.

Vectors earns more next to these.

Questions teams ask before they pick vectors.

Every other data model on RedDB.

Try vectors on RedDB.