Laravel Er Diagram Generator Laravel Package

Product Decisions This Supports

• Feature scoping and sizing on data-heavy work. Before committing to anything that touches billing, permissions, orders, or multi-tenant scoping, generate an ERD to see which models and relationships are actually in play. This turns "how big is this, really?" from a multi-day archaeology exercise into a ten-minute answer, and gives you a defensible input for roadmap sizing rather than a gut-feel estimate from the loudest engineer in the room.
• Roadmap sequencing and schema-debt prioritization. The diagram exposes orphan models, over-connected tables, and polymorphic hotspots. Patterns like a dozen tables hanging off a single users record are leading indicators of where delivery will slow down over the next several quarters — concrete evidence for carving a "clean up the data model" workstream out of the perpetually deferred backlog.
• Migration blast-radius assessment. With 6.0.0's ignore_columns and column types pulled from Laravel's own getColumns(), the diagram shows the tables and relationships a change touches. That supports go/no-go calls on shared-table refactors and shared-schema integrations, and lets you push back on estimates that assume a change is local when it isn't.
• Build vs buy. This is a free, MIT-licensed dev dependency versus a paid ERD, data-catalog, or lineage platform. Buy only when the need is genuine enterprise data lineage, governance, or cross-system cataloging. If the need is "document what exists in our Laravel app so we can plan against it," this is a near-zero-cost adopt — not a build-vs-buy decision worth spending cycles on.
• Onboarding and documentation debt reduction. Code-derived diagrams don't rot the way hand-drawn ones do. Where schema knowledge lives in two engineers' heads, this is the cheapest risk transfer available: no vendor contract, no implementation project, no ongoing owner.
• Stakeholder-facing architecture communication. 6.0.0's model aliasing lets diagrams display business vocabulary ("Customer" rather than App\Models\CustAcct) — the difference between an artifact engineers tolerate and one you can put in front of product, design, or leadership in a planning review.

When to Consider This Package

• Adopt when you run a Laravel application with a meaningful Eloquent layer — roughly 30+ models is the practical threshold where manual diagramming stops being viable; you want developer-owned diagrams that stay current with the codebase at no licensing cost; you need a shared artifact for architecture reviews, onboarding, or refactor planning; or you are on, or moving to, Laravel 13.
• Upgrade to 6.0.0 specifically when you want Laravel 13 support, accurate column types from Laravel's schema introspection, ignore_columns to suppress audit/soft-delete and PII-adjacent fields, or aliases for stakeholder-legible diagrams. Treat it as a genuine major bump: audit composer.json constraints and diff generated output on a branch before rolling out.
• Look elsewhere when you need diagrams reverse-engineered from the actual database rather than from models (this reflects application code and can silently diverge from true schema); you need interactive, editable, or collaborative modeling with lineage and governance; you're on a non-Laravel or heavily mixed stack; your schema leans on polymorphic or runtime-resolved relations that model introspection will under-represent; or your model count is very large (200+) and you need scoped, multi-diagram output rather than one dense global graph.
• Sequencing note: this is not a roadmap item and should not consume a planning slot. It is low-priority maintenance work a single engineer lands in a sprint alongside feature delivery — no coordination overhead, no release-train dependency, no user-facing change.

How to Pitch It (Stakeholders)

To executives: This is a free, open-source developer tool that automatically generates a picture of our application's data model directly from the codebase. It costs nothing to license, takes well under a day of engineering to adopt, and pays back three ways: faster onboarding for new engineers, lower risk on schema changes because we can see exactly what a change touches before we make it, and a shared diagram we can use in planning conversations instead of stale documentation nobody trusts. The current release keeps us aligned with Laravel 13 and adds controls that make the output readable for non-engineers. To be clear about scope: this is not a data-governance or enterprise catalog platform — if we later need lineage across multiple systems, that's a separate buy decision with its own business case. Right now this closes a documentation gap at essentially zero cost.

To engineering: It's a dev-only artisan command (php artisan erd:generate) that introspects Eloquent models and relationships, emits Graphviz DOT, and renders PNG/SVG. Nothing touches the request path — no runtime footprint, no production dependency, no blast radius. 6.0.0 brings model aliasing for cleaner diagrams, column-type accuracy via Laravel's getColumns(), an ignore_columns option that finally makes output reviewable (drop created_at/updated_at/deleted_at and PII-adjacent fields), and Laravel 13 compatibility. It does require Graphviz installed locally and in CI, so pin that version in the CI image — that's the most likely source of "it doesn't work on my machine" tickets. Because it's a major bump, the acceptance gate is: check composer.json constraints, run both 5.x and 6.0.0 against the same database, and diff the .dot output — classify any diffs as cosmetic, expected, or suspicious before merging. Adoption order: publish and tune the config, commit or CI-generate the artifact so it doesn't rot, then write a short internal README covering the Graphviz prerequisite and the baseline ignore_columns list. One caveat worth repeating: diagrams reflect models, not the database — they're a navigation aid, never the source of truth.