Skip to content

Commit c4d3715

Browse files
github-actions[bot]github-actions[bot]
committed
docs: sync from coderbuzz/codex@8854676
1 parent 71f1a1a commit c4d3715

2 files changed

Lines changed: 23 additions & 25 deletions

File tree

‎AI_KNOWLEDGE.md‎

Lines changed: 11 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- docs: sync from coderbuzz/codex@1d1cd61 -->
1+
<!-- docs: sync from coderbuzz/codex@8854676 -->
22

33
# @coderbuzz/sql: AI Expert Knowledge Reference
44

@@ -1787,21 +1787,19 @@ The peers are optional through `peerDependenciesMeta`. Published versions up to
17871787

17881788
## 30. Benchmarks
17891789

1790-
Machine-readable source of truth: `https://raw.githubusercontent.com/coderbuzz/benchmarks/main/results/latest.json` (each entry has `winner`, `factorVsNext`, `higherIsBetter`). Quote numbers from there, not from memory.
1790+
Machine-readable source of truth: `https://raw.githubusercontent.com/coderbuzz/benchmarks/main/results/latest.json` (suite ids `sql-simple`, `sql-join`, `sql-insert`, `sql-batch`, `sql-cte`, `sql-10-conditions`; each entry has `winner`, `factorVsNext`, `factorVsBest`, `higherIsBetter`). Quote numbers from there, not from memory, and not from the in-repo suites, which are for A/B runs between versions only.
17911791

1792-
Full results at **[github.com/coderbuzz/benchmarks](https://github.com/coderbuzz/benchmarks)**.
1793-
1794-
SQL query compilation throughput on Apple M-series, Bun runtime. Higher is better.
1792+
Numbers from [github.com/coderbuzz/benchmarks](https://github.com/coderbuzz/benchmarks) (`results/latest.json`): cloud reference machine (Intel Xeon @ 2.10GHz, CPU model 207, 4 cores, Linux x64), Bun 1.4.2, run of 2026-10-10 (benchmarks `131fcc5`). @coderbuzz/sql 0.9.6 against Kysely 0.29.6 and Drizzle ORM 0.45.3; query **compilation** throughput only (building the SQL string, no database round trip), ops/s, best of 3 processes, higher is better.
17951793

17961794
| Scenario | @coderbuzz/sql | Kysely | Factor vs Kysely | Drizzle ORM | Factor vs Drizzle |
17971795
|---|---|---|---|---|---|
1798-
| SELECT simple | **1,700,391 ops/s** | 561,869 | **3.0x** | 34,239 | **49.7x** |
1799-
| SELECT JOIN (2 tables) | **2,208,322 ops/s** | 310,690 | **7.1x** | 16,801 | **131.4x** |
1800-
| INSERT single row | **2,954,261 ops/s** | 393,159 | **7.5x** | 55,085 | **53.6x** |
1801-
| INSERT batch 100 rows | **134,187 ops/s** | 17,634 | **7.6x** | 914 | **146.8x** |
1802-
| CTE (WITH clause) | **831,703 ops/s** | 224,893 | **3.7x** | 12,222 | **68.0x** |
1803-
| 10 nested WHERE conditions | **656,309 ops/s** | 117,064 | **5.6x** | 12,692 | **51.7x** |
1796+
| SELECT simple | **1,032,086 ops/s** | 460,788 | **2.2x** | 46,083 | **22.4x** |
1797+
| SELECT JOIN (2 tables) | **539,870 ops/s** | 264,268 | **2.0x** | 19,127 | **28.2x** |
1798+
| INSERT single row | **1,729,852 ops/s** | 292,097 | **5.9x** | 52,251 | **33.1x** |
1799+
| INSERT batch 100 rows | **70,248 ops/s** | 10,878 | **6.5x** | 842 | **83.4x** |
1800+
| CTE (WITH clause) | **366,525 ops/s** | 160,544 | **2.3x** | 41,805 | **8.8x** |
1801+
| 10 nested WHERE conditions | **446,201 ops/s** | 106,321 | **4.2x** | 19,358 | **23.0x** |
18041802

1805-
`@coderbuzz/sql` is 3-8x faster than Kysely and 50-147x faster than Drizzle ORM across every query type. The gap widens with query complexity (batch, JOIN, conditions) due to `@coderbuzz/sql`'s zero-overhead string compilation strategy vs Kysely's AST-based approach and Drizzle's ORM abstraction layer.
1803+
`@coderbuzz/sql` is 2.0-6.5x faster than Kysely and 8.8-83x faster than Drizzle ORM on every query type in the suite. The lead over Kysely is largest on inserts (5.9x single row, 6.5x batch) and many conditions (4.2x), smallest on JOIN and CTE (2.0-2.3x): `@coderbuzz/sql` compiles straight to a string, Kysely builds and walks an AST, Drizzle adds its ORM layer.
18061804

1807-
These measure query **compilation** only (building the SQL string), not database round trips.
1805+
These measure query **compilation** only (building the SQL string), not database round trips. Earlier tables in these docs (Apple M-series, older versions: 3-8x Kysely, 50-147x Drizzle) came from another machine and are superseded; do not quote them.

‎README.md‎

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- docs: sync from coderbuzz/codex@1d1cd61 -->
1+
<!-- docs: sync from coderbuzz/codex@8854676 -->
22

33
# @coderbuzz/sql
44

@@ -71,20 +71,20 @@ This is not an ORM. There are no lazy-loaded relations, no magical `save()` meth
7171

7272
## Benchmarks
7373

74-
Full results at **[github.com/coderbuzz/benchmarks](https://github.com/coderbuzz/benchmarks)**.
75-
76-
SQL query compilation throughput on Apple M-series, Bun runtime. Higher is better.
74+
Numbers from [github.com/coderbuzz/benchmarks](https://github.com/coderbuzz/benchmarks) (`results/latest.json`): cloud reference machine (Intel Xeon @ 2.10GHz, CPU model 207, 4 cores, Linux x64), Bun 1.4.2, run of 2026-10-10 (benchmarks `131fcc5`). @coderbuzz/sql 0.9.6 against Kysely 0.29.6 and Drizzle ORM 0.45.3; query **compilation** throughput only (building the SQL string, no database round trip), ops/s, best of 3 processes, higher is better.
7775

7876
| Scenario | @coderbuzz/sql | Kysely | Factor vs Kysely | Drizzle ORM | Factor vs Drizzle |
7977
|---|---|---|---|---|---|
80-
| SELECT simple | **1,700,391 ops/s** | 561,869 | **3.0x** | 34,239 | **49.7x** |
81-
| SELECT JOIN (2 tables) | **2,208,322 ops/s** | 310,690 | **7.1x** | 16,801 | **131.4x** |
82-
| INSERT single row | **2,954,261 ops/s** | 393,159 | **7.5x** | 55,085 | **53.6x** |
83-
| INSERT batch 100 rows | **134,187 ops/s** | 17,634 | **7.6x** | 914 | **146.8x** |
84-
| CTE (WITH clause) | **831,703 ops/s** | 224,893 | **3.7x** | 12,222 | **68.0x** |
85-
| 10 nested WHERE conditions | **656,309 ops/s** | 117,064 | **5.6x** | 12,692 | **51.7x** |
86-
87-
`@coderbuzz/sql` is 3-8x faster than Kysely and 50-147x faster than Drizzle ORM across every query type. The gap widens with query complexity (batch, JOIN, conditions) due to `@coderbuzz/sql`'s zero-overhead string compilation strategy vs Kysely's AST-based approach and Drizzle's ORM abstraction layer.
78+
| SELECT simple | **1,032,086 ops/s** | 460,788 | **2.2x** | 46,083 | **22.4x** |
79+
| SELECT JOIN (2 tables) | **539,870 ops/s** | 264,268 | **2.0x** | 19,127 | **28.2x** |
80+
| INSERT single row | **1,729,852 ops/s** | 292,097 | **5.9x** | 52,251 | **33.1x** |
81+
| INSERT batch 100 rows | **70,248 ops/s** | 10,878 | **6.5x** | 842 | **83.4x** |
82+
| CTE (WITH clause) | **366,525 ops/s** | 160,544 | **2.3x** | 41,805 | **8.8x** |
83+
| 10 nested WHERE conditions | **446,201 ops/s** | 106,321 | **4.2x** | 19,358 | **23.0x** |
84+
85+
`@coderbuzz/sql` is 2.0-6.5x faster than Kysely and 8.8-83x faster than Drizzle ORM on every query type in the suite. The lead over Kysely is largest on inserts (5.9x single row, 6.5x batch) and many conditions (4.2x), smallest on JOIN and CTE (2.0-2.3x): `@coderbuzz/sql` compiles straight to a string, Kysely builds and walks an AST, Drizzle adds its ORM layer.
86+
87+
> Numbers move with the machine; compare them only within one run. The source of truth is `https://raw.githubusercontent.com/coderbuzz/benchmarks/main/results/latest.json`.
8888
8989
---
9090

0 commit comments

Comments
 (0)