ormDB vs PostgreSQL
ormDB is a relational database engine written in Rust that replaces PostgreSQL with native graph-fetch queries, eliminating N+1 problems at the engine level. PostgreSQL offers decades of stability, a vast extension ecosystem, and deep SQL compliance. ormDB is best for ORM-heavy workloads; PostgreSQL remains the safer choice for mature, SQL-dependent production systems.
Verdict: ormDB is purpose-built for ORM workloads with native graph queries; PostgreSQL is the proven general-purpose SQL powerhouse.
ormDB strengths
- Native graph-fetch queries eliminate N+1 problems entirely
- Zero-copy wire protocol (rkyv) reduces serialization overhead
- Safe migrations with A-D grading prevent destructive schema changes
- Built-in change streams (CDC) without extensions or logical replication setup
- Query budgets prevent runaway queries at the engine level
PostgreSQL strengths
- Decades of production hardening and battle-tested stability
- Massive ecosystem of extensions (PostGIS, pg_vector, TimescaleDB)
- Deep SQL standard compliance and advanced query planner
- Enormous community, tooling, and hiring pool
- Mature replication, partitioning, and HA solutions
Overview
ormDB is a relational database engine written in Rust that replaces PostgreSQL as the database underneath your ORM. Both are relational databases with ACID transactions, but they differ fundamentally in how they handle the queries your application actually makes.
PostgreSQL speaks SQL. Your ORM translates object graph operations into SQL queries, often generating dozens of round-trips to resolve nested relations. This is the N+1 problem, and it exists because SQL has no concept of an object graph.
ormDB speaks entity/relation/graph-fetch natively. When your ORM asks for a user with their posts, comments, and tags, ormDB resolves the entire object graph in a single round-trip. No joins to assemble manually. No N+1.
Performance and Protocol
ormDB uses a zero-copy wire protocol built on rkyv, eliminating the serialization and deserialization overhead that traditional database protocols impose. PostgreSQL uses a text-based protocol that requires parsing on both sides.
Query budgets in ormDB let you cap the computational cost of any query at the engine level. PostgreSQL offers statement_timeout, but it measures wall-clock time rather than actual query cost.
Migrations and Safety
ormDB grades every migration from A (safe, zero-risk) to D (destructive, data loss possible). This safe migration grading happens automatically and prevents accidental column drops or type changes from reaching production without explicit acknowledgment.
PostgreSQL migrations depend entirely on external tooling. The database itself has no opinion on whether your ALTER TABLE is safe.
Built-In Capabilities
Where PostgreSQL requires extensions for vector search (pgvector), advanced geo queries (PostGIS), and change data capture (logical replication), ormDB builds these capabilities directly into the engine. Vector search, geo search, full-text search, and change streams all work out of the box.
When to Choose
Choose ormDB when your application is ORM-driven and you want the database to understand your data model natively. Choose PostgreSQL when you need the broadest ecosystem, the deepest SQL support, and decades of production-proven stability.
Feature Comparison
| Feature | ormDB | PostgreSQL |
|---|---|---|
| Native Graph Queries | Yes | No |
| ACID Transactions | Yes | Yes |
| N+1 Elimination | Yes | No |
| Change Streams (CDC) | Yes | Partial |
| Vector Search | Yes | Partial |
| Full-Text Search | Yes | Yes |
| Geo Search | Yes | Partial |
| Row-Level Security | Yes | Yes |
| Safe Migration Grading | Yes | No |
| Zero-Copy Wire Protocol | Yes | No |
| Query Budgets | Yes | No |
| SQL Support | No | Yes |
Choose ormDB when
- → Your app uses an ORM and you want the database to understand object graphs natively
- → N+1 query problems are a persistent performance bottleneck
- → You need real-time change streams without configuring logical replication
- → You want safe, graded migrations that warn before destructive changes
- → You need vector search, geo search, and full-text search without installing extensions
Choose PostgreSQL when
- → You need a battle-tested database with decades of production use
- → Your workload relies on advanced SQL features like window functions or CTEs
- → You depend on PostgreSQL-specific extensions like PostGIS or TimescaleDB
- → You need a large hiring pool of engineers with existing expertise
- → Your infrastructure and tooling are deeply integrated with PostgreSQL
Frequently Asked Questions
Can I migrate from PostgreSQL to ormDB?
Yes. ormDB provides ORM adapters for Prisma, Drizzle, TypeORM, Sequelize, Kysely, SQLAlchemy, and Django. You keep your ORM and swap the database underneath.
Does ormDB support SQL?
ormDB uses a native entity/relation/graph-fetch query language instead of SQL. Your ORM adapter translates your existing ORM calls into ormDB's native protocol.
Is ormDB as reliable as PostgreSQL?
ormDB is currently in Alpha v0.1.0. PostgreSQL has decades of production hardening. ormDB is MIT-licensed and designed for correctness, but it is earlier in its maturity journey.
Do I need to rewrite my application to use ormDB?
No. If you use a supported ORM (Prisma, Drizzle, Django, etc.), you swap the database driver. Your application code stays the same.
How does ormDB handle extensions that PostgreSQL has?
ormDB builds vector search, geo search, full-text search, and CDC directly into the engine. There is no extension system because the most-needed capabilities are native.
What language is ormDB written in?
ormDB is written in Rust, providing memory safety and high performance without a garbage collector.
Is ormDB open source?
Yes. ormDB is released under the MIT license.