DEV Community: Sebastian Cabarcas

Benchmarking Laravel Permission Checks: Database vs Redis

Sebastian Cabarcas — Wed, 01 Apr 2026 13:41:29 +0000

"How much faster is Redis for permission checks?" is a question I get every time I mention laravel-permissions-redis. The answer depends on your scale, your access patterns, and what you're measuring.

So I built a benchmark application to get real numbers. Here's what I found.

Methodology

The setup

PHP 8.3 with OPcache enabled
Laravel 12 with default configuration
Redis 7.2 running locally (same machine, minimal network latency)
MySQL 8.0 running locally
Packages compared:
- spatie/laravel-permission v6 (database-backed, using Redis as Laravel cache driver)
- scabarcas/laravel-permissions-redis v3 (Redis SETs, dual-layer cache)

The data

1 user with 50 permissions assigned via 3 roles
Permissions structured in groups: posts.*, users.*, settings.*, reports.*
Both packages configured with their recommended defaults

What we measure

Database queries -- the number of queries hitting MySQL per request
Cache architecture -- how each package stores and retrieves permission data
Invalidation cost -- what happens when permissions change
Cold start -- first request after cache flush
Warm state -- steady-state performance

Important note on fairness: Spatie is configured with CACHE_DRIVER=redis to give it the fastest possible cache backend. This comparison is about architecture, not "database vs Redis" in the trivial sense.

Benchmark 1: Database queries per request

A typical request in our test application performs 33 permission checks (middleware + policy + inline checks). Here's how many database queries each package generates:

Scenario	spatie/laravel-permission	laravel-permissions-redis	Reduction
1 request (cold cache)	5 queries	1 query	80%
1 request (warm cache)	0 queries	0 queries	--
10 sequential requests	14 queries	10 queries	~29%
50 sequential requests	54 queries	50 queries	~7%

Why the numbers converge

Both packages cache after the first request. The difference on subsequent requests comes from cache invalidation behavior, which we'll cover next.

The real story isn't in steady-state -- it's in what happens when the cache isn't warm.

Benchmark 2: Cache architecture deep dive

This is where the architectural differences matter most.

How Spatie stores permissions

Cache key: "spatie.permission.cache"
Value: Serialized PHP array of ALL permissions for ALL users

On every hasPermissionTo() call:

Fetch the full serialized blob from Redis (via Laravel Cache)
Deserialize it (unserialize())
Filter permissions for the current user
Scan the resulting array for the requested permission

Time complexity per check: O(n) where n = total permissions in the system

How laravel-permissions-redis stores permissions

Redis key: "auth:user:42:permissions"
Value: Redis SET {"posts.create", "posts.edit", "users.view", ...}

On every hasPermissionTo() call:

Check in-memory PHP array (if already resolved this request) -- zero I/O
If miss: single SISMEMBER auth:user:42:permissions "posts.create" command

Time complexity per check: O(1) -- hash table lookup within the Redis SET

What this means in practice

Aspect	Spatie	laravel-permissions-redis
First check in a request	Deserialize full cache + scan	`SISMEMBER` (1 Redis call)
Second check (same request)	Deserialize full cache + scan	In-memory array (0 I/O)
10th check (same request)	Deserialize full cache + scan	In-memory array (0 I/O)
Memory per check	Full permission array loaded	Only user's permission set

With Spatie, if your application has 10,000 permissions across all users, every single hasPermissionTo() call loads and scans that entire dataset. With Redis SETs, each check only touches the current user's data.

Benchmark 3: Cache invalidation

This is the benchmark that convinced me to build the package.

Scenario: Admin changes a user's permissions

Spatie's approach:

// When any permission changes:
app(PermissionRegistrar::class)->forgetCachedPermissions();
// This calls: Cache::forget('spatie.permission.cache');

Result: Every user's cache is gone. The next request from any user pays the full cold-start cost.

With 50,000 active users and a 200 req/sec API, this means:

~200 concurrent cold-start database queries
Each query rebuilds the full permission cache
Cache stampede risk if multiple users hit simultaneously

laravel-permissions-redis approach:

// When user 42's permissions change:
$repository->warmUserCache(42);
// Only rewarms: auth:user:42:permissions and auth:user:42:roles

Result: Only user 42's cache is rewarmed. Every other user's cache stays untouched.

Invalidation cost comparison

Metric	Spatie	laravel-permissions-redis
Users affected	ALL	1 (the changed user)
DB queries triggered	1 heavy query (all permissions)	2 light queries (1 user's roles + permissions)
Cache stampede risk	High (all users cold)	None (only 1 user rewarmed)
Time to full recovery	Depends on traffic	Instant (proactive rewarm)

Benchmark 4: Cold start and cache warming

Single user cold start

When a user logs in with no cached data:

Spatie:

Query all permissions in the system
Serialize and store in cache
Deserialize and scan on each check

laravel-permissions-redis:

Query this user's roles (1 query)
Query permissions for those roles (1 query)
Write Redis SETs: SADD auth:user:42:permissions "posts.create" "posts.edit" ...
All subsequent checks: SISMEMBER or in-memory

Bulk cache warming (deploy scenario)

After a deploy, you might want to pre-warm the cache for all users:

# laravel-permissions-redis provides this out of the box
php artisan permissions-redis:warm

# Spatie has no equivalent -- cache builds lazily on first request

User count	Warm time (laravel-permissions-redis)	Notes
1,000	~2s	Chunked processing
10,000	~15s	Parallel Redis pipelines
100,000	~120s	Batched with progress bar

With Spatie, there's no warm command. The cache rebuilds on the first request after deploy, meaning your first 100-1000 users experience a slow response.

Benchmark 5: Memory usage

Per-request memory footprint

Package	Memory per request (50 permissions/user)
Spatie (all permissions cached)	~2-5 MB (full permission array deserialized)
laravel-permissions-redis	~50-100 KB (only current user's set)

The difference grows with the total number of permissions in your system. Spatie loads all permissions regardless of which user is making the request. laravel-permissions-redis only loads what's relevant to the current user.

The visualization

Here's how to think about the performance difference at different scales:

Permission checks per request
    |
    |  Spatie (warm)      Redis (warm)
    |  ~~~~~~~~~~~~       ~~~~~~~~~~~~
  5 |  Fast enough        Fast
 15 |  Fine               Fast
 30 |  Noticeable          Fast
 50 |  Slow               Fast
100 |  Very slow           Fast
    |
    +---------------------------------------->

The key insight: Spatie's performance degrades linearly with the number of checks per request. laravel-permissions-redis stays constant because each check is O(1).

When the difference doesn't matter

Let's be honest about when this optimization is irrelevant:

< 50 req/sec with < 10 checks/request: Both packages are fast enough. Choose based on features, not performance.
Read-heavy, rarely-changing permissions: If permissions never change, Spatie's cache stays warm indefinitely. The invalidation advantage disappears.
Single-user CLI or queue jobs: No concurrent cache stampede risk. Cold start cost is a one-time hit.

When the difference is critical

High-traffic APIs: 200+ req/sec where each request checks 10+ permissions
Multi-tenant SaaS: Thousands of users with different permission sets
Real-time applications: WebSocket servers or Octane workers with long-lived processes
Frequent permission changes: Admin panels where roles/permissions are edited regularly
Large permission matrices: 100+ permissions per user across multiple roles

Reproducing these benchmarks

The benchmark application is open source:

git clone https://github.com/scabarcas17/laravel-permissions-redis-benchmark
cd laravel-permissions-redis-benchmark
composer install
php artisan migrate --seed
php artisan benchmark:run

It generates a side-by-side comparison report with your specific hardware. I encourage you to run it yourself -- your numbers will vary based on Redis/MySQL latency, PHP version, and hardware.

Conclusion

The performance difference between database-backed and Redis-backed permission checking comes down to three architectural decisions:

O(1) vs O(n) lookups -- Redis SISMEMBER vs array scanning
Surgical vs nuclear invalidation -- rewarm one user vs flush everything
Dual-layer caching -- in-memory + Redis vs cache driver only

For small applications, these differences are academic. For high-traffic Laravel APIs, they're the difference between adding more servers and optimizing what you have.

The package is free, MIT-licensed, and available on Packagist:

composer require scabarcas/laravel-permissions-redis

Check out the GitHub repo for documentation, migration guides, and the full test suite. Issues and PRs are welcome.

All benchmarks were run on a MacBook Pro M2 with local Redis and MySQL. Production numbers will vary based on network topology and hardware. The benchmark repository includes instructions for reproducing on your own hardware.

Why I Built a Redis-Backed Alternative to Spatie Permissions

Sebastian Cabarcas — Tue, 31 Mar 2026 16:51:50 +0000

If you've worked with Laravel for more than a week, you've probably installed spatie/laravel-permission. It's the default answer to "how do I add roles and permissions to my app?" -- and for good reason. It's well-maintained, well-documented, and battle-tested.

So why did I build laravel-permissions-redis?

Because at scale, the database becomes the bottleneck.

The problem I kept hitting

I was building a multi-tenant SaaS with a Laravel API serving ~200 requests/second. Each request triggered between 5 and 30 permission checks -- middleware, policies, Blade directives, inline gates. With Spatie, every single one of those checks was hitting the cache driver, deserializing a full array of permissions, and scanning it linearly.

On cold cache? Full database reload. On cache invalidation? Forget everything, rebuild from scratch on the next request. With 50,000+ users, that "next request" was painfully slow.

The numbers looked something like this:

Scenario	DB queries (Spatie)	DB queries (Redis approach)
1 request, 33 checks	5	1
10 requests	14	10
50 requests	54	50

After the initial cache warm, all permission checks with Redis resolve with zero additional database queries. Not "fewer queries" -- zero.

Why not just use Redis as a Laravel cache driver?

That was my first thought too. Set CACHE_DRIVER=redis and let Spatie's existing cache layer benefit from Redis speed.

It helps, but it doesn't solve the architectural problems:

O(n) lookups. Spatie serializes all permissions into a single cached array. Each hasPermissionTo() call deserializes that array and scans it. With 200 permissions per user, that's 200 comparisons per check.
Nuclear invalidation. When any permission changes, Spatie calls forgetCachedPermissions() which drops the entire cache. Every user pays the cold-start penalty on their next request.
No in-memory request cache. Even with Redis as the cache driver, Spatie hits Redis on every single check within the same request. If your middleware checks 5 permissions, that's 5 Redis round-trips.

The architecture of laravel-permissions-redis

I took a fundamentally different approach using Redis SET data structures:

auth:user:{userId}:permissions  ->  SET {"posts.create", "posts.edit", "users.view"}
auth:user:{userId}:roles        ->  SET {"admin", "editor"}
auth:role:{roleId}:permissions  ->  SET {"posts.create", "posts.edit"}

Each permission check is a single SISMEMBER command -- O(1) time complexity, regardless of how many permissions exist. No deserialization, no scanning.

The dual-layer cache

Request hits middleware
    -> Check in-memory PHP array (zero I/O)
    -> Miss? Check Redis SET (one SISMEMBER)
    -> Miss? Query database, warm Redis, populate in-memory cache

Within a single request, the first check might hit Redis. Every subsequent check for the same user resolves from a PHP array in memory -- no I/O at all.

Surgical invalidation

When a user's permissions change, we don't flush everything. We rewarm only the affected user's Redis SETs. Everyone else's cache stays warm. No cold-start stampede.

// Spatie: nuke everything
Cache::forget('spatie.permission.cache');

// laravel-permissions-redis: rewarm only what changed
$repository->warmUserCache($userId);

Feature parity (and beyond)

I didn't want this to be a "fast but limited" alternative. The goal was full feature parity with Spatie plus the features I kept needing:

Drop-in API compatibility

// These work exactly the same as Spatie
$user->assignRole('admin');
$user->givePermissionTo('posts.create');
$user->hasPermissionTo('posts.edit');
$user->hasAnyRole('admin', 'editor');

Same method names, same Blade directives (@role, @hasanyrole), same middleware (permission:posts.create). Migrating is mostly swapping a trait and a config file.

Features Spatie doesn't have

Feature	Description
Octane support	Automatic in-memory cache reset between requests in long-lived workers
Multi-tenancy	Redis key isolation per tenant, with built-in Stancl/Tenancy resolver
Wildcard permissions	`posts.*` matches `posts.create`, `posts.edit`, etc. via `fnmatch()`
Super admin role	One config value to make a role bypass all permission checks
Testing trait	`actingAsWithPermissions($user, ['posts.create'])` -- one-liner test setup
Cache warming CLI	`php artisan permissions-redis:warm` to pre-warm all users on deploy
Seed command	`php artisan permissions-redis:seed` reads from config, supports `--fresh`
Migrate from Spatie	`php artisan permissions-redis:migrate-from-spatie` with `--dry-run`
Fluent guard scoping	`$user->forGuard('api')->hasPermissionTo('posts.create')`

Automated migration from Spatie

This was important to me. If you already have Spatie installed with production data, migration needs to be painless:

# See what would happen without changing anything
php artisan permissions-redis:migrate-from-spatie --dry-run

# Run the migration
php artisan permissions-redis:migrate-from-spatie

The command reads Spatie's tables, creates equivalent records in the new schema, and warms the Redis cache. There's a full migration guide with a method equivalence table and behavior differences.

Multi-tenancy without the headache

Spatie's "teams" feature works but adds a team_id column to every pivot table and requires careful query scoping.

With Redis, tenant isolation is simpler -- prefix the keys:

auth:user:t:{tenantId}:{userId}:permissions

Configuration is two lines:

// config/permissions-redis.php
'tenancy' => [
    'enabled'  => true,
    'resolver' => 'stancl', // or any callable
],

Complete data isolation. No query scoping to forget. No cross-tenant leaks.

Octane: the problem nobody talks about

Laravel Octane keeps your application in memory across requests. Great for performance, terrible for anything that caches state in PHP properties.

Spatie caches permissions in static properties. In Octane, User A's permissions can leak into User B's request if they hit the same worker. The Spatie team acknowledges this and suggests workarounds, but there's no built-in solution.

laravel-permissions-redis listens for Octane's RequestReceived event and resets all in-memory state automatically:

// config/permissions-redis.php
'octane' => [
    'reset_on_request' => true,
],

No leaked state. No workarounds. It just works.

The honest trade-offs

This package is not for everyone. Here's when you should not use it:

You don't run Redis. This package requires Redis. If your stack is MySQL + file cache, Spatie is the right choice.
You need getDirectPermissions() vs getPermissionsViaRoles(). This package merges all permissions into a flat set. If you need to distinguish "was this permission assigned directly or via a role?", Spatie handles that better.
You need to support PHP 8.0 or Laravel 8. This package requires PHP 8.3+ and Laravel 11+.
Authorization isn't your bottleneck. If you're doing 10 requests/second with 3 permission checks each, Spatie is fast enough. Don't add Redis complexity for no measurable gain.

Getting started

composer require scabarcas/laravel-permissions-redis

php artisan vendor:publish --provider="Scabarcas\LaravelPermissionsRedis\LaravelPermissionsRedisServiceProvider"

php artisan migrate

# Optional: warm cache for all existing users
php artisan permissions-redis:warm

Add the trait to your User model:

use Scabarcas\LaravelPermissionsRedis\Traits\HasRedisPermissions;

class User extends Authenticatable
{
    use HasRedisPermissions;
}

That's it. The API is intentionally familiar. If you've used Spatie, you already know how to use this.

What's next

The package is at v3.0.0 with full support for PHP 8.3/8.4, Laravel 11/12/13, and Redis 6/7. The test suite covers UUID/ULID models, Octane workers, multi-tenant isolation, and integration tests against real Redis instances in CI.

I'd love feedback, issues, and PRs. The repo is at github.com/scabarcas17/laravel-permissions-redis.

If you're hitting performance walls with database-backed permissions, give it a try. Your Redis server is already sitting there -- might as well put it to work.

How I Solved Multi-Guard Permission Issues in Laravel with Redis

Sebastian Cabarcas — Mon, 30 Mar 2026 16:11:07 +0000

When working with Laravel applications that use multiple guards (web, api, etc.), I ran into a subtle but critical issue:

Permissions were leaking between guards.

At first, everything seemed fine… until it wasn’t.

The Problem

Imagine this scenario:

A user has a permission under the api guard
You check that permission under the web guard
$user->hasPermissionTo('posts.edit');

And it returns true, even though it shouldn’t.

This happens when your permission system doesn’t properly isolate guards — something that can silently introduce security issues in production.

Why This Happens

Most implementations treat permission names as globally unique:

posts.edit

But in reality, permissions should be scoped by guard, meaning:

web: posts.edit
api: posts.edit

Without that separation, collisions are inevitable.

The Solution

In v2.0.0 of my package (laravel-permissions-redis), I redesigned the permission system to be fully guard-aware.

1. Guard-Scoped Permission Checks

All permission and role checks now accept a guard:

$user->hasPermissionTo('posts.edit', 'api');
$user->hasRole('admin', 'web');

Or fluently:

$user->forGuard('api')->hasPermissionTo('posts.edit');

2. Redis Storage Redesign

Permissions are now stored using this format:

guard|permission

Example:

api|posts.edit
web|posts.edit

This completely eliminates collisions between guards.

3. Smarter Caching

I also improved cache control to make the system more scalable:

rewarmAll() → rebuild cache without flushing
warmPermissionAffectedUsers() → only warm impacted users
getUserIdsAffectedByPermission() → precise impact analysis

4. Performance Improvements

No more full table scans when warming users
Redis config is cached internally
Middleware now resolves the correct guard automatically

Breaking Changes

If you're upgrading:

Methods like hasPermission() now accept a $guard
Redis key format changed → you must flush and rewarm cache

Key Takeaway

Authorization bugs are dangerous because they don’t crash your app — they silently give access.

Fixing guard isolation is not just a “nice to have”, it’s essential for any system with:

APIs + Web apps
Multi-auth setups
Scalable architectures

Final Thoughts

This update was focused on one thing:

Making authorization correct, predictable, and scalable.

If you're dealing with complex permission systems in Laravel, this approach might save you from some very tricky bugs.

I’d love to hear your thoughts or how you're handling permissions in your projects.

Reducing Laravel Permission Queries Using Redis (Benchmark Results)

Sebastian Cabarcas — Tue, 24 Mar 2026 16:32:51 +0000

Laravel permissions work great… until your application starts to scale.

If you're using role/permission checks heavily, you might be hitting your database more often than you think.

In this article, I’ll show you a simple benchmark comparing the default behavior vs a Redis-based approach.

The Problem

In many Laravel applications, permission checks look like this:

$user->can('edit-post');

Looks harmless, right?
But under the hood, this can trigger multiple database queries, especially when:

You have many users
Complex role/permission structures
Frequent authorization checks

At small scale, it’s fine.
At large scale… it adds up quickly.

Benchmark Setup

To test this, I created a simple benchmark comparing:

Default Laravel permissions behavior
Redis-cached permissions

Benchmark repo: https://github.com/scabarcas17/laravel-permissions-redis-benchmark

The idea was simple:

Run multiple permission checks
Measure database queries
Compare performance

Results

Default Behavior

Multiple database queries per permission check
Repeated queries for the same permissions
Increased load under high traffic

With Redis

Permissions cached in Redis
Near-zero database queries after first load
Much faster response times

Key Insight

The biggest issue is not the first query…
It’s the repeated queries for the same permissions.
By caching permissions in Redis, we eliminate redundant database access.

The Solution

To test this approach in a real scenario, I built a small package: https://packagist.org/packages/scabarcas/laravel-permissions-redis

GitHub repo:
https://github.com/scabarcas17/laravel-permissions-redis

This package adds a Redis layer on top of Laravel permissions, reducing unnecessary queries.

When Does This Matter?

This approach is especially useful if your app has:

High traffic
Many permission checks per request
Complex role/permission structures
Performance bottlenecks related to authorization

Final Thoughts

Laravel’s default behavior is solid and works well for most applications.

But if you're scaling and noticing performance issues, caching permissions can make a real difference.

This benchmark is just a starting point—but it clearly shows the impact of reducing repeated database queries.

Feedback

I’d love to hear your thoughts:

Have you experienced performance issues with permissions?
How are you handling caching in your apps?

How I Eliminated Repetitive Permission Queries in Laravel Using Redis

Sebastian Cabarcas — Thu, 19 Mar 2026 19:27:35 +0000

One of the most common performance issues I’ve seen in Laravel applications is related to roles and permissions.

At first, everything works fine.

But as the application grows, authorization checks become more frequent — and suddenly, your database is handling a large number of repetitive queries just to validate permissions.

The Problem
Even when using caching strategies, many applications still:

Hit the database frequently for permission checks
Recompute authorization logic on every request
Struggle under high load scenarios

This becomes especially noticeable in systems with:

Complex role structures
Multiple middleware checks
High traffic

The Idea

Instead of relying on the database (even with caching), I explored a different approach:

Move roles and permissions entirely into Redis

The goal:

Keep authorization in-memory
Eliminate repetitive queries
Improve response times

The Approach

The core idea is simple:

Store roles and permissions in Redis
Resolve all authorization checks from memory
Avoid hitting the database during request lifecycle

This allows permission checks to be:

Faster
More scalable
More predictable under load

The Result

I built a package around this idea:

https://github.com/scabarcas17/laravel-permissions-redis
https://packagist.org/packages/scabarcas/laravel-permissions-redis

It’s designed to integrate naturally with Laravel while replacing repetitive database queries with Redis-based resolution.

When Does This Make Sense?

This approach is especially useful if:

Your app performs frequent permission checks
You are scaling and need better performance
You want to reduce database load

Final Thoughts

Laravel is not the problem — architecture is.

Small decisions like how you handle permissions can have a huge impact as your system grows.

I’d love to hear how others are solving this problem or any feedback on this approach.