Vector Search and AI Embeddings in ormDB

Native Vector Search

ormDB is a relational database engine written in Rust that replaces PostgreSQL, MySQL, and SQLite. Vector search is built directly into the engine using HNSW (Hierarchical Navigable Small World) indexes for fast approximate k-nearest neighbor queries. There is no extension to install and no external service to manage.

This means your relational data and vector embeddings live in the same database, queryable in the same request. Search for semantically similar documents and include their authors, tags, and comments in a single graph fetch.

Defining Vector Columns

Add a vector column to any entity in your schema:

entity Article {
  id: uuid @primary
  title: text
  body: text
  status: text
  author_id: uuid @relation(User)
  embedding: vector(1536) @index(hnsw, metric: cosine)
}

The vector(1536) type declares a 1536-dimensional vector column. The @index(hnsw, metric: cosine) annotation creates an HNSW index using cosine similarity as the distance metric.

Inserting Embeddings

Store embeddings alongside your relational data:

await db.insert('Article', {
  id: 'article_001',
  title: 'Introduction to Graph Databases',
  body: '...',
  status: 'published',
  author_id: 'user_042',
  embedding: await openai.embeddings.create({
    model: 'text-embedding-ada-002',
    input: 'Introduction to Graph Databases ...',
  }).data[0].embedding,
})

Querying by Similarity

Find the k nearest neighbors to a query vector:

const queryEmbedding = await openai.embeddings.create({
  model: 'text-embedding-ada-002',
  input: 'How do graph databases handle relationships?',
}).data[0].embedding

const similar = await db.vectorSearch('Article', {
  field: 'embedding',
  vector: queryEmbedding,
  k: 10,
  where: { status: 'published' },
})

The where clause filters before the vector search, so you only search within published articles. The result includes the matched entities with their similarity scores.

Vector Search with Graph Fetch

Combine vector search with graph fetches to get related data in a single round-trip:

const results = await db.vectorSearch('Article', {
  field: 'embedding',
  vector: queryEmbedding,
  k: 10,
  where: { status: 'published' },
  include: {
    author: {
      fields: ['id', 'name', 'avatar_url'],
    },
    tags: true,
    comments: {
      limit: 3,
      order_by: { created_at: 'desc' },
      include: {
        author: { fields: ['id', 'name'] },
      },
    },
  },
})

This single request finds the 10 most similar published articles and returns each with its author, tags, and 3 most recent comments (including comment authors). In a traditional setup, this would require a vector search service, followed by multiple database queries for the relational data.

Index Configuration

Tune HNSW index parameters for your workload:

entity Product {
  id: uuid @primary
  name: text
  description: text
  embedding: vector(768) @index(hnsw, {
    metric: cosine,
    m: 16,
    ef_construction: 200,
    ef_search: 100
  })
}

• m: Maximum number of connections per node (higher = more accurate, more memory)
• ef_construction: Search depth during index building (higher = better index quality, slower builds)
• ef_search: Search depth during queries (higher = more accurate results, slower queries)

Use Cases

Semantic search: Find documents, products, or support tickets by meaning rather than keywords. Combine with full-text search for hybrid retrieval.

Recommendation engines: Find similar items based on embedding similarity. Include relational data (reviews, categories, pricing) in the same query.

RAG applications: Retrieve relevant context for large language models directly from your application database, with full relational context attached. ormDB is the ideal database for AI applications.

Vector search in ormDB is not a bolt-on feature. It is indexed, filtered, and composable with graph fetches, all within the same ACID transaction guarantees as the rest of your data. Compare this to the extension-based approach of PostgreSQL or separate services required by DynamoDB.