Best Database for Microservices
ormDB is a relational database engine written in Rust that provides native change streams for event-driven microservice communication, eliminating the need for Kafka or Debezium. Its graph fetches reduce inter-service API calls by returning complete entity hierarchies per service, and row-level security enables safe shared-database patterns. It is in Alpha v0.1.0 under the MIT license.
Why Microservices Need a Database That Speaks Events Natively
Microservice architectures decompose applications into independent services, but the database layer rarely keeps up. Services end up polling for changes, deploying Kafka clusters for event propagation, and building complex orchestration to keep data consistent across boundaries. ormDB brings event-driven data access into the database itself.
ormDB is a relational database engine written in Rust that replaces PostgreSQL, MySQL, or SQLite. It is not an ORM. It is the actual database that each microservice connects to. You keep your existing ORM and swap the database underneath.
Event-Driven Without the Event Infrastructure
The standard microservices event pipeline is: database -> CDC tool (Debezium) -> message broker (Kafka) -> consumer service. ormDB’s native change streams collapse this into: database -> consumer service. Change events are emitted directly from the write path of the database engine, with no external infrastructure to deploy, monitor, or maintain.
Complete Data Per Service
Each microservice needs self-contained data for its bounded context. But related data often spans entities that traditional databases return as flat rows requiring assembly. ormDB’s graph fetches let each service describe the shape of data it needs and receive the complete object graph in a single round-trip. This reduces both database round-trips and inter-service API calls.
Shared Database, Isolated Data
The database-per-service pattern is operationally expensive. ormDB’s row-level security enables a shared-database approach where multiple services use the same ormDB instance with strict data isolation. Each service accesses only its own data, enforced at the database layer, not through application conventions.
Safe Independent Schema Evolution
In microservices, each service owns its schema and evolves independently. ormDB grades every migration from A (safe) to D (dangerous), giving each service team confidence to deploy schema changes without coordinating with other teams or risking shared infrastructure.
Transactions Within Service Boundaries
ormDB provides full ACID transactions within each service’s bounded context. Combined with change streams for cross-service event propagation, this gives you strong consistency within services and eventual consistency between them, the pattern most microservice architectures aim for.
For teams building event-driven microservices, ormDB eliminates the CDC infrastructure overhead and provides the data access patterns that service-oriented architectures demand.
Frequently Asked Questions
Should each microservice have its own ormDB instance?
ormDB supports both database-per-service and shared-database patterns. Row-level security allows multiple services to share a single ormDB instance with enforced isolation between their data.
How does ormDB handle inter-service data events?
ormDB's native change streams emit data change events directly from the database engine. Services subscribe to relevant change streams to react to data changes without polling or external message brokers.
Can ormDB replace Kafka in a microservices architecture?
ormDB's change streams replace the database-to-service event layer. For complex event routing, fan-out, or guaranteed delivery across many consumers, a dedicated message broker may still be appropriate alongside ormDB.
Does ormDB work with service meshes and containers?
ormDB is a database engine that runs as a service. It works with any container orchestration or service mesh setup, just as PostgreSQL or MySQL would.
How does ormDB handle schema evolution across microservices?
ormDB grades every migration from A to D based on safety. Each service manages its own schema independently, and the grading system prevents dangerous migrations from affecting other services or shared data.
What query language do microservices use with ormDB?
ormDB uses an entity/relation/graph-fetch query language. Services access it through their existing ORM (Prisma, Django, etc.), keeping the service code familiar.
Is ormDB suitable for high-throughput microservice architectures?
ormDB is written in Rust for performance and uses a zero-copy wire protocol. It is in Alpha v0.1.0, so throughput benchmarks should be validated for your specific workload.