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
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.
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.