MonOrm

An async ORM for Python and TypeScript with one Rust core. You write the schema once in Prisma syntax. The Rust core plans the SQL and runs it on PostgreSQL or SQLite. Both languages get the same queries, the same migrations and generated, typed models.

Under active development. It works today, and the author runs it in production. It is version 0.1.1: install it with pip install monorm or npm install monorm@npm:@ufstack/monorm. The npm package is @ufstack/monorm for now; always install it under the alias monorm, because the code imports monorm. Other people should not use it in production yet, or do so at their own risk. Evaluate it against your own app before you rely on it.

About 1.97× faster end to end than Django (async), up to 3.55×. Source: the geometric mean of 20 cases in one run on one machine, with the database round trip included (results). Method, limits and the cases where it is not faster: Benchmarks.

The name is MonOrm.

Example

The schema (the same in both languages):

model User {
  id    Int @id @default(autoincrement())
  name  String
  posts Post[]
}
model Post {
  id        Int @id @default(autoincrement())
  title     String
  published Boolean
  author_id Int
  author    User @relation(fields: [author_id], references: [id])
}

Python:

users = await User.objects.filter(User.posts.published).load(User.posts)

TypeScript:

const users = await User.objects.filter(User.posts.published).load(User.posts);

Both examples run as they are: examples/quickstart (in-memory SQLite).

Why

One ORM for every language

You want to move your web server to another language, but you do not want to learn a new data stack. Many libraries already work this way: one Rust core with a package for each language, for example OpenDAL for file storage. MonOrm does the same for the database layer. The schema, the migrations, the query API and the behavior are the same in Python and TypeScript, because one Rust engine does the work for both. A team can keep one schema when it adds a second service in another language, or when it moves from one language to the other.

The Rust core is not tied to Python and TypeScript. Any language that can call native code can get a MonOrm package with the same schema, migrations and query API. Contributors can add a language: see language-bindings.md.

All of SQL, in the ORM

An ORM should not stop you from doing what SQL can do. With MonOrm you write less raw SQL and install fewer separate packages. These come with the ORM:

• Queries: window functions, CTEs (also recursive), subqueries and EXISTS, aggregates over relations, full-text search, JSON and array columns, cursor pagination.
• Writes: upsert (ON CONFLICT), bulk insert, bulk update, update and delete with RETURNING.
• Schema: check and exclusion constraints, partial and non-btree indexes, triggers and SQL functions, declarative partitions, all with migrations.
• Operations: row and advisory locks, read replicas, tenants with row-level security, N+1 detection, query hooks and OpenTelemetry.
• Raw SQL is still there when you need it.

Some features are PostgreSQL only; schema.md lists the SQLite limits.

Django packages, built in

In Django, many of these features come from separate packages. In MonOrm they are part of the ORM or a built-in extension:

Familiar design

• The schema language is Prisma's. One schema.prisma file, with the editor tooling that already exists (docs).
• The model API is Django-style. Model.objects, filter(), load() and migrations that come from the schema.
• Typed expressions in the style of SQLAlchemy, and generated typed models (docs).

Inspired by

Thank you to the projects below. We claim only what we took from each.

• Robyn: a Python surface with the hot path in Rust through PyO3. We use the same split for the database layer.
• Prisma: the schema-first idea and the schema.prisma language. MonOrm is independent of Prisma (details). It is not a drop-in replacement for Prisma Client, and its query API is its own.
• Django: the model API (Model.objects, querysets) and migrations from the schema (monorm makemigrations, monorm migrate, see schema.md).

Quickstart

There is one package for each registry:

pip install monorm      # the engine, every built-in extension and the auth app; `python -m monorm generate`
npm install monorm@npm:@ufstack/monorm      # the same for Node and Bun (the alias is required); `npx monorm generate`

The monorm command line comes with the Python and npm packages. Both packages hold PostgreSQL and SQLite. They build for 4 platforms: Linux x86-64, Linux arm64, macOS arm64 and Windows x86-64. An extension that is not built in is a separate package that you install next to monorm (optional-packaging.md).

To build from source:

uv venv .venv && . .venv/bin/activate
uv pip install maturin
python languages/python/packaging/stage.py   # the extension libraries of this platform
maturin develop                              # the one monorm package
python examples/quickstart/quickstart.py     # Python 3.11 or later

cd languages/js && npm install && npm run assemble
cd ../../examples/quickstart && npm install && node quickstart.ts   # Node 23.6 or later

Upgrade from the split packages

Before v0.1.0 the project had a thin monorm package, a native package for each profile and one package for each extension. Remove them, then install monorm:

pip uninstall monorm-native-postgres monorm-native-sqlite monorm-native-combined monorm-native-tooling \
  monorm-timestamps monorm-soft-delete monorm-locking monorm-inherit monorm-query-defaults \
  monorm-generic monorm-proxy monorm-composition monorm-file-storage monorm-auth
pip install monorm
npm uninstall @ufstack/monorm @ufstack/monorm-native-postgres @ufstack/monorm-native-sqlite @ufstack/monorm-native-combined @ufstack/monorm-native-tooling @ufstack/monorm-auth \
  @ufstack/monorm-timestamps @ufstack/monorm-soft-delete @ufstack/monorm-locking @ufstack/monorm-inherit @ufstack/monorm-query-defaults \
  @ufstack/monorm-generic @ufstack/monorm-proxy @ufstack/monorm-composition @ufstack/monorm-file-storage
npm install monorm@npm:@ufstack/monorm

The monorm[postgres] and monorm[sqlite] extras are gone: the wheel has both drivers. Two copies of one extension id stop the load with the error "installed twice", which names the package to uninstall. In a schema, import "app:monorm-auth" is the Python name of the auth app and import "app:auth" is the Node name. Change the imports in your code from @ufstack/monorm to monorm and from @ufstack/monorm-<name> to monorm/extensions/<name>.

You need uv, Rust (cargo), and Node 20.19+ or 22.12+ (or Bun) for the TypeScript package.

Features

Build-time extensions are Rust crates. The monorm package has these built in: proxy models, query defaults, model composition, file storage, generic relations, timestamps, soft delete, locking and inheritance. See the extension index.

Databases and platforms

Benchmarks

Measured in one run (d428e01, 2026-10-28) on a shared cloud VM (vm, Linux 6.18.44 x86_64) with PostgreSQL 16.15. Contenders: Django 6.1.2 (sync and async), SQLAlchemy 2.1.6 (sync and async, asyncpg), Prisma 7.10.1, Drizzle 0.45.4 and pg 8.23.1. "N× faster" is the contender median time divided by the monorm median time. Every number is measured and end to end: it includes the database round trip.

• The Python work alone (build the query and make the SQL, no database) is 4.39× faster than Django async (geometric mean of 10 cases). This number is approximate.
• Level or slower cases: a case is level when the interval of its speed-up includes 1.00.
  • Python vs Django async: tx-5 (1.10×, level).
  • Python vs Django sync: insert-1 (1.07×), bulk-update-100 (1.10×) and tx-5 (1.03×) are level.
  • Python vs SQLAlchemy sync: tx-5 is 0.92× (slower, level). Against SQLAlchemy async, no case is level.
  • Node vs Prisma: bulk-update-100 (1.08×) and delete-100 (1.03×) are level.
  • Node vs Drizzle: projection-1000 (1.01×), filter (1.11×), update-1 (1.08×), bulk-update-100 (0.99×, slower), delete-100 (1.05×) and tx-5 (0.97×, slower) are level.
• Bun has only 3 cases (read-pk, read-1000, bulk-insert-1000): 2.48× faster than Prisma and 1.46× faster than Drizzle (geometric means), none level.
• Against Django sync the Python geometric mean is 1.59× faster, against SQLAlchemy sync 2.25×.
• It is one run on a shared VM. Treat a difference whose interval overlaps 1.00 as no difference. Django async has no async atomic(), which affects tx-5.

Full tables, the method and the raw data: bench/RESULTS.md and bench/compare/README.md. Run the comparison yourself before you decide.

Status and limits

Both API docs list what is not done yet: Python and schema. The API is async only. There is no MySQL driver. The crate on crates.io comes later.

Docs

• docs/README.md: the documentation index (core, extensions, performance).
• examples/blog: a schema, its generated models and migrations, and runnable demos.
• CHANGELOG.md: what changed.

Contributing

Read CONTRIBUTING.md for the setup, the checks and the pull request rules. Report a security problem as described in SECURITY.md.

License

MIT. See LICENSE.