Aeion Database Wrapper vs Standard ORMs
Discover why enterprise platform engineers avoid raw ORMs like Prisma and TypeORM in production, relying instead on Aeion's Transparent Database Wrapper to enforce multi-tenant security and RBAC natively at the kernel level.
Decisive Architectural Advantages
Why raw database access is dangerous at scale.
The End of Data Leaks
In standard SaaS development using Prisma or Sequelize, developers must manually remember to append `WHERE tenant_id = x` to every single query. If a junior developer forgets, Customer A sees Customer B's data. Aeion OS makes this mathematically impossible. The JS Proxy intercepts the query and forcefully binds the `tenantId` into the AST execution layer automatically.
Unbypassable RBAC Security
When writing raw SQL, enforcing security relies on developers writing perfect endpoint logic. Aeion's 3-Stage RBAC shifts security to the schema layer. A developer requests data via the wrapper, and the engine evaluates the user's role against the schema, dynamically injecting the necessary Row-Level Security filters before hitting the database, rendering API-sniffing useless.
Temporal Resilience
Standard ORMs simply overwrite data. Once an `UPDATE` command executes, the history is gone forever. Aeion intercepts every mutation to generate an Event Sourcing-lite history using RFC 6902 JSON patches. The ability to "time travel" and query a record exactly as it looked last Tuesday is built directly into the wrapper.
Aegis Destruction Guards
Dropping a column in a standard ORM migration is terrifyingly easy. Aeion integrates the Aegis Guardrail system. If a Drizzle migration attempts to `TRUNCATE` or `DROP` a non-empty table, Aegis intercepts it at the execution layer, halting the process and mandating a forced S3/MinIO `pgBackRest` snapshot before proceeding.
Field-level permissions defined once, not scattered across endpoints.
A raw ORM setup typically means re-implementing "hide this field from junior staff" logic in every response payload across every REST endpoint — easy to miss, hard to audit. Aeion's Transparent Database Wrapper moves RBAC rules onto the schema itself: the wrapper injects the SQL filters and strips unauthorized fields before the payload leaves the kernel, so that whole class of manual-masking bug can't occur.
Frequently Asked Questions
On top. Drizzle handles the SQL layer; the Aeion wrapper adds enforced tenant isolation, access-control filter injection, field-level masking, and temporal history capture — all at the kernel layer, before queries hit the database. You get Drizzle's type safety + Aeion's safety net.
They can't — the wrapper injects `tenant_id` into every query at the AST level. There is no code path that runs an unscoped query against tenant tables from a request context. Cross-tenant access requires explicitly using the system database client (only available inside platform-level code), which is intentionally awkward.
Field access functions on the schema (`access.read`, `access.update`) evaluate per-user per-field. The wrapper strips disallowed fields from the response payload at the kernel boundary, not in the controller. A junior dev can write `findOne(...)` against the user table and never see a field they're not authorized for — the field literally isn't in the result.
Reconstruct any record's exact state at any past timestamp, not just see what changed. Audit logs tell you 'name field updated at 14:23'; temporal lets you query 'what did this customer's full record look like last Tuesday at 14:23?' Useful for compliance ('what did the user see when they signed?'), debugging ('what state caused this bug?'), and customer support ('roll this back to before the bad import').
Negligible per-query — the filter injection happens at AST compile time, not at execution. The temporal capture is async write to a separate event log, not a synchronous trigger. Production tenants run thousands of queries per second through the wrapper with sub-millisecond overhead added.
Where a raw ORM still makes sense.
This comparison is about multi-tenant SaaS, where tenant isolation and schema-level RBAC are the hard part. If you're building a single-tenant app, a standalone service, or a tool that never separates one customer's data from another's, a raw ORM is a perfectly good — and simpler — choice. Prisma and TypeORM have large communities, mature standalone migration tooling, and drivers for databases beyond Postgres; the Aeion wrapper is Postgres + Drizzle by design. And the wrapper's safety net only pays off when you're running the platform: adopting it purely to wrap queries in a codebase that isn't on Aeion OS would be more machinery than you need. Reach for the wrapper when isolation, field-level masking, and time-travel history are requirements you'd otherwise be hand-rolling on every query.
Abandon the Raw ORM
Ensure perfect multi-tenant security by gating your database at the kernel.