SYS:PRODUCT // Authorization Platform
Fine-grained authorization, managed for you
Every application needs authorization. Most teams build it from scratch — role tables, custom middleware, hand-rolled audit logs. InferaDB is managed authorization infrastructure: a purpose-built system with sub-3µs permission checks, cryptographic audit trails, and native multi-tenancy. Define your permission model, call the API, and stop maintaining authorization code.
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 IPL policy 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.
IPL policy evaluation
InferaDB Permission Language defines your authorization model declaratively. The engine compiles IPL into an optimized evaluation plan and executes it against the relationship graph — no interpretation overhead at check time.
Six core services
Check, BatchCheck, Expansion, Resources, Subjects, and Watch. Each is a focused API that does one thing well. No monolithic query language to learn — just the operations authorization systems actually need.
Revision tokens
Every write returns a revision token. Pass it to subsequent reads to guarantee consistency — no stale permission checks, no time-of-check-to-time-of-use race conditions. Consistency without coordination overhead.
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.
Two-layer LRU cache
Hot permission checks are served from an in-process cache with automatic invalidation on writes. No external cache to manage, no TTL tuning, no stale data. The cache is consistency-aware — it invalidates on relationship changes, not on timers.
No capacity planning
Performance scales linearly with your workload. Add replicas for read throughput, add nodes for storage capacity. No re-sharding, no rebalancing, no downtime. Your authorization layer grows with your application.
Predictable under load
Rust's lack of garbage collection means no GC pauses, no tail latency spikes, no p99 surprises during traffic bursts. The latency you measure in staging is the latency you get in production.
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.
How it works under the hood
InferaDB is three components: the Engine that evaluates permissions, the Ledger that provides an immutable audit trail, and the Dashboard that gives your team visibility into your authorization system. The Engine is the core — everything else builds on its primitives.
Relationship graph, not rule engine
Authorization decisions are resolved by traversing a relationship graph, not by evaluating a rule chain. This means permission checks are O(depth) in the graph, not O(rules) in your policy. As your policy grows in complexity, check latency stays constant.
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. A compromised node cannot leak cross-tenant relationship data.
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 authorization layer is the ceiling on every deal you close.
Remove the ceiling.
Purpose-built storage. Sub-3µs permission checks. Raft consensus. Full audit trails. Ten SDKs. One system that replaces the authorization infrastructure your team keeps rebuilding.