Different ways of using UUID in default migrations, will changing it cause problems ?

[Twyar]

Hi,

I am using a fresh installation of Laravel 11 for a new project of mine.
What I wanted to do first is change the default auto-incrementing id on the users table to either UUID or ULID.

The default migrations look like this:
https://github.com/laravel/laravel/blob/11.x/database/migrations/0001_01_01_000000_create_users_table.php

So change the migration from:

Schema::create('users', function (Blueprint $table) {
    $table->uuid('id')->primary();
    // Rest of columns
});

To:

Schema::create('users', function (Blueprint $table) {
    $table->uuid('id')->primary();
    // Rest of columns
});

Now I noticed that the sessions table also uses UUIDs, but it's done by:

Schema::create('sessions', function (Blueprint $table) {
    $table->string('id')->primary();
    // Rest of columns
});

And for the jobs migrations:
https://github.com/laravel/laravel/blob/11.x/database/migrations/0001_01_01_000002_create_jobs_table.php

Schema::create('jobs', function (Blueprint $table) {
    $table->id();
    // Rest of columns
});
Schema::create('job_batches', function (Blueprint $table) {
    $table->string('id')->primary();
    // Rest of columns
});
Schema::create('failed_jobs', function (Blueprint $table) {
    $table->id();
    $table->string('uuid')->unique();
    // Rest of columns
});

Now I would make a pull request for this changing this, but before I do, I wanted to know if there's a specific reason why by default the migrations dont all use

$table->uuid('id')->primary();

Instead of a combination of the following 2:

$table->string('id')->primary();
$table->string('uuid')->unique();

Isn't UUID already pretty much unique ? So why is that defined on that column.
It doesn't really feel streamlined that way I feel like.

Now for myself I change everything to the uuid('id'), and removed the extra incrementing id from the failed_jobs table, but I don't know if this will cause issues later on the road.

[ghost]

int (autoincrement) vs uuid(not timestamp based one) has an order, it is also faster when sorting.
Using UUID (not timestamp based one) instead of auto-increment would need an additional sort by created_at.
Also some devs have imprinted into their heads that it is always a good idea to have an auto-increment as primary key (which I can confirm it is useful on cursor paginate, but not necessarily it needs to be auto-incremented for that, just unique and integer). They might also mention REST because the composed primary key is not common usage.

PS. if you change a PK, you need to change all foreign keys for it in all over the places.