# SqlSugar: the .NET ORM that speaks twenty databases

> SqlSugar is an MIT-licensed .NET ORM maintained by the Fructose Big Data Technology team, spanning MySQL, SQL Server, PostgreSQL, ClickHouse, DuckDB and a long list of Chinese domestic databases. It targets .NET Framework through .NET 10, with AOT support and multi-tenant features built in.

**DotNetNext/SqlSugar** — .Net aot ORM   SqlServer ORM Mongodb ORM MySql  瀚高 Postgresql ORM  DB2 Hana 高斯 Duckdb C# VB.NET Sqlite  ORM Oracle ORM Mysql Orm 虚谷数据库 达梦 ORM 人大金仓 ORM 神通ORM  C# ORM , C# ORM .NET ORM NET9 ORM .NET8 ORM ClickHouse ORM QuestDb ,TDengine ORM,OceanBase ORM,GaussDB ORM,Tidb ORM Object/Relational Mapping

- Repository: https://github.com/DotNetNext/SqlSugar
- Website: https://www.donet5.com/Home/Doc
- Stars: 5,837 · Forks: 1,391
- Language: C#
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/dotnetnext-sqlsugar

## An ORM whose selling point is the database list

SqlSugar introduces itself as a .NET open source ORM framework, maintained and updated by the Fructose Big Data Technology team, calling itself the most easy-to-use ORM out of the box, and its differentiator is breadth: the supported list runs from MySql, SqlServer, Sqlite, Oracle and PostgreSQL through analytics stores like ClickHouse, DuckDB, TDengine and QuestDb, to cloud MySQL variants on Amazon, Azure and Google Cloud. Unusually for a Western reader, the list also names a large set of Chinese domestic databases, Dameng, Kingbase, which the README marks as domestically recommended, Shentong, HighGo, GBase and Huawei GaussDB, plus Odbc and a custom database escape hatch. The framework covers .NET Framework and .NET Core 3.1 through .NET 10, and the repository description leads with AOT support, so native compilation is a stated target rather than an accident.

## Queryable joins that show you their SQL

The first documented feature is the join syntax, a fluent chain over Queryable with typed lambda join conditions:

```cs
var query  = db.Queryable<Order>()
            .LeftJoin<Custom>  ((o, cus) => o.CustomId == cus.Id)
            .LeftJoin<OrderItem> ((o, cus, oritem ) => o.Id == oritem.OrderId)
            .LeftJoin<OrderItem> ((o, cus, oritem , oritem2) => o.Id == oritem2.OrderId)
            .Where(o => o.Id == 1)
            .Select((o, cus) => new ViewOrder { Id = o.Id, CustomName = cus.Name })
            .ToList();
```

The README then shows the generated SQL, left joins resolved to ON clauses and the parameterized WHERE, which is the right documentation instinct for an ORM: developers evaluating it can read exactly what their expression becomes rather than trusting a black box. A Where on the identifier compiles to a parameter @Id0, not string concatenation, which answers the first question anyone writes about a query builder.

## Includes, paging and expressions built in loops

Navigation properties load through Includes, with multi-level chains supported in one call, x.Provinces, x.Citys, x.Street in the documentation's example, and combinable with explicit joins in the same query. Paging is a single method with the count returned by reference:

```cs
 int pageIndex = 1;
 int pageSize = 20;
 int totalCount=0;
 var page = db.Queryable<Student>().ToPageList(pageIndex, pageSize, ref totalCount);
```

For conditions assembled at runtime, Expressionable composes predicates in a loop:

```cs
var names= new string [] { "a","b"};
Expressionable<Order> exp = new Expressionable<Order>();
foreach (var item in names)
{
    exp.Or(it => it.Name.Contains(item.ToString()));
}
var list= db.Queryable<Order>().Where(exp.ToExpression()).ToList();
```

The README again pairs this with its generated SQL, OR-ed LIKE clauses with cast parameters, which is the shape search filters actually need and the shape hand-written OR trees usually get wrong.

## Multi-tenancy from the connection config up

The multi-tenant story starts at construction, where one SqlSugarClient accepts a list of ConnectionConfig entries, each with a ConfigId naming a database:

```cs
SqlSugarClient db = new SqlSugarClient(new List<ConnectionConfig>()
{
    new ConnectionConfig(){ ConfigId="0", DbType=DbType.SqlServer,  ConnectionString=Config.ConnectionString, IsAutoCloseConnection=true },
    new ConnectionConfig(){ ConfigId="1", DbType=DbType.MySql, ConnectionString=Config.ConnectionString4 ,IsAutoCloseConnection=true}
});

var mysqldb = db.GetConnection("1");//mysql db
var sqlServerdb = db.GetConnection("0");// sqlserver db

db.BeginTran();
```

Connections are retrieved by id, and a transaction begun on the client spans inserts across the MySQL and SQL Server connections in the documented example, a cross-database unit of work. The description rounds this out with the SAAS feature set: cross-database query, audit, tenant sub-database, tenant sub-table and tenant data isolation, meaning the multi-database breadth is aimed at hosted multi-tenant products, not just at portability.

## SqlSugarScope, AOP hooks and global query filters

For the lifetime question, the documentation shows a singleton pattern built on SqlSugarScope, configured once with an AOP hook attached:

```cs
public static SqlSugarScope Db = new SqlSugarScope(new ConnectionConfig()
 {
            DbType = SqlSugar.DbType.SqlServer,
            ConnectionString = Config.ConnectionString,
            IsAutoCloseConnection = true
  },
  db=> {
            db.Aop.OnLogExecuting = (s, p) =>
            {
                Console.WriteLine(s);
            };
 });
```

OnLogExecuting surfaces every executed statement, SQL and parameters, to any callback, which is the observability hook production systems need. Transactions can then span methods, with UseTran wrapping inserts that live in different classes. Global query filters complete the picture: db.QueryFilter.Add(new TableFilterItem<Order>(it => it.Name.Contains("a"))) applies a predicate to every subsequent query on Order, the mechanism soft deletes and tenant scoping are typically built on. ValueObject, discriminator, repository, UnitOfWork, DbContext and AOP support are all claimed in the description.

## Zero-SQL schema work and big-data claims

The description's headline claims are about doing without SQL entirely: zero SQL ORM table building, with indexes and full CRUD supported, dynamic class building and dynamic table building for workflow-driven applications, non-entity multi-database CRUD, JSON to SQL and custom XML mapping. On volume, the README claims support for .NET big-data writes and updates in the millions, table sharding, and mature solutions for query statistics at billions of rows, language that positions the ORM for operational Chinese-scale systems rather than CRUD utilities. Low code plus workflow is an explicit target, the dynamic everything stack, which explains why the feature list feels broader than a typical mapper: SqlSugar aims to be the data layer under generated applications, where schemas arrive at runtime.

## A wiki, a Chinese site, and tags that lag the code

Documentation is split deliberately: a GitHub wiki holds the English operation guides, query, join, include, insert, update and delete each with a dynamic-variant page, plus a Nuget page for installation, while the Chinese documentation lives at donet5.com with the README offering a language toggle. Release tags tell a quieter story: the newest is 5.1.4.197 from 2025-07-06, after 5.1.4.187 in March 2025 and 5.1.4.167 in August 2024, yet the repository's last push was 2026-09-13, so development continues well past the tag cadence and package versions move through NuGet independently of GitHub releases. The license is MIT, the source lives under Src/, and against Dapper, the widely used .NET micro-ORM, the difference is direction: Dapper maps SQL you write, while SqlSugar generates SQL from expressions and manages schema alongside queries.

## Conclusion

Choose SqlSugar when one codebase must talk to many databases, especially mixes that include Chinese domestic engines alongside mainstream ones, or when tenant isolation and cross-database transactions are requirements rather than afterthoughts. Prefer Dapper when you want to write the SQL yourself and only need mapping, or Entity Framework when its model-first workflow fits your team. Verify first that your exact database and .NET generation, Framework, Core 3.1 or net5 through net10, are covered in the current documentation, and read the wiki's Nuget page for the right package variant.

## FAQ

### What is SqlSugar?

SqlSugar is a free, MIT-licensed open source ORM framework for .NET, maintained by the Fructose Big Data Technology team. It supports more than twenty databases, from MySQL and SQL Server to ClickHouse and several Chinese domestic databases, across .NET Framework through .NET 10.

### Which databases does SqlSugar support?

The documented list includes MySql, SqlServer, Sqlite, Oracle, PostgreSQL, MongoDB, DuckDB, Hana, OceanBase, TDengine, QuestDb, ClickHouse, GaussDB, GBase, MariaDB, TiDB, DB2, Access, Percona and cloud MySQL services, plus Chinese databases such as Dameng, Kingbase, Shentong and HighGo, and custom database support.

### How do you install SqlSugar?

Installation is through NuGet, with a dedicated Nuget page in the project wiki. Documentation spans the GitHub wiki for the English guides and the Chinese-language site at donet5.com, starting from the wiki's start guide page.

## Sources

- [DotNetNext/SqlSugar on GitHub](https://github.com/DotNetNext/SqlSugar)
- [License: MIT](https://github.com/DotNetNext/SqlSugar/blob/master/LICENSE)
- [Project website](https://www.donet5.com/Home/Doc)
- [README](https://github.com/DotNetNext/SqlSugar/blob/master/README.md)
- [Releases](https://github.com/DotNetNext/SqlSugar/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dotnetnext-sqlsugar