Best Practices for Non-Deterministic IDs in Laravel

For huge datasets, I prefer using ULID. They are time-based and monotonic, so indexing works well.

You can read more about ULID here: https://github.com/ulid/spec

Laravel has native ULID generation support, just use Str::ulid(). Laravel also has with a HasUlids trait that works the same as the HasUuids one.

Thanks for the wonderful suggestions, guys!

@snapey I was thinking this as well. The only downside I see is when performing basic Eloquent operations like Model::find($id). It would be more convenient if it used the UUID or HashID column under the hood. Without making the UUID column the primary key in the database. Currently, I would need to do something like Model::where('uuid', $id) instead. Do you think this approach is feasible?

@rodrigo.pedra I will definitely give ULID a look. Thanks for the suggestion!

Hi @martinbean,

Looks great! How do you handle generating the ULID when a new record is inserted into the database? Is it something like this?

app/Models/MyModel.php

protected static function boot()
    {
        parent::boot();

        static::creating(function ($model) {
            $model->ulid = Str::ulid();
        });
    }

Note: I used ChatGPT to help structure parts of this explanation, but the approach described is from my actual production experience.

Laravel 12.x supports UUIDv7 out of the box (and Laravel 11.x introduced it). However, if you want to use both UUID7 and ULID together on the same model, you'll need a custom solution.

✅ Internal vs. External Identifiers

Using UUIDv7 for primary keys (e.g., id) is an excellent choice—especially for scalable applications. UUIDs are globally unique and make tasks like data merging and system interoperability much safer by minimizing the risk of key collisions.

One of the key advantages of using UUIDs as internal identifiers is that you can perform direct database operations without relying solely on APIs. This encourages cleaner, more decoupled API design.

However, UUIDs (especially v7) are long and not user-friendly. Therefore, I strongly recommend not exposing UUIDs to end users. Instead, use ULIDs for public-facing IDs.

For example:

• Use id (UUIDv7) internally for primary keys, foreign keys, and unique constraints.
• Use public_id (ULID) externally in URLs, APIs, and UI displays.

This separation protects internal infrastructure and keeps your system's internals abstracted from external consumers.

🛠 CRUD Operations and Routing

Always expose and interact with the public_id for all CRUD operations. This adds a slight abstraction layer but helps shield internal identifiers and improves system design.

Laravel allows you to customize route model binding to use public_id:

public function getRouteKeyName(): string
{
    return 'public_id';
}

⚖️ Performance Considerations

It's true that UUIDs and ULIDs can be slightly slower than auto-incrementing integers due to their size and index performance. However, the benefits—global uniqueness, scalability, and flexibility—far outweigh these drawbacks, especially for distributed systems.

UUIDv7 offers the additional benefit of lexical sortability. Because it encodes a timestamp in milliseconds, newly generated UUIDs are naturally ordered. This improves index locality and query performance compared to UUIDv4.

🔄 Data Portability

Another major benefit of UUIDs: they're ideal for syncing data across environments or services. Since UUIDs are unique across systems, there's very little risk of collision when importing or migrating data.

---

✅ Recommended Strategy

• Internal IDs (id, FK, PK, UK): Use UUIDv7. Never expose.
• External IDs (public_id): Use ULID. Always expose.

---

🧩 Custom Trait: HasUuidsAndPublicId

Since Laravel does not currently support using both HasUuids and HasUlids traits together in a single model, you can define a custom trait to achieve this:

<?php
namespace App\Traits;

use Illuminate\Database\Eloquent\Concerns\HasUuids;
use Illuminate\Support\Str;

trait HasUuidsAndPublicId
{
    use HasUuids;

    /**
     * Boot the trait to auto-generate public_id before creation.
     */
    public static function bootHasUuidsAndPublicId(): void
    {
        static::creating(function ($model) {
            if (empty($model->public_id)) {
                $model->public_id = $model->newPublicId();
            }
        });
    }

    /**
     * Generate a lowercase ULID for public_id.
     */
    public function newPublicId(): string
    {
        return strtolower(Str::ulid());
    }

    /**
     * Use public_id as the route model binding key.
     */
    public function getRouteKeyName(): string
    {
        return 'public_id';
    }
}

Use this trait on your models:

class User extends Model
{
    use HasUuidsAndPublicId;

    protected $table = 'users';
}

⚠️ Note: Trying to use both HasUuids and HasUlids traits simultaneously, like this:

use HasUuids, HasUlids;

will not work, as Laravel does not currently support combining both traits on the same model.

---

Final Thoughts

For scalable Laravel applications:

• Use UUIDv7 for internal keys.
• Use ULIDs for external identifiers.
• Encapsulate this logic in custom traits like HasUuidsAndPublicId.

This strategy balances performance, security, and maintainability, and is already adopted by many large-scale systems.

Instead of expose that long ugly string to client, i will make it shorter

<?php

declare(strict_types=1);

if (! function_exists('genHash')) {
    function genHash(): string
    {
        return hash('crc32b', Str::uuid()->toString());
    }
}

genHash(); // '1ddfdbf6'