The default migration set every new Laravel app ships with, before any domain models are added. It is three loosely-coupled groups — authentication, cache, and queue. The one relationship drawn, sessions → users, is a convention rather than a database-level foreign key; Laravel declares none and leaves referential integrity to the application.
What this Laravel schema covers
User accounts and login credentials
Password reset token storage
Database-backed session storage
Key/value cache and atomic locks
Pending, batched, and failed queue jobs
A few decisions the diagram can't show:
sessions.user_id references users by convention only — it is a nullable indexed column, not a real foreign key (foreignId() without ->constrained()), so a session is written before login and survives with no users row.
password_reset_tokens uses email as its primary key, no surrogate id — one pending reset per address, overwritten on the next request.
The jobs time columns and cache.expiration are integer Unix epochs, not timestamps, so the worker and cache compare raw integers when checking what is due or expired.
job_batches.failed_job_ids is a longText JSON array of job UUIDs, so a batch's progress updates atomically in one row rather than a join table.
failed_jobs carries both an auto-increment id and a separate uuid; the integer is local, the UUID is the portable handle the queue retries against.
Clone this as the baseline before adding your own models. Beyond the conventional sessions → users link, the graph fills in once you add domain tables and constrain them yourself.
Default schema for a new Laravel app — The stock database tables a fresh Laravel app ships with. These are the framework's built-in auth, cache, and queue storage, not an application domain.
