Benchmarks

Dapper-class. AOT-native. Zero ceremony.

Socigy.OpenSource.DB is a source-generated data layer — your queries become real C# at compile time, so there's no reflection, no runtime IL emit, and nothing to warm up. The result is performance that matches hand-written Dapper, with a fully typed API.

The headline, in three numbers (PostgreSQL, .NET 10, 1 000-row read)

• ⚡ Matches hand-written Dapper on speed (statistically tied at every size) — with a fully typed API instead of hand-written SQL.
• 🪶 ~120 KB allocated — on par with hand-written ADO.NET, 1.6× less than Dapper, and up to 8× less than EF Core.
• 🚀 Runs under NativeAOT with no performance penalty — something Dapper and EF Core cannot do at all.

You get the ergonomics of an ORM, micro-ORM-class speed, lower read allocations than Dapper, far less memory than EF Core, and the only typed query layer that survives a NativeAOT publish.

Why it's fast

Column ordinals are resolved once per result set and values are read with the allocation-free GetFieldValue<T>, so materialization is as lean as a hand-written reader loop — by ordinal, no boxing. Predicates are translated to SQL once per query shape and cached, so repeat calls skip translation entirely and just re-bind the parameter values — no per-call reflection or string building. (That first-time translation costs ~450 ns; after that the shape is served from cache.)

The numbers

Environment: BenchmarkDotNet v0.15.8 · Intel Core Ultra 9 275HX · Windows 11 · .NET 10.0.8. Each call opens a pooled connection (a realistic per-request pattern), so connection acquisition is part of every measurement. Run them yourself (below) for figures on your own hardware.

How to read these tables: the best result per metric in each group is highlighted in green (lower is better — less time, less memory), Socigy's own rows are tinted, and the bars show relative cost within a group. Within noise means two results' 99.9% confidence intervals overlap — the gap is smaller than normal run-to-run variance, so neither is reliably faster.

Reads — typed `Query`, vs Dapper & EF Core

Socigy matches Dapper on speed — and beats it on memory. Queries are translated once and cached per shape, so typed Query lands within ~3% of hand-written Dapper at every size (their confidence intervals overlap — a statistical tie). It also allocates less than Dapper throughout — at 1 000 rows 122 KB vs Dapper's 199 KB (1.6× less), and 8× less than EF Core tracking's 979 KB — while running up to 1.9× faster than EF Core.

Reads — `.sql` procedure, vs Dapper & EF Core

A fixed-SQL Socigy procedure (no LINQ translation at all) against Dapper raw SQL and EF Core FromSqlRaw.

Within ~3–9% of Dapper, and well ahead of EF Core — at the same allocation as the cached typed Query (≈121 KB at 1 000 rows) and ~3× lighter than EF's FromSqlRaw.

Writes — INSERT, vs Dapper & EF Core

Single-row writes are dominated by the database commit (fsync), so times are close and noisy — Socigy and Dapper are tied within noise. Socigy's insert builder caches its statement and column plan, so it allocates just 4.2 KB — a hair above Dapper's 3.7 KB and ~16× less than EF Core's 66 KB.

Writes — bulk INSERT (`InsertMultipleAsync`), vs a per-row loop, Dapper & EF Core

InsertMultipleAsync batches a whole collection into one multi-row INSERT … VALUES (…),(…) command (auto-chunked under PostgreSQL's 65,535-parameter limit) instead of a command per row.

Batched multi-row INSERT is in a different league. Because the whole batch becomes a single command, InsertMultipleAsync is 10–40× faster than a per-row loop and far ahead of anything that issues one command per row — Dapper's ExecuteAsync over a list does exactly that (N round-trips), landing ~50–230× slower. EF Core batches its inserts so it stays within 2–4×, but allocates ~5× more (707 KB / 6.3 MB vs Socigy's 136 KB / 1.4 MB). Socigy is both the fastest and the leanest at every size.

Writes — UPDATE (by primary key), vs Dapper & EF Core

Dead-even with Dapper, both fsync-bound; EF Core trails slightly and allocates ~10× more.

NativeAOT: the one nobody else can match 🚀

Publish your app with NativeAOT and Socigy just works — and runs as fast as it does under the JIT:

Allocations are identical across JIT and NativeAOT (≈122 KB at 1 000 rows). The parity is no accident: materialization is entirely source-generated, so there's no runtime codegen to fall back to an interpreter.

And here's the floor — under NativeAOT, Socigy against a hand-written, ordinal-based ADO.NET reader loop (GetInt32/GetGuid by ordinal, no abstraction). This is as fast as managed data access gets:

Raw ADO.NET is the theoretical floor — fastest on every row (the green cells) — yet Socigy stays within ~9% of it while giving you a fully typed API, and matches it on allocations at scale (≈121 KB vs 120 KB at 1 000 rows; the per-row gap is essentially gone).

No other typed library even gets to play this game — the alternatives don't run under NativeAOT at all:

In an AOT-published service, Socigy is the typed data layer — because it's the only one that boots.

Run it yourself

Don't take our word for it — every number above is reproducible in minutes.

1. Prerequisites

• .NET 10 SDK (dotnet --version ≥ 10).
• A PostgreSQL instance for every suite except ParseBenchmarks.
• NativeAOT only: a C/C++ toolchain for the native link step — on Windows the Desktop development with C++ workload (or Build Tools); on Linux clang + zlib. See the NativeAOT prerequisites. BenchmarkDotNet pulls the Microsoft.DotNet.ILCompiler package automatically.

2. Start a PostgreSQL (example: Docker)

3. Point the benchmarks at it

The connection string is read from the BENCH_DB environment variable; if unset it defaults to Host=localhost;Port=5432;Username=postgres;Password=1234;Database=postgres.

The bench_users (1000 rows) and bench_writes tables are created and seeded automatically on the first run — no manual SQL needed.

4. Run a suite (Release only)

5. Run the NativeAOT comparison

Publishes a native build per benchmark and runs the suites under JIT and NativeAOT side by side (Socigy vs raw ADO.NET):

6. Find the results

BenchmarkDotNet prints a summary table and writes report files to BenchmarkResults/results/ next to the project — GitHub-flavoured Markdown (*-report-github.md), JSON (*-report-full.json), CSV and HTML.