v8.1 is out · NativeAOT ready

Feather-light, lightning-fast

LiteOrm is a lightweight, high-performance .NET ORM framework—the execution speed of a micro ORM with the ergonomics of a full ORM. Built for workloads that are performance sensitive but still need to handle complex SQL.

dotnet add package LiteOrm
178msInsert 10k rows
1/3Of the peer average allocation
11Database dialects
AOTNativeAOT / Trim compatible
.NET 8+Also targets Framework 4.6.1+
Features

Why LiteOrm

The execution speed of a micro ORM with the ergonomics of a full ORM—without hiding SQL, and without forcing you to hand-write it.

Blazing fast

Performance close to raw Dapper and far ahead of EF Core. Bulk insert, update and association queries all lead the field, with the smallest allocation footprint.

Three query styles

Lambda, Expr and ExprString mix freely: strongly typed filters, dynamically built conditions, and hand-written SQL fragments at the DAO layer—each used where it fits.

Automatic associations

Declare relations with [ForeignType] / [TableJoin]—no hand-written JOINs—and filter by a related table in one call with ExistsRelated.

Declarative transactions

The [Transaction] attribute brings AOP transaction management with nesting and rollback, leaving business code untouched.

11 database dialects

SQL Server, MySQL, Oracle, PostgreSQL and SQLite, plus built-in support for the domestic databases DM, KingbaseES, GaussDB, OceanBase, TiDB and GreatDB.

Sharding and read/write splitting

The IArged interface routes sharded tables, while multiple data sources and read-only replicas work out of the box—covering the everyday needs of mid-size and large systems.

Query

One query, three ways

All three produce parameterized SQL. Lambda reads best, Expr suits dynamic composition, and ExprString is there for the DAO layer when you need precise control over the SQL.

// Write queries the way you write C#: strongly typed, highly readable
var users = await userService.SearchAsync(
    u => u.Age >= 18 && u.UserName!.StartsWith("A"));

// Sorting + paging
var page = await userService.SearchAsync(
    q => q.Where(u => u.Age >= 18)
          .OrderByDescending(u => u.CreateTime)
          .Skip(20).Take(10));
// Compose conditions dynamically: ideal for query builders and admin filters
using static LiteOrm.Common.Expr;

var expr = (Prop("Age") >= 18)
          & Prop("UserName").StartsWith("A");
var users = await userService.SearchAsync(expr);

// Conditions serialize to JSON, so they travel across layers or come straight from the client
string json = expr.ToJson();
// Interpolated strings for hand-written SQL fragments, DAO layer only
using static LiteOrm.Common.Expr;

int minAge = 18;
var users = await userViewDAO.Search(
    $"WHERE {Prop("Age")} > {minAge}")
    .ToListAsync();

// Interpolated values are parameterized automatically: flexible and safe

The service layer exposes Lambda / Expr entry points plus SearchAs projection queries; the DAO layer additionally opens up ExprString, DataTable queries and other low-level capabilities. See the query overview.

Benchmark

Let the data speak

.NET 10.0.11 · MySQL · BenchmarkDotNet MediumRun. Times below are for a 10,000-row batch.

FrameworkInsertUpdateUpsertAssociation query
LiteOrm178.12 ms280.36 ms247.92 ms78.65 ms
Dapper266.28 ms355.83 ms327.69 ms98.68 ms
FreeSql332.71 ms570.89 ms257.39 ms101.45 ms
SqlSugar352.86 ms734.61 ms7042.44 ms179.25 ms
EF Core1837.48 ms1374.47 ms1538.52 ms162.80 ms

Test environment: Linux Ubuntu 24.04.4 LTS · Intel Xeon Silver 4314 2.40GHz · asynchronous bulk operations. Full report in LiteOrm.Benchmark.

Memory allocation (1,000 rows, KB)

Total allocations for insert / update / upsert / association query. The leanest allocator means lower GC pressure and steadier latency.

LiteOrm
6,431
Dapper
18,365
FreeSql
32,912
SqlSugar
74,954
EF Core
90,752

Definition: total allocation of insert / update / upsert / association query (1,000-row batch), measured by LiteOrm.Benchmark. See the performance report.

Databases

Broad database support

One entity mapping covers both mainstream and domestic databases. Domestic dialects are detected and matched with priority—no extra configuration.

SQL Server2012+
MySQL8.0+
Oracle12c+
PostgreSQL—
SQLite—
DM (Dameng)Oracle compatible
KingbaseESPostgreSQL compatible
GaussDBopenGauss family
OceanBaseMySQL compatible
TiDBMySQL compatible
GreatDBMySQL compatible

Domestic and compatible builders extend the mainstream dialects and override only the differences. Older database versions can be supported through custom paging and a custom SqlBuilder. See the database compatibility notes.

Documentation

Docs organized by learning path

From first steps to production, every scenario ships copy-paste-ready code. Bilingual and AI friendly.