A meta-schema for a Laravel admin panel. Most of its tables configure other application tables instead of holding domain data, so the data dictionary forms the spine with RBAC, menus, and settings hanging off it.
What this Voyager schema covers
BREAD/CRUD definitions for any Eloquent model
Per-field form and listing configuration
Role- and permission-based access control
Nested navigation menus
Per-locale field translations
Grouped key/value application settings
A few decisions the diagram can't show:
data_types holds one row per managed model and data_rows one row per field, so this schema describes the columns of tables that live elsewhere.
A field's Browse/Read/Edit/Add/Delete visibility and its form input type are stored as data on data_rows, so a column's admin UI is configured, not coded.
translations is string-keyed by table_name, column_name, and foreign_key and unique per locale, so any column is translatable with no foreign key pointing at it.
The details column on data_types, data_rows, and settings is text holding JSON config read at runtime, opaque to SQL. Managed-model relationships live in data_rows.details too, so the real app's relationship graph never shows up on this diagram.
users.role_id sets one default role while the user_roles pivot grants the rest, so RBAC reads from both a pointer and a pivot.
menu_items.parent_id self-references the table to nest sub-menus.
Good fork target when you want a database-driven admin layer instead of a hand-built dashboard. The catch: field behaviour and model relationships both hide in JSON details blobs, so the columns alone won't tell you how a screen renders.
Laravel Admin Package — Voyager is the open-source "missing Laravel admin" panel. It drops into an existing Laravel app and turns its database tables into managed admin screens.