Benchmarks

Benchmarked against 7 libraries: @casl/ability, casbin, accesscontrol, role-acl, @rbac/rbac, and easy-rbac. Numbers from vitest bench on identical authorization scenarios. Sizes verified via bundlephobia on 2026-03-30.

Run bun run bench in packages/duck-iam to reproduce the numbers here.

The honest verdict

CASL is faster than us. On simple RBAC checks, CASL is ~2x faster in production mode — it pre-compiles rules into a hash-map index at build time. duck-iam can't match that while keeping runtime-updatable policies.

We are faster than everyone else. In production mode, duck-iam beats easy-rbac, @rbac/rbac, accesscontrol, casbin, and role-acl.

We ship more features. Scoped roles, explain/debug traces, lifecycle hooks, batch permissions, 18 condition operators, 5 server middlewares, 3 client libraries. No competitor bundles all of them.

We are larger than CASL. ~21 KB vs ~6 KB. duck-iam includes a full policy engine, RBAC-to-ABAC converter, explain tracer, builder, config validator, and LRU cache. CASL ships none of that.

Library Overview

Runtime Performance

All numbers are ops/sec (higher is faster). Each library solves the same authorization problem. CASL condition checks use subject() so conditions actually run (bare string checks skip them). duck-iam has two modes: [DEV] returns rich Decision objects with timing and reasons, [PROD] returns plain booleans with zero overhead.

Simple RBAC: "can viewer read post?"

ABAC condition check: "can owner update own draft?"

Only libraries with real ABAC condition support. CASL uses subject() so conditions run.

Others excluded — no attribute-based condition support.

Role + condition: "can admin delete post?"

Deny path: "viewer cannot delete"

Batch: 20 permission checks

Cold start: build everything + first check

Why CASL is faster, and why it rarely matters

The architectural difference

CASL and duck-iam solve authorization at different engine levels:

CASL: pre-compiled lookup table. build() iterates every rule once and produces an index keyed by [action, subjectType]. Every can() call is a single hash-map lookup — O(1), ~0.012 us. Rules are frozen after build() and can't change at runtime.

duck-iam: dynamic policy engine. Policies load from databases, update at runtime through adapters, and invalidate via the LRU cache. Each evaluation does: WeakMap index lookup, Map.get by action:resource, condition evaluation, combining algorithm. Even with rule indexing, each check costs ~0.12 us — about 2x a single hash lookup.

Where the ~2x gap comes from (profiled)

Profiled operations in the production fast path:

The gap is not one big bottleneck. It's the sum of small costs a policy engine requires. CASL sidesteps them by freezing rules at build time.

What we optimized (and what we can't)

Every optimization that keeps the dynamic policy model is applied:

1. Rule indexing: pre-built Map<action:resource, Rule[]> per policy, cached via WeakMap. Removes the linear scan over all rules.
2. Unconditional rule flag: rules with empty conditions skip evalConditionGroup().
3. Inlined combiners: deny-overrides and allow-overrides inline into the evaluation loop — no array allocation, no function calls.
4. Path cache: condition field paths like subject.attributes.role split once and cache forever.
5. Production mode: no performance.now(), no Date.now(), no Decision allocation, no reason strings.

Closing the last ~2x gap means dropping dynamic policies and pre-compiling at init like CASL. That breaks adapters, runtime policy updates, and the LRU cache — the features that make duck-iam a policy engine instead of a lookup table.

Why it doesn't matter in practice

Authorization isn't the bottleneck. A typical API request:

The gap is 60 nanoseconds. At 100 checks per request, that's 6 us — 0.00012% of a 50 ms request.

Dev vs Prod Mode

duck-iam has two execution modes. They change runtime behavior and return types:

// Development (default) -- rich Decision with timing, reasons, rule refs
const engine = new Engine({ adapter, mode: 'development' })
const decision = await engine.check('user-1', 'read', post)
// decision: Decision { allowed: true, effect: 'allow', reason: '...', duration: 0.5, timestamp: ... }
// engine.explain() is available
// Hooks (afterEvaluate, onDeny, onError) fire on every check
 
// Production -- plain boolean, maximum throughput
const prodEngine = new Engine({ adapter, mode: 'production' })
const allowed = await prodEngine.check('user-1', 'read', post)
// allowed: true (boolean)
// No performance.now(), no Date.now(), no object allocation, no reason strings
// engine.explain() throws -- not available in production
// Hooks (afterEvaluate, onDeny, onError) are skipped for maximum speed

// Development (default) -- rich Decision with timing, reasons, rule refs
const engine = new Engine({ adapter, mode: 'development' })
const decision = await engine.check('user-1', 'read', post)
// decision: Decision { allowed: true, effect: 'allow', reason: '...', duration: 0.5, timestamp: ... }
// engine.explain() is available
// Hooks (afterEvaluate, onDeny, onError) fire on every check
 
// Production -- plain boolean, maximum throughput
const prodEngine = new Engine({ adapter, mode: 'production' })
const allowed = await prodEngine.check('user-1', 'read', post)
// allowed: true (boolean)
// No performance.now(), no Date.now(), no object allocation, no reason strings
// engine.explain() throws -- not available in production
// Hooks (afterEvaluate, onDeny, onError) are skipped for maximum speed

engine.can() always returns boolean in both modes (for middleware compatibility).

Does production mode reduce bundle size?

The mode flag alone does not reduce bundle size. It's a runtime check. Import patterns do — the package is tree-shakeable, so bundlers drop unused code:

// Smallest production bundle -- import only the fast evaluator
// Tree-shakes away: Engine, explain, builder, config, validate, dev evaluate
import { evaluateFast } from '@gentleduck/iam'
const allowed = evaluateFast(policies, request) // boolean
 
// Full engine -- includes everything (dev + prod paths)
import { Engine } from '@gentleduck/iam'

// Smallest production bundle -- import only the fast evaluator
// Tree-shakes away: Engine, explain, builder, config, validate, dev evaluate
import { evaluateFast } from '@gentleduck/iam'
const allowed = evaluateFast(policies, request) // boolean
 
// Full engine -- includes everything (dev + prod paths)
import { Engine } from '@gentleduck/iam'

evaluateFast + evaluatePolicyFast give the smallest bundle when you manage policies yourself. The Engine, explain system, builder, and config validator only ship if imported.

engine.explain() is development-only.

Internal Performance

Pure evaluation timing, average of 2,000 iterations after 200 warmup rounds.

Engine Performance (with LRU caching)

Times vary by machine. Run bun run benchmark for your hardware.

Bundle Size

We are not the smallest. At ~21 KB, duck-iam is 3.5x larger than CASL. The full package bundles: evaluation engine, RBAC-to-ABAC converter, conditions engine (18 operators), explain/debug tracer, type-safe builder, config validator, and LRU cache. CASL ships none of that.

The package is tree-shakeable. Import only evaluateFast and skip the engine, explain, and builder for a much smaller bundle. Each adapter and server middleware adds ~0.8-1.7 KB.

Module Sizes

Feature Comparison

Where each library wins

@gentleduck/iam wins on

• Feature density: only library with scoped roles + explain/debug + lifecycle hooks + batch permissions + 18 condition operators + dev/prod mode in one package
• Faster than casbin, role-acl, accesscontrol: 3-50x faster in production mode
• Server integration: 5 framework middlewares (Express, Next.js, Hono, NestJS, generic)
• Client libraries: React, Vue, and vanilla JS with hooks and reactive state
• Type safety: full generic type parameters for actions, resources, roles, and scopes
• Explain API: the only library that tells you exactly why a permission was granted or denied
• Dev/Prod mode: rich debug objects in development, fast booleans in production

@casl/ability wins on

• Raw speed: 2x faster than duck-iam in production mode from the pre-compiled ability index
• Bundle size: ~6 KB, 3.5x smaller
• Maturity: production since 2017
• Ecosystem: ~900K downloads/week, extensive docs and community
• Isomorphic: proven frontend + backend sharing pattern

easy-rbac wins on

• Fastest deny path: 2x faster than CASL on deny checks
• Tiny bundle: ~2 KB, the smallest
• Zero config: hierarchical RBAC, nothing to set up

casbin wins on

• Adapter ecosystem: 20+ database adapters across 15+ languages
• Admin UI: web-based policy management panel
• Academic backing: formal PERM metamodel

@rbac/rbac wins on

• Fast simple checks: 2.5M ops/sec for basic RBAC
• Built-in middleware: Express, NestJS, Fastify
• Runtime role updates: add or change roles without restart

Smallest possible bundle

createAccessConfig() sets up the whole authorization system in one call, but it pulls in the full config system, validator, and builder. If all you need is policy evaluation, skip the config layer and import the building blocks directly.

Build a typed policy and evaluate it without createAccessConfig:

import type { Policy, AccessRequest } from '@gentleduck/iam'
import { evaluatePolicyFast } from '@gentleduck/iam'
 
// Define your action/resource types for type safety
type Action = 'read' | 'update' | 'delete'
type Resource = 'post' | 'comment'
 
const policy: Policy<Action, Resource> = {
  id: 'blog-policy',
  algorithm: 'deny-overrides',
  rules: [
    { id: 'allow-read', effect: 'allow', actions: ['read'], resources: ['post', 'comment'], conditions: {}, priority: 0 },
  ],
}
 
const request: AccessRequest<Action, Resource> = {
  subject: { id: 'user-1', roles: ['viewer'] },
  action: 'read',
  resource: { type: 'post', id: 'post-1' },
}
 
const allowed = evaluatePolicyFast(policy, request) // boolean

import type { Policy, AccessRequest } from '@gentleduck/iam'
import { evaluatePolicyFast } from '@gentleduck/iam'
 
// Define your action/resource types for type safety
type Action = 'read' | 'update' | 'delete'
type Resource = 'post' | 'comment'
 
const policy: Policy<Action, Resource> = {
  id: 'blog-policy',
  algorithm: 'deny-overrides',
  rules: [
    { id: 'allow-read', effect: 'allow', actions: ['read'], resources: ['post', 'comment'], conditions: {}, priority: 0 },
  ],
}
 
const request: AccessRequest<Action, Resource> = {
  subject: { id: 'user-1', roles: ['viewer'] },
  action: 'read',
  resource: { type: 'post', id: 'post-1' },
}
 
const allowed = evaluatePolicyFast(policy, request) // boolean

The package is fully tree-shakeable. Anything you don't import drops out: Engine, explain, builder, config, validate, adapters. From the module sizes above, evaluateFast alone is tiny next to the 21.9 KB core entry — pay only for what you use.

Other low-level pieces to import directly: PolicyBuilder, RuleBuilder, evaluateFast, evaluatePolicy, and the condition operators. Mix and match for the exact surface area you need.

Methodology

• @gentleduck/iam: bundle sizes from dist/ via gzip -c | wc -c. Performance via vitest bench with N=3 inner loops. Production mode uses evaluateFast() with rule indexing (WeakMap-cached per policy, Map lookup by action:resource).
• @casl/ability: condition benchmarks use subject() for real condition evaluation. Bare string checks (can('read', 'Post')) skip conditions and would give misleading numbers — we don't do that.
• casbin: real RBAC model (newModel() + StringAdapter) with role inheritance via grouping rules.
• accesscontrol, @rbac/rbac, easy-rbac: excluded from ABAC benchmarks (no condition support).
• Competitor sizes from bundlephobia.com, verified 2026-03-30.
• Sizes are minified + gzipped.
• All benchmarks run on the same machine in the same vitest session.

Reproduce:

cd packages/duck-iam
bun run bench       # vitest bench -- competitive comparison
bun run benchmark   # JSON data output + console summary

cd packages/duck-iam
bun run bench       # vitest bench -- competitive comparison
bun run benchmark   # JSON data output + console summary