Frequently Asked Questions

ormDB is a relational database engine written in Rust that replaces PostgreSQL, MySQL, or SQLite in your stack. It speaks ORM natively — its query language is entity/relation/graph-fetch instead of SQL. You keep your ORM (Prisma, Django, etc.), swap the database.

No. ormDB is the database itself, not an ORM library. It is a complete relational database engine with ACID transactions, constraints, and indexes. ORMs connect to ormDB through drop-in adapters, just like they connect to PostgreSQL.

Yes. ormDB is designed to replace PostgreSQL (or MySQL/SQLite) as the database in your stack. It provides the same relational guarantees — ACID transactions, foreign keys, constraints — but with a native understanding of ORM query patterns.

Rust. The entire database engine — storage, query planner, wire protocol, CLI — is written in Rust (Edition 2021). This gives us memory safety without garbage collection and zero-cost abstractions for performance-critical code.

ormDB is currently in Alpha (v0.1.0). It is functional and installable, but not yet recommended for production workloads. We are actively developing the storage engine, query optimizer, and ORM adapters.

MIT. ormDB is fully open source. You can use it, modify it, and distribute it freely.

Yes. ormDB is MIT licensed, free to use, and developed in the open on GitHub at github.com/incredlabs/ormdb. There are no paid tiers or feature gates.

Prisma is an ORM — a TypeScript library that generates queries. ormDB is the database those queries run against. They are complementary: you keep Prisma (or Drizzle, Django, etc.) and point it at ormDB instead of PostgreSQL, so the database itself understands the graph fetches your ORM asks for.

ormDB supports graph fetches — you declare a root entity and an include graph of relations, and ormDB returns the entire object graph in a single round-trip. The database compiles this into optimized relational plans internally. Your ORM never needs to issue separate queries per relation.

Graph fetches are ormDB's primary query primitive. You specify a root entity type, filters, and an include graph of relations to load. ormDB returns structured entity blocks and edge blocks that clients assemble into nested objects. No N+1, no ambiguous join rows.

ormDB does not use SQL as its query language. Its native query language is a typed, structured IR (intermediate representation) that represents entity/relation/graph-fetch operations. ORM adapters translate ORM query patterns into this IR. Raw SQL passthrough is not supported.

Every schema migration in ormDB receives a safety grade: A (online, no blocking), B (online, brief blocking), C (requires careful timing), or D (destructive). You see the grade before you run the migration, so you never accidentally take down your database with a risky ALTER.

Change streams are ormDB's built-in CDC (Change Data Capture) mechanism. When entities or relations change, ormDB emits structured delta events with version tokens. You subscribe to these events for real-time cache invalidation, event-driven architectures, or downstream data syncing.

Yes. ormDB includes HNSW-indexed k-nearest neighbor search for AI embeddings. You can store vectors alongside your relational data and query them together — no need for a separate vector database.

Query budgets prevent runaway queries. You set limits on max depth (include nesting), max fanout per relation, max total rows/edges returned, and execution time. Queries that exceed budgets are rejected, preventing accidental full-table scans from ORM-generated queries.

ormDB has drop-in adapters for Prisma, Drizzle, TypeORM, Sequelize, Kysely (TypeScript/JavaScript), SQLAlchemy, and Django (Python). Adapters translate ORM query structures into ormDB's native graph fetch IR.

No. ormDB adapters are drop-in replacements for your database driver. Your ORM models, queries, and business logic stay the same. You change the connection string and adapter configuration.

No. ormDB does not support raw SQL passthrough. Its query language is a typed IR optimized for ORM workloads. If your application relies heavily on raw SQL, complex stored procedures, or vendor-specific SQL extensions, ormDB may not be the right fit.

The migration process involves: (1) Install ormDB and configure your ORM adapter. (2) Define your entity schema in ormDB format. (3) Migrate your data using ormDB's import tools. (4) Switch your connection string. See our migration guides for step-by-step instructions.

For relationship-heavy TypeScript apps, ormDB is a strong choice because its graph fetches return nested object graphs that mirror your interfaces and eliminate N+1 queries, working through Prisma, Drizzle, or TypeORM. See the "best database for TypeScript" guide for the full comparison against PostgreSQL, MongoDB, SQLite, and Supabase.

ormDB works as a Django ORM backend and eliminates N+1 queries via graph fetches while keeping ACID relational guarantees. It is a strong fit for Python teams that want native relations without swapping ORMs. See the "best database for Python/Django" guide for tradeoffs versus PostgreSQL.

ormDB suits multi-tenant SaaS because row-level security is enforced by the engine on every query and graph fetch, safe A-D migrations protect the shared schema, and query budgets prevent noisy-neighbor problems. See the "best database for SaaS" and multi-tenant guides for details.

Yes. ormDB is MIT licensed and free to use. There are no paid tiers or feature gates.

incredlabs offers consulting services for database architecture, migration planning, and ormDB implementation. Contact consulting@incredlabs.com for details.

ormDB is built by incredlabs, founded by Dipankar Sarkar. The project is open source and developed on GitHub.

Full documentation is at docs.incredlabs.com/ormdb. The source code and architecture docs are on GitHub at github.com/incredlabs/ormdb.