ormDB vs Traditional ORMs
ormDB is a relational database engine written in Rust that works underneath your existing ORM (Prisma, Django, Drizzle, etc.), not instead of it. Traditional ORMs translate object models into SQL, causing N+1 queries and impedance mismatch. ormDB eliminates these problems at the engine level by understanding entity relations natively and resolving object graphs in a single round-trip.
Verdict: ormDB is not an ORM -- it is the database engine that makes your existing ORM (Prisma, Django, etc.) work without N+1 problems or impedance mismatch.
ormDB strengths
- Eliminates N+1 at the database engine level, not the application layer
- Understands entity relations natively -- no impedance mismatch
- Works WITH your existing ORM, not instead of it
- Graph-fetch queries return complete object graphs in one round-trip
- Safe migrations graded A-D at the engine level
Traditional ORMs strengths
- Mature abstractions with years of community knowledge
- Work with any SQL database (PostgreSQL, MySQL, SQLite)
- Rich query builders and model validation at the application layer
- Large ecosystems with plugins, middleware, and documentation
- Battle-tested in millions of production applications
Overview
ormDB is a relational database engine written in Rust that replaces the SQL database underneath your existing ORM. It does not replace Prisma, Django, Drizzle, or any other ORM. It makes them work properly.
Traditional ORMs sit between your application and a SQL database. They translate your object-oriented models into SQL queries and translate the results back into objects. This translation is the source of two persistent problems: N+1 queries and impedance mismatch.
The N+1 Problem
When your ORM fetches a list of users and their posts, it typically generates one query for users and then one query per user for their posts. This is the N+1 problem. ORMs offer workarounds — eager loading, data loaders, batch queries — but these are application-layer patches.
ormDB eliminates N+1 at the database engine level. Its native graph-fetch query resolves the entire object graph (users, posts, comments, tags) in a single round-trip. Every ORM adapter benefits automatically. No eager loading configuration required.
Impedance Mismatch
SQL databases store data in flat tables with foreign keys. Your application thinks in objects with nested relations. The ORM bridges this gap, but the bridge is lossy. Complex relations require multiple joins, subqueries, or separate queries. The ORM guesses at the most efficient strategy and often guesses wrong.
ormDB stores and queries data as entities with relations. There is no gap to bridge. When your ORM defines a User with Posts, ormDB understands that relationship natively and can traverse it without assembling joins.
How It Works
You keep your ORM. You install the ormDB adapter for your ORM (Prisma, Drizzle, TypeORM, Sequelize, Kysely, SQLAlchemy, or Django). You point your database connection at ormDB instead of PostgreSQL or MySQL. Your models, queries, and application code stay the same.
The adapter translates your ORM’s query language into ormDB’s native entity/relation/graph-fetch protocol. ormDB resolves the query and returns structured data over its zero-copy wire protocol (rkyv).
What You Gain
Beyond N+1 elimination, ormDB adds capabilities your SQL database does not offer: change streams (CDC) for real-time updates, vector search for AI workloads, geo search, query budgets, and safe migrations with A-D grading. These features are available to every ORM adapter without extra infrastructure.
When to Choose
Use ormDB when your ORM is fighting the database. Use a traditional ORM with PostgreSQL or MySQL when you need maximum ecosystem compatibility, multi-database portability, or battle-tested production stability.
Feature Comparison
| Feature | ormDB | Traditional ORMs |
|---|---|---|
| Native Graph Queries | Yes | No |
| N+1 Elimination | Yes | Partial |
| Entity/Relation Awareness | Yes | Partial |
| ACID Transactions | Yes | N/A |
| Safe Migration Grading | Yes | No |
| Change Streams (CDC) | Yes | No |
| Vector Search | Yes | No |
| Multi-Database Support | No | Yes |
| Application-Layer Validation | No | Yes |
| Query Budgets | Yes | No |
| Zero-Copy Wire Protocol | Yes | No |
| Row-Level Security | Yes | No |
Choose ormDB when
- → Your ORM generates N+1 queries and eager loading is not solving the problem
- → You want the database to understand your object model natively
- → Impedance mismatch between your ORM models and SQL is causing bugs
- → You need change streams, vector search, or geo search without extra infrastructure
- → You want migration safety enforced at the database level
Choose Traditional ORMs when
- → You need to support multiple database backends simultaneously
- → Your workload is SQL-heavy with complex raw queries
- → You are locked into a specific SQL database for compliance or infrastructure reasons
- → Your team relies on ORM-specific features like Prisma Studio or Django Admin
Frequently Asked Questions
Does ormDB replace my ORM?
No. ormDB replaces the database underneath your ORM. You keep using Prisma, Drizzle, Django, SQLAlchemy, TypeORM, Sequelize, or Kysely. You swap the database, not the ORM.
How does ormDB fix N+1 if I keep my ORM?
ormDB understands entity relations natively. When your ORM requests related data, ormDB resolves the entire object graph in a single round-trip instead of generating separate SQL queries for each relation.
What is the impedance mismatch problem?
Traditional ORMs translate object-oriented models into SQL tables and back. This translation loses information about relationships, leading to inefficient queries. ormDB's native entity/relation model eliminates this mismatch.
Which ORMs does ormDB support?
ormDB provides adapters for Prisma, Drizzle, TypeORM, Sequelize, Kysely, SQLAlchemy, and Django ORM.
Do I need to change my application code?
No. You change the database connection configuration to point at ormDB instead of PostgreSQL or MySQL. Your ORM code, models, and queries remain the same.
Can traditional ORMs solve N+1 without ormDB?
ORMs offer eager loading, data loaders, and query optimization hints. These are application-layer workarounds. ormDB eliminates N+1 at the database engine level, so it works automatically for every query.
Is ormDB production-ready?
ormDB is in Alpha v0.1.0. Traditional ORMs paired with PostgreSQL or MySQL are the production-proven choice today. ormDB is MIT-licensed and designed for correctness.