UQL | Blog

Semantic Search: Native Vector Similarity in a Multi-Dialect ORM

Thu, 12 Mar 2026 00:00:00 GMT

AI-powered search is everywhere, but if you use an ORM, you’ve probably hit this wall: the moment you need vector similarity, you’re forced to use raw SQL. Hand-written distance expressions, and dialect-specific quirks — all outside your type-safe query API.

UQL 0.3 changes that. Native semantic search is now a first-class citizen, featuring automatic index migration for HNSW/IVFFlat and zero-allocation performance.

What It Looks Like

You write

const results = await querier.findMany(Article, {
  $select: { id: true, title: true },
  $sort: { embedding: { $vector: queryEmbedding, $distance: 'cosine' } },
  $limit: 10,
});

UQL generates the right SQL for your database:

PostgreSQL

SELECT "id", "title" FROM "Article"
ORDER BY "embedding" <=> $1::vector
LIMIT 10

MariaDB

SELECT `id`, `title` FROM `Article`
ORDER BY VEC_DISTANCE_COSINE(`embedding`, ?)
LIMIT 10

SQLite

SELECT `id`, `title` FROM `Article`
ORDER BY vec_distance_cosine(`embedding`, ?)
LIMIT 10

No raw SQL. No dialect checks. Same query everywhere.

For MongoDB, UQL translates into an Atlas $vectorSearch pipeline — same API, zero config:

MongoDB Atlas

[
  { "$vectorSearch": { "index": "embedding_index", "path": "embedding", "queryVector": ["..."], "numCandidates": 100, "limit": 10 } }
]

Entity Setup

Define your vector field and index — UQL handles schema generation, extension creation, and index building:

import { Entity, Id, Field, Index } from 'uql-orm';

@Entity()
@Index(['embedding'], { type: 'hnsw', distance: 'cosine', m: 16, efConstruction: 64 })
export class Article {
  @Id() id?: number;
  @Field() title?: string;

  @Field({ type: 'vector', dimensions: 1536 })
  embedding?: number[];
}

For Postgres, UQL automatically emits CREATE EXTENSION IF NOT EXISTS vector. MariaDB and SQLite just work — no extensions needed.

Key Features

Distance Projection

Project the computed distance into your results with $project — no duplicate computation:

import type { WithDistance } from 'uql-orm';

const results = await querier.findMany(Article, {
  $select: { id: true, title: true },
  $sort: { embedding: { $vector: queryVec, $distance: 'cosine', $project: 'similarity' } },
  $limit: 10,
}) as WithDistance<Article, 'similarity'>[];

results[0].similarity; // autocomplete works ✓

WithDistance<E, K> adds a typed distance property to each result — your IDE autocompletes it, and typos are caught at compile time.

5 Distance Metrics

Metric	Postgres	MariaDB	SQLite	MongoDB Atlas
`cosine`	`<=>`	✅	✅	✅ (index-defined)
`l2`	`<->`	✅	✅	✅ (index-defined)
`inner`	`<#>`	—	—	✅ (index-defined)
`l1`	`<+>`	—	—	—
`hamming`	`<~>`	—	✅	—

3 Vector Types

Type	Storage	Use Case
`'vector'`	32-bit float	Standard embeddings (OpenAI, etc.)
`'halfvec'`	16-bit float	50% storage savings, near-identical accuracy
`'sparsevec'`	Sparse	SPLADE, BM25-style sparse retrieval

halfvec and sparsevec are Postgres-only. MariaDB and SQLite transparently map them to their native VECTOR type — your entities work everywhere.

Vector Indexes

Type	Postgres	MariaDB	MongoDB Atlas
HNSW	✅ with `m`, `efConstruction`	❌	❌
IVFFlat	✅ with `lists`	❌	❌
Native	—	✅ `VECTOR INDEX`	✅ `$vectorSearch`

Why `$sort`?

Vector similarity search is fundamentally sorting by distance. UQL reuses the existing $sort API, which composes naturally with $where, $select, $limit, and regular sort fields:

const results = await querier.findMany(Article, {
  $where: { category: 'science' },
  $sort: { embedding: { $vector: queryVec, $distance: 'cosine' }, title: 'asc' },
  $limit: 10,
});

No new concepts to learn. The query API you already know now handles AI search.

Get Started

npm i uql-orm

Full documentation →
GitHub

We’d love to hear how you’re using vector search in your projects — open an issue on GitHub and let us know!

In Search of the Fastest TypeScript ORM

Tue, 10 Mar 2026 00:00:00 GMT

I kept seeing “just use Drizzle, it’s lightweight” and “ORMs are slow, use a query builder” repeated everywhere. So I decided to actually measure it.

Pure SQL generation speed — no database, no network, no connection pool. Just the overhead your ORM adds to every single request.

7 entries. 8 query types. 3 runs averaged. Apple Silicon M4.

Methodology

Environment: Node.js v24, Apple Silicon M4, 3 runs averaged.
Versions: Latest stable of every ORM/QB as of March 2026.
Fairness: Each ORM uses its most idiomatic API — QueryBuilder for TypeORM/MikroORM, which benefits them by skipping entity overhead.
What’s measured: Pure SQL string generation — no database, no I/O, no connection pool. This isolates ORM overhead only.
Why no Prisma? Prisma is not a pure TypeScript/JavaScript ORM — only its client is JS/TS. The query engine is a separate Rust binary that builds SQL, making it architecturally incomparable and not even testable this way.

The Results

INSERT — 10 rows in batch

Entry	ops/sec	vs winner
UQL	606K 🥇	—
Knex	407K	0.67x
Sequelize	202K	0.33x
Kysely	197K	0.33x
MikroORM	50K	0.08x
TypeORM	47K	0.08x
Drizzle	13K	0.02x

UPDATE — SET + WHERE

Entry	ops/sec	vs winner
UQL	1,817K 🥇	—
Kysely	819K	0.45x
Knex	601K	0.33x
TypeORM	321K	0.18x
Sequelize	234K	0.13x
MikroORM	119K	0.07x
Drizzle	81K	0.04x

UPSERT — ON CONFLICT by id

Entry	ops/sec	vs winner
UQL	693K 🥇	—
Knex	349K	0.50x
Sequelize	334K	0.48x
Kysely	334K	0.48x
TypeORM	316K	0.46x
MikroORM	130K	0.19x
Drizzle	38K	0.05x

DELETE — simple WHERE

Entry	ops/sec	vs winner
UQL	3,642K 🥇	—
Sequelize	1,349K	0.37x
Kysely	1,290K	0.35x
Knex	962K	0.26x
TypeORM	542K	0.15x
Drizzle	212K	0.06x
MikroORM	148K	0.04x

SELECT — 1 field

Entry	ops/sec	vs winner
UQL	3,994K 🥇	—
Sequelize	3,143K	0.79x
Kysely	1,559K	0.39x
Knex	994K	0.25x
TypeORM	817K	0.20x
MikroORM	297K	0.07x
Drizzle	238K	0.06x

SELECT — WHERE + SORT + LIMIT

Entry	ops/sec	vs winner
UQL	1,200K 🥇	—
Knex	480K	0.40x
Kysely	425K	0.35x
Sequelize	385K	0.32x
TypeORM	355K	0.30x
Drizzle	60K	0.05x
MikroORM	46K	0.04x

SELECT — Complex $or + operators

Entry	ops/sec	vs winner
UQL	644K 🥇	—
Kysely	218K	0.34x
Knex	199K	0.31x
TypeORM	186K	0.29x
Sequelize	152K	0.24x
Drizzle	35K	0.05x
MikroORM	22K	0.03x

AGGREGATE — GROUP BY + COUNT + HAVING

Entry	ops/sec	vs winner
UQL	1,489K 🥇	—
Sequelize	407K	0.27x
TypeORM	364K	0.24x
Knex	284K	0.19x
Kysely	227K	0.15x
Drizzle	77K	0.05x
MikroORM	64K	0.04x

📊 Interactive charts →

Three Things That Surprised Me

1. The “lightweight” query builder is the slowest thing in the benchmark.

Drizzle — marketed as lightweight — is slower than Sequelize (a full ORM from 2014) in every single category. The functional expression-tree approach creates more intermediate objects than Sequelize’s simple string concatenation.

2. Standalone query builders can’t beat a well-designed ORM.

Knex and Kysely have zero entity/relation overhead. They’re just SQL string builders. Yet UQL — a full ORM with entities, relations, and migrations — is faster than both in all 8 categories. This 4x-40x overhead advantage demonstrates that the conventional wisdom (“ORMs are slow”) doesn’t hold when the ORM is designed for performance with a Zero-Allocation architecture from day one.

3. MikroORM pays double.

MikroORM uses Knex internally as its SQL generator. So every query goes through two compilation layers: MikroORM → Knex → SQL string. The result? MikroORM averages 4-5x slower than Knex alone. That’s the cost of layering abstractions.

How UQL Gets There

I got curious why the gap was so large, so I dug into the approach. Most ORMs figure out your schema at query time: “What table does User map to? What column is companyId? Is it nullable?” — they answer these questions on every single query.

UQL answers them once at startup. Field-to-column mappings, table names, relation paths — all pre-computed into lookup tables before the first query runs. At query time, generating SQL is just reading from a cache.

The other difference is allocation. When TypeORM builds a SELECT, it creates a QueryBuilder, then an expression tree, then walks the tree to produce SQL. UQL pushes SQL fragments directly into a string buffer — no intermediate objects, no garbage collection pressure.

Does This Matter in Production?

Database latency is 1-50ms. ORM overhead is microseconds. So who cares?

You care at scale. If you’re running a moderately busy API — say 1,000 req/s:

UQL adds 1 CPU-second of ORM overhead
MikroORM adds 20 CPU-seconds — for the same queries

That’s 20x more CPU burned on generating SQL strings — pure waste before a single byte hits the network. In serverless (where you pay per ms), that’s your bill. In containers, that’s your horizontal scaling cost.

Reproduce It

Full disclosure: I’m the author of UQL. That’s exactly why I built the benchmark as an independent repo anyone can audit and reproduce.

The full benchmark is open source — clone it, audit it, run it, share results. No database needed, finishes in seconds. See how UQL maintains its 4x-40x performance lead across every modern TypeScript environment.

Repo: ts-orm-benchmark

In Search of the Perfect TypeScript ORM

Sat, 15 Jun 2024 00:00:00 GMT

Originally published on Medium.

What is an ORM?

An ORM provides a simpler way to interact with databases in an app — it allows developers to work with data using objects.

What is a Perfect ORM for TypeScript?

Below are the ideal features a TypeScript ORM should have, why such features are the most important ones, and how the existing ORMs fall short in most of these areas.

The top 5 features a perfect TypeScript ORM should have are:

1. Serializable Queries

The ability to transport queries between the layers of a system is great for flexibility and simplicity. For example, via HTTP requests, APIs, websockets, or even the frontend/client (optional) could transmit the queries to the backend/server using the same (ORM) syntax and avoid the need for an additional syntax layer like what happens with GraphQL in the flow GraphQL => ORM => Database. The flow could instead be simplified as ORM => Database; with the following advantages:

Keep away from the need for pseudo-languages to define the queries (context-switching). Instead, use standard JSON as the syntax for the queries so they are entirely declarative and serializable.
Avoid additional servers and steps in the build process of the app.
Native support of the editors/IDEs for the queries without any custom plugins/extensions.

2. Native TypeScript

Squeeze TypeScript’s power with JSON, classes, and decorators.

Type-safe queries and models that are natively validated by the same language that you use to write your app.
Context-aware queries allow auto-completion of the appropriate operators and fields according to the different parts of a query.
Entity definition with standard classes and decorators to avoid the need for proprietary DSLs (as happens with Prisma), extra steps in the build process, and custom extensions for the editors.

3. Multi-level Operators

Operations such as filter, sort, limit, project, and others work on any level of the queries (including relations and their fields).

4. Consistent API Across Databases

Write the queries for any database in a consistent way and then transparently optimize these queries for the configured database dialect.

5. Universal Syntax (Language Agnostic)

The ability to write queries in any language opens the door to many possibilities, even porting the ORM to other languages. For example, JSON is a first-class citizen format on almost any modern language out there, including Python, Rust, and others (besides JavaScript).

Why Do the Current Top 3 TypeScript ORMs Fall Short?

What does TypeORM lack to be a perfect ORM?

1. Lack of 100% serializable queries:

Notice how the LessThan operator is a function that has to be imported and called — this precludes any capability to serialize the query.

import { LessThan } from 'typeorm';

const loadedPosts = await dataSource.getRepository(Post).findBy({
  likes: LessThan(10),
});

2. Lack of Native TypeScript:

The query dissolves into strings because relations and where can accept any string, thus any invalid string can be put there.

const posts = await connection.manager.find(Post, {
  select: ['id'],
  relations: ['< anything can go here >'],
});

3. Lack of consistent API across databases:

In the section that TypeORM has for MongoDB, there is a self-explanatory warning about this.

4. Lack of Universal Syntax (language agnostic):

It relies on closures to support advanced queries (and not every language out there supports closures).

What does Prisma lack to be a perfect ORM?

1. Lack of Native TypeScript:

Context-switching between the custom DSL and TypeScript makes this process obtrusive.
Extra steps in the build process to generate the corresponding files from the custom DSL.
It is required to install a custom extension for VS Code to get (basic) autocompletion from the editor for the DSL, which is far from being as good and reliable as with TypeScript.

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  email     String   @unique
  name      String?
  role      Role     @default(USER)
  posts     Post[]
}

2. Lack of consistent API across databases:

Prisma exposes low-level details about MongoDB that could be encapsulated by the ORM.

model User {
  id String @id @default(auto()) @map("_id") @db.ObjectId
  // Other fields
}

3. Lack of Universal Syntax (language agnostic):

It relies on its own proprietary DSL to define the models.

What does MikroORM lack to be a perfect ORM?

1. Lack of 100% serializable queries:

Notice how that query uses two separate methods, one for the update and another for the where — this disallows the serialization of its queries.

const qb = orm.em.createQueryBuilder(Author);

qb.update({ name: 'test 123', type: PublisherType.GLOBAL }).where({
  id: 123,
  type: PublisherType.LOCAL,
});

2. Lack of Native TypeScript:

Dissolves into strings — any string can go inside the fields array, so the query loses the possibility of being type-safe.

const author = await em.findOne(
  Author,
  {},
  {
    fields: ['name', 'books.title', 'books.author', 'books.price'],
  }
);

3. Lack of Multi-level operators:

What if you need to filter the records of a relation or sort them? This seems unachievable in a type-safe way from what can be seen in the MikroORM docs.

4. Lack of consistent API across databases:

import { EntityManager } from '@mikro-orm/mongodb';
const em = orm.em as EntityManager;
const qb = em.aggregate(/* ... */);

MikroORM exposes low-level details about MongoDB that could be encapsulated by the ORM.

Why is UQL the Closest to a Perfect ORM?

In short, because it was designed from the beginning with all of the above foundations. Let’s see how.

1. 100% Serializable Queries

Even the insert and update operations have a fully serializable API.

const lastUsers = await querier.findMany(User, {
  $select: { id: true, name: true, email: true },
  $sort: { createdAt: -1 },
  $limit: 20,
});

2. Native TypeScript with Truly Type-safe Queries

Every operator and field is validated according to the context. For example, the possible values for the $select operator will automatically depend on the level.

const lastUsersWithProfiles = await querier.findMany(User, {
  $select: {
    id: true,
    name: true,
    profile: {
      $select: { id: true, picture: true },
      $required: true,
    },
  },
  $sort: { createdAt: -1 },
  $limit: 20,
});

3. Multi-level Operators

The operators work on any level. For example, $sort and $where can be applied to the relations and their fields in a type-safe and context-aware way.

const items = await querier.findMany(Item, {
  $select: {
    id: true,
    name: true,
    measureUnit: {
      $select: { id: true, name: true },
      $where: { name: { $ne: 'unidad' } },
      $required: true,
    },
    tax: { $select: { id: true, name: true } },
  },
  $where: {
    salePrice: { $gte: 1000 },
    name: { $istartsWith: 'A' },
  },
  $sort: {
    tax: { name: 1 },
    measureUnit: { name: 1 },
    createdAt: -1,
  },
  $limit: 100,
});

4. Consistent API Across Databases

Its API is unified across different databases — it does the magic under the hood so the same entities and queries could transparently work on any supported database. This makes it easier to switch from a Document to a Relational database (or vice-versa).

5. Universal Syntax Across Languages

Its syntax is 100% standard JSON, opening the door for many possibilities with other languages — like interoperation or even creating versions of UQL in other languages such as Python or Rust with ease.

See more at uql-orm.dev. Please star it ⭐ on GitHub if you like the idea!

UQL | Blog

Semantic Search: Native Vector Similarity in a Multi-Dialect ORM

What It Looks Like

Entity Setup

Key Features

Distance Projection

5 Distance Metrics

3 Vector Types

Vector Indexes

Why $sort?

Get Started

In Search of the Fastest TypeScript ORM

Methodology

The Results

INSERT — 10 rows in batch

UPDATE — SET + WHERE

UPSERT — ON CONFLICT by id

DELETE — simple WHERE

SELECT — 1 field

SELECT — WHERE + SORT + LIMIT

SELECT — Complex $or + operators

AGGREGATE — GROUP BY + COUNT + HAVING

Three Things That Surprised Me

How UQL Gets There

Does This Matter in Production?

Reproduce It

In Search of the Perfect TypeScript ORM

What is an ORM?

What is a Perfect ORM for TypeScript?

1. Serializable Queries

2. Native TypeScript

3. Multi-level Operators

4. Consistent API Across Databases

5. Universal Syntax (Language Agnostic)

Why Do the Current Top 3 TypeScript ORMs Fall Short?

What does TypeORM lack to be a perfect ORM?

What does Prisma lack to be a perfect ORM?

What does MikroORM lack to be a perfect ORM?

Why is UQL the Closest to a Perfect ORM?

1. 100% Serializable Queries

2. Native TypeScript with Truly Type-safe Queries

3. Multi-level Operators

4. Consistent API Across Databases

5. Universal Syntax Across Languages

Why `$sort`?