ORM Benchmark

Our open-source benchmark puts each ORM through a full PostgreSQL lifecycle: insert, read, update, read, nested read, delete, read. Here is the latest run.

PostgreSQL 18.6 (Homebrew), Bun 1.4.2, Apple M4 Max, September 2026. Median µs per operation over 250 rounds, after 125 warmup rounds, interleaved and rotated. Every median is ±2.4% or tighter at 95% confidence.

Versions: Drizzle 0.45.2 · MikroORM 7.2.0 · Prisma 7.10.0 · Sequelize 6.37.8 · TypeORM 1.1.1 · UQL 0.68.1.

Results

Adds is what the ORM itself costs, everything on top of what the driver would have spent anyway. The two ref rows are the floors: hand-written SQL with the rows mapped by hand, which is what an ORM has to earn its keep against. Bun SQL entries are measured against bun sql and the rest against raw pg, so a fast driver is never counted as the ORM’s doing.

#	Entry	Adds µs	Total µs
ref	bun sql	floor	1138
ref	raw pg	floor	1181
1	UQL (bunSql)	+247	1385
1	UQL	+275	1456
3	Drizzle (bunSql)	+385	1523
3	Drizzle	+419	1600
5	TypeORM	+544	1725
6	Sequelize	+875	2056
6	Prisma	+929	2110
8	MikroORM	+1571	2752

Entries share a place when their confidence intervals overlap: an equal number means a difference this run cannot resolve, not a tie broken in someone’s favour.

Totals only span 2.0x, because every entry pays the same database cost. What the ORM itself adds spans 6x: 247µs for UQL (bunSql), 1571µs for MikroORM.

Each entry is measured against its own driver’s floor, so a faster driver is never counted as the ORM’s win. Running the same UQL code on Bun SQL instead of pg saves 71µs, but only 28µs of that is UQL: the other 43µs is the gap between the two floors, free to anything on that driver.

Per step

The three steps where how much data is bound and hydrated decides the number. The interactive charts break down every step.

Entry (µs)	insert	read	nested	Total, 7 steps
bun sql	357	181	194	1138
raw pg	346	206	219	1181
UQL (bunSql)	376	224	318	1385
UQL	380	259	352	1456
Drizzle (bunSql)	427	241	362	1523
Drizzle	433	267	408	1600
TypeORM	485	340	344	1725
Sequelize	485	396	546	2056
Prisma	892	287	396	2110
MikroORM	463	744	882	2752

Columns: insert is INSERT 10 rows, returning ids; read is SELECT with WHERE, SORT, LIMIT 200; nested is SELECT 50 parents with their children. The biggest gap is Prisma’s insert: 892µs against 376-485µs for everyone else. The other 4 steps are asserted every round but not published: they are round trips with almost nothing in them, worth 465-663µs of each total and separating the field by at most 110µs.

Three runtimes

The same lifecycle runs on Bun, Node and Deno, from one bundle built by Bun so the runtime is the only variable. The Bun SQL rows sit out here, since that client is a Bun API.

Bun 1.4.2, Node 24.20.0, Deno 2.9.6, all running the same bundled JavaScript, one at a time against the same database. PostgreSQL 18.6 (Homebrew), Apple M4 Max, September 2026. µs for a whole lifecycle, nearest-rank percentiles over 2000 rounds after 250 warmup, so a p99 is drawn from the 21 slowest rounds.

Entry (µs)	Bun p50	Bun p99	Node p50	Node p99	Deno p50	Deno p99
raw pg	1183	3940	1250	3765	1276	3860
UQL	1486	5178	1553	3766	1540	4588
Drizzle	1612	6217	1804	4803	1808	4771
TypeORM	1661	6180	1853	4643	1750	4772
Sequelize	1966	7426	2202	5763	2214	5457
Prisma	2073	8038	2325	6224	2488	6487
MikroORM	2712	11011	3785	9103	3787	8483

On raw pg, the same code on all of them, the runtimes are 93µs apart at p50 but 175µs apart at p99: Bun leads the median, Node the tail, and each p99 is 233% on Bun, 201% on Node, 203% on Deno above its own p50. Switching runtime moves any single entry by at most 1075µs at p50 (MikroORM), where switching ORM on one runtime moves it 1191-2223µs. Both are differences of measured medians, known to ±38µs and ±39µs, so read them as ranges rather than as a ranking. The one pair that changes places between runtimes is Drizzle and TypeORM, 41µs apart.

Memory

The same lifecycle weighed for what it allocates, on Node, one process per entry. Adds KB is the heap above the hand-written floor, per request.

PostgreSQL 18.6 (Homebrew), Node 24.20.0, Apple M4 Max, September 2026. Median KB allocated per step over 60 rounds after 60 warmup of a 7-step lifecycle. Rounds a garbage collection ran in are discarded, never corrected, and no entry lost more than 1% of its own (MikroORM).

Entry	insert	read	nested	Total KB	Adds KB
raw pg	14	87	106	245	floor
UQL	44	105	82	320	+75
Drizzle	134	248	238	751	+506
Prisma	273	220	374	1055	+810
TypeORM	126	295	503	1066	+821
Sequelize	100	425	592	1295	+1050
MikroORM	77	1470	2071	3877	+3632

Above the floor the field spans 48.4x: 75KB for UQL, 3632KB for MikroORM, and nested opens it widest: MikroORM’s 2071KB against UQL’s 82KB.

Almost none of it survives: another 60 lifecycles, collected either side, leave at most 31KB behind (Sequelize), identity maps included. What the table prices is collector pressure, not a resident set that grows.

Type safety

The same benchmark writes ordinary mistakes in each tool’s own API (a misspelled column in a projection, a filter on a column that is not there, a text operator on a number, a sum over a text column, a read of a column the projection left out) and reports which ones the compiler refuses. Each file is compiled twice, once as written and once with every mistake corrected, so a green mark means the mistake errored and the correction was clean.

Checked with TypeScript 7.0.2, 11 probes per entry.

Mistake	Drizzle	MikroORM	Prisma	Sequelize	TypeORM	UQL
Misspelled column in the projection	✅	✅	❌	❌	✅	✅
Misspelled column in the filter	✅	✅	✅	✅	✅	✅
String value against a numeric column	✅	✅	✅	❌	✅	✅
Text operator against a numeric column	❌	❌	✅	✅	✅	✅
Misspelled column in the sort	✅	✅	✅	❌	✅	✅
Sum over a text column	❌	❌	✅	❌	✅	✅
Misspelled column inside a loaded relation	✅	✅	✅	❌	✅	✅
Misspelled column in inserted data	✅	✅	✅	✅	✅	✅
Number written into a text column	✅	✅	✅	✅	✅	✅
Reading a column the projection left out	✅	✅	✅	❌	❌	✅
Reading a misspelled column off a loaded relation	✅	✅	✅	✅	✅	✅
Caught, of 11	9	9	10	5	10	11

UQL catches 11 of the 11, Sequelize 5. Every mistake here is caught by at least one entry. The corrected copy of every file compiles clean, which is what makes a red mark a missing check rather than a broken query.

The columns are alphabetical, not ranked: a handful of probes cannot separate these tools the way a microsecond can, and ties are common. The queries behind each mark are in the benchmark.

Why UQL is fast

• Schema metadata is worked out once at startup, so nothing is looked up while a query runs.
• SQL is written straight into a string buffer, with no intermediate builder objects.

Method

• Everyone defines the same Company and User, runs the same seven steps through its own idiomatic API, and gets one connection with no pooling. Entries are interleaved and rotated, so none of them keeps a favourable position.
• Every step asserts on the rows it returns, so a step that silently does nothing fails instead of scoring well.
• Medians, never means, so one GC pause cannot dominate a number, and each carries the 95% confidence interval the caption above states. Places are assigned over those intervals, so entries the run cannot separate share one instead of being ordered by noise.
• The runtime figures come from one Bun-built bundle run on each runtime in turn, so no runtime is charged for its own TypeScript loader. The memory figures come from a process per entry, since a shared heap cannot be attributed.
• The type-safety probes are compiled with TypeScript 7.0.2 at strict, against the same entity definitions the timed lifecycle queries: one definition per ORM, scored and measured, so neither half is judged on a model the other never used.

git clone https://github.com/rogerpadilla/ts-orm-benchmark.git
cd ts-orm-benchmark
bun install

DATABASE_URL=postgres:///postgres bun run bench
DATABASE_URL=postgres:///postgres bun run bench.runtimes
DATABASE_URL=postgres:///postgres bun run bench.memory
bun run bench.types

---

Speed is only one axis. For how the APIs and features line up, see the comparison.

ComparisonDrizzle vs MikroORM vs Prisma vs TypeORM vs UQL, with actual code for every common operation.

---

Try it

npm install uql-orm

Entities are plain classes and queries are plain JSON: nothing to generate, and no schema file to keep in sync.

Quick Start GitHub

---