SYS:PRODUCT // Authorization Platform
Fine-grained authorization, managed for you
Your team added a roles table in week one. By year two, it's a custom authorization system — six engineers, a role matrix nobody can reason about, and an audit trail held together with application logs. InferaDB replaces all of it: purpose-built infrastructure where permission checks are faster than a network round-trip to your own database, every decision is tamper-proof, and each customer's data is isolated by default. Define your model, call the API, and get your engineers back.
Every team reinvents authorization. Most get it wrong.
Authorization looks simple until it is not. You start with a roles table, add a few joins, and ship. Then comes multi-tenancy, hierarchical permissions, role explosion, and the first production incident where a customer sees another customer's data. Now you are maintaining a bespoke authorization system that nobody wants to touch and everyone is afraid to change.
Wrong tool for the job
General-purpose databases handle authorization queries, but they were not optimized for them. Recursive graph traversal in Postgres means multi-millisecond latencies, query plan instability, and index bloat that grows with your permission model's complexity.
Policy without storage
Policy engines like OPA and Cedar evaluate rules — but they do not store the relationships those rules operate on. You still need a data layer, a sync pipeline, cache invalidation, and consistency guarantees. The policy engine solves 30% of the problem.
Home-grown systems break at scale
In-house authorization works until your first role explosion, your first cross-tenant data leak, or your first audit where you cannot explain why a user had access. Every team re-solves the same hard problems: caching, consistency, tenant isolation, audit logging.
The real cost is not engineering time
It is the deals you cannot close because your authorization system does not support the permission models enterprise buyers require. It is the compliance certifications you cannot pass because you lack audit trails. It is the multi-tenant architecture you cannot ship because your permission layer was not designed for tenant isolation.
Purpose-built for authorization. Nothing else.
InferaDB is not a policy engine bolted onto Postgres. It is a complete authorization system with its own storage engine, consensus protocol, and query language — designed from the ground up for one job: evaluating permissions against a relationship graph at speeds that disappear from your latency budget.
Written in Rust
No garbage collection pauses. No runtime overhead. The engine is compiled to native code with predictable, low-variance latency under load. Memory safety without a managed runtime.
Custom B+ tree storage
InferaDB does not sit on top of RocksDB or SQLite. Its storage engine uses a purpose-built B+ tree optimized for relationship graph traversal — not generic key-value operations. Index reads complete in 0.3ms.
Raft consensus
Linearizable writes across replicas. When a relationship changes, every subsequent read reflects that change. No eventual consistency windows where a revoked permission still grants access.
How a permission check works
Your application calls Check with a subject, relation, and object. The engine evaluates your Infera Policy Language (IPL) schema against its relationship graph, traverses the relevant paths, and returns ALLOW or DENY with a revision token — a consistency marker you can use to guarantee subsequent reads see at least the same state. The entire operation completes in microseconds, not milliseconds.
Relationship graph, not rule engine
Authorization decisions are resolved by traversing a relationship graph, not by evaluating a rule chain. Permission checks are O(depth) in the graph, not O(rules) in your policy. Complexity grows without latency growing.
Linearizable writes via Raft
Every relationship write is replicated through Raft consensus before acknowledgment. When a write succeeds, every subsequent read — on any replica — reflects that change. No eventual consistency surprises.
Per-vault encryption
Each tenant's data is encrypted at rest with AES-256-GCM using per-vault keys. Tenant isolation is enforced at the storage layer, not just the application layer.
Authorization that disappears from your latency budget
Permission checks are on the critical path of every API request. If your authorization layer adds measurable latency, your users feel it. InferaDB is engineered so authorization is never the bottleneck — even at millions of checks per second, even with complex relationship graphs, even under sustained load.
The APIs your authorization system actually needs
Six focused services, three interface options, and SDKs for ten languages. InferaDB gives you the building blocks to implement any authorization pattern — from simple role checks to complex hierarchical permissions with delegation and tenant isolation.
Check
Single permission check with revision token. Does subject S have relation R on object O? Returns ALLOW or DENY with the revision state, so you can guarantee consistency across subsequent calls.
BatchCheck
Evaluate multiple permission checks in a single round-trip. Critical for AI agent workflows that need 20+ checks per turn, or UI rendering that needs to determine visibility for dozens of elements at once.
Expansion traces
See exactly why a permission was allowed or denied. The engine returns the full graph traversal path — which relationships were followed, which conditions were evaluated. Debug authorization issues in minutes, not hours.
Watch API
Stream real-time relationship changes. Use it for cache invalidation in downstream systems, audit log ingestion, or triggering workflows when permissions change. Server-sent events, no polling.
Resources and Subjects
List all resources a subject can access, or all subjects that can access a resource. Powers UI patterns like "show me everything I have access to" and admin views like "who can see this document."
Three interfaces, ten SDKs
REST, gRPC, and OpenID AuthZEN. First-class SDKs for Go, Python, TypeScript, Java, Ruby, PHP, C#, Rust, Elixir, and Swift. Use whichever fits your stack — the behavior is identical across all three.
An honest look at the alternatives
Engineers evaluating authorization infrastructure typically consider three approaches. Here's how they compare.
Built in-house
Role tables in Postgres, custom middleware, hand-rolled checks. This works early on — it is fast to build and you control everything. But it breaks down at scale: role explosion, cross-tenant data leaks, and compliance audits that demand audit trails you never built. Every team that goes this route eventually spends more time maintaining authorization than building product.
InferaDB replaces the bespoke system with purpose-built infrastructure — so your team stops re-solving graph traversal, cache invalidation, and tenant isolation from scratch.
Policy engines (OPA, Cedar)
OPA and Cedar are good at what they do: evaluating policy rules against input data. But they are policy engines, not authorization systems. They do not store relationships, they do not provide consistency guarantees, and they do not include a data layer. You still need to build the sync pipeline, manage the relationship store, and handle cache invalidation yourself.
InferaDB combines policy evaluation and relationship storage in a single system. IPL defines your model, the engine stores your relationships, and Raft consensus guarantees every read reflects every write.
Managed authorization (SpiceDB, Oso, Warrant)
These platforms share InferaDB's relationship-based approach, and they have advanced the category significantly. They are solid choices for teams that need managed authorization today. Where they differ is in the infrastructure layer: most rely on general-purpose databases under the hood.
InferaDB is built on a custom B+ tree storage engine, achieves sub-3µs permission checks without external caching layers, provides cryptographic audit trails via the Ledger, and enforces per-vault encryption for tenant isolation at the storage level — not just the application level.
How teams use the authorization engine
Middleware integration
Add a check call to your API gateway or request handler. The engine returns a decision before the request reaches your application code. SDKs for 10 languages make this a few lines of code.
Permission-aware queries
Use the Resources API to list what a user can access, powering filtered views, search results, and admin dashboards without post-filtering or N+1 queries.
Real-time sync
Stream relationship changes via the Watch API to keep downstream caches, search indexes, and UI state consistent with the authorization graph.
Your team is maintaining authorization code instead of shipping product.
That trade-off ends here.
Managed authorization infrastructure.
Integrate in minutes, not months.
Ship features instead of permission code.