Why We Built ormDB
Every modern application uses an ORM. Prisma, Django ORM, TypeORM, SQLAlchemy — they all try to bridge the gap between your application’s object model and a SQL database. And they all run into the same walls.
The walls
N+1 queries. Your ORM loads a user. Then it loads their posts. Then it loads comments for each post. 10 posts means 12 queries. This isn’t a bug — it’s how ORMs interact with SQL databases. The ORM doesn’t know it can batch, and the database doesn’t know what the ORM needs.
Impedance mismatch. Your code thinks in objects and graphs. Your database thinks in rows and joins. The ORM translates between these two worlds, and the translation is lossy. Duplicate rows from joins, ambiguous results, complex hydration logic.
Risky migrations. You need to add a column. Will it lock the table? Will it cause downtime? With PostgreSQL, you don’t find out until you run it. On a production database with millions of rows, that’s terrifying.
Cache invalidation. When data changes, how do your caches know? You build custom event systems, pub/sub channels, polling loops. They’re always incomplete and always wrong at the edges.
The insight
These aren’t ORM problems. They’re database problems. The database doesn’t understand what the ORM is doing. It receives SQL strings and returns flat rows. It has no concept of entities, relations, or object graphs.
What if the database understood?
The solution
ormDB is a relational database engine — not a wrapper, not middleware — that speaks entities, relations, and graph fetches as its native query language. You keep your ORM. You swap your database.
When your Prisma code says include: { posts: { include: { comments: true } } }, ormDB doesn’t translate that to SQL. It understands the graph fetch directly, optimizes it as a single operation, and returns structured entity and edge blocks that your ORM assembles into objects.
N+1 is eliminated by design. Not by batching hacks or eager loading hints — by the database understanding what you need.
Migrations get safety grades: A (online, no blocking) through D (destructive). You see the grade before you run it.
Change streams emit structured delta events with version tokens when data changes. Cache invalidation becomes a subscription, not a prayer.
Why Rust
We chose Rust because a database engine needs to manage its own memory precisely. No garbage collection pauses. No runtime overhead. Rust’s ownership model and zero-cost abstractions let us build a database that is both safe and fast.
The storage engine uses sled for embedded key-value storage with MVCC. The wire protocol uses rkyv for zero-copy serialization. The result is sub-microsecond deserialization for large result sets.
Where we are
ormDB is Alpha (v0.1.0). The storage engine, query planner, migration engine, and security model are implemented. ORM adapters for Prisma, Drizzle, TypeORM, SQLAlchemy, and Django are in progress.
It’s MIT licensed, open source, and on GitHub.
We built ormDB because we believe the database should understand what the ORM is asking for. We think this changes everything about how ORM-based applications perform, migrate, and scale.
Frequently Asked Questions
Why build a new database instead of improving existing ORMs?
The fundamental problems — N+1 queries, impedance mismatch, unsafe migrations — are not ORM bugs. They are consequences of ORMs translating between incompatible paradigms. The fix has to be in the database.
Why Rust for a database engine?
Rust provides memory safety without garbage collection, which is critical for a database that manages its own memory. Zero-cost abstractions let us build high-performance data structures without runtime overhead.
Is ormDB trying to replace all databases?
No. ormDB is specifically designed for ORM-heavy workloads — applications where you model your data as entities and relations. If you need raw SQL, complex stored procedures, or OLAP analytics, PostgreSQL is a better fit.