The .NET data access framework built for the people who actually understand databases.
Most .NET data access tools were built by developers, for developers. They start at the object model and work toward the database. The connection is an afterthought. The pool is someone else’s problem. Isolation levels are passed through and hoped for. Session settings drift. Connection storms happen. The DBA gets paged at 2am and the framework shrugs.
pengdows.crud was built from the other direction.
It starts at the connection. Connection governance, pool protection, read/write lane separation, session conformance, dialect correctness, isolation level honesty — those are the foundation. The mapping, the SQL generation, the batch operations, the audit handling — those are built on top of a foundation that actually respects the database.
For DBAs
If you’ve spent years cleaning up the messes that application frameworks make — you know what we’re talking about.
pengdows.crud is the framework you can approve and enforce. It governs connections so application developers can’t exhaust your pool. It applies session settings correctly on every checkout so pooled connections don’t drift. It enforces read-only intent at the connection string and session level. It generates dialect-correct SQL for your specific database — not generic SQL that happens to work most of the time. It separates business keys from surrogate keys the way you designed the schema, not the way an ORM wants to think about it.
It supports 13 databases. Each tenant in a multi-tenant deployment can be on a completely different database engine — Oracle, PostgreSQL, SQL Server, SQLite — governed correctly, all from the same application.
You can enforce it organizationally. That’s by design.
pengdows.poco.mint — The schema is the source of truth
pengdows.crud does not do migrations. Your DBA tuned the database. Your DBA designed the indexes, the constraints, the keys, the schema. That work belongs to the DBA, not to a code-first model in your application.
pengdows.poco.mint manifests that source of truth into C#. Point it at your database and it generates correctly attributed entity classes — [Table], [Column], [Id], [PrimaryKey], [Version], audit fields — reflecting exactly what the database already is. Not what your application thinks it should be.
The database drives the code. Not the other way around.
mint ships in two flavors:
CLI — for developers and CI/CD pipelines. Regenerate entities when the schema changes. Schema drift becomes a build-time concern, not a runtime surprise.
WebUX — a self-contained Docker container. No installs. No SDK. No toolchain. Nothing on your machine that wasn’t there before. Spin it up, point it at your database, choose your tables, download your entities, shut it down. That’s it.
DBAs don’t need a developer to get started. The generated entities are correct, attributed, and ready to use.
For Developers
pengdows.crud is not an ORM. It does not hide SQL, generate migrations, or track object state.
You write SQL. The framework makes sure it runs correctly — with the right parameter syntax, the right identifier quoting, the right session settings, on the right connection from the right pool. You get strongly-typed entity mapping, compiled expression tree hydration, batch operations with automatic chunking, streaming for large result sets, optimistic concurrency, full audit field support, and a testing infrastructure that lets you run your entire test suite without a real database.
You also get DataReaderMapper — map any SQL result to any POCO, no entity model required. Reporting queries, projections, stored procedure results — all map cleanly with the same compiled expression tree performance.
Not EF Core. Not Dapper.
EF Core starts at the object model. It cannot get to where pengdows.crud is without being rebuilt from scratch. The connection governance, the pool governor, the per-tenant engine diversity, the portable isolation profiles — those require owning the connection layer. EF Core doesn’t own it.
Dapper is a mapper. It does one thing well. You hand it a connection and it maps the result. It has no opinion about connections, pooling, sessions, dialects, or concurrency. pengdows.crud does everything Dapper does plus owns the entire connection lifecycle correctly. On PostgreSQL reads it’s faster than Dapper — because auto-prepare is baked in. On SQLite it costs ~12 microseconds per operation for the governance layer — a cost that disappears at network latency.
The honest comparison: Dapper is a tool. EF Core is an abstraction. pengdows.crud is infrastructure.
Zero external dependencies. .NET 8+. MIT licensed.
- GitHub
pengdows.crudon NuGetpengdows.crud.abstractionson NuGetpengdows.crud.fakeDbon NuGetpengdows.stormgateon NuGet