THEODB · THE AI DATABASE

One database for your data and your AI.

Built on Postgres — embeddings, vector search, hybrid retrieval, and AI functions in SQL. Your vectors live in the same rows as your data. No ETL.

PostgreSQL-compatible · AI and vector search callable from SQL · no ETL to a separate vector store.

12AI + vector capabilities
PostgreSQL 17wire-compatible
1 SQLvectors + joins + AI in one query
3vector distance metrics
Any modelbring your embedding endpoint
0 ETLno separate vector DB

Join the waitlist Read the docs

Building AI features on Postgres usually means bolting a vector store onto your database, then keeping two systems in sync — embeddings drift from the rows they describe, and every query becomes a join you do in application code. TheoDB collapses that: embeddings, vector search, hybrid retrieval, and AI calls are all SQL, running next to the relational data they belong to.

What you get

Concretely, what ships.

Vector search in SQL

Query vector columns with <=>, <->, <#>, backed by HNSW, IVFFlat, and DiskANN.

Embeddings from SQL

theodb.embed() writes the embedding and the row together, from your model endpoint.

Hybrid search, fused

ai.hybrid_search() combines full-text and vector similarity with RRF in one call.

AI functions in SQL

ai.generate, ai.summarize, ai.analyze_sentiment, and ai.rank inside your queries.

Natural language → SQL

ai.nl_query() turns a question into a validated, read-only SELECT over an allowlist.

Bring your own model

Feel it

sql

-- Semantic search + operational filter + AI summary, all in SQL
SELECT p.id,
       p.description,
       ai.summarize(p.description) AS gist
FROM products p
JOIN inventory i ON i.product_id = p.id
WHERE i.in_stock
  AND p.category_id = 3
ORDER BY p.embedding <=> theodb.embed('lightweight trail shoes')
LIMIT 5;

Vectors, a relational join, and AI — one statement, one transaction.

What you'd ship

Things you would actually build.

01RAG over your own data — embed, store, and retrieve without a second datastore.
02Semantic + keyword search in one ai.hybrid_search() call, ranked by RRF.
03In-database enrichment — sentiment, summaries, and scoring as SQL columns.
04Ask-your-database — ai.nl_query() answers questions as safe, read-only SELECTs.
05Migrate off a standalone vector DB — theodb.import_vectors() ingests a Pinecone export.
06Agent memory and retrieval — embeddings, filters, and joins in one consistent transaction.

Why TheoDB

How it compares.

Most teams add retrieval by gluing a vector store, an embedding pipeline, and an LLM API onto a database that already holds the data. That glue is where staleness and complexity accumulate. Comparison at the capability level.

Capability	TheoDB	pgvector + glue	Dedicated vector DB
Vectors + your data	Same rows, one database	Same DB, manual wiring	Separate store, synced via ETL
Embeddings	theodb.embed() in SQL	Call an API in app code	External pipeline
Generation & classify	ai.generate / ai.summarize in SQL	App code + AI API	Not offered
Hybrid (keyword + vector)	ai.hybrid_search() with RRF	Wire FTS + vector yourself	Varies
Drivers & tooling	PostgreSQL-compatible	Postgres	New client + query language

One Postgres-compatible database where your vectors, your data, and your AI calls share the same query — instead of a vector DB, an embedding pipeline, and an AI service you keep in sync.

Why now

Every product team is adding retrieval and AI features, mostly by gluing systems onto a database that already holds the data. Keeping vectors and AI beside the rows they describe removes the sync problem before it starts.

Status

Honest claims only.

AI and vector search callable from SQL — embeddings, hybrid retrieval, generation, and NL→SQL.
PostgreSQL-compatible: your existing drivers and ORMs work; vectors and rows share one query.
Commercial product, access via the waitlist · columnar / HTAP analytics on the roadmap.