Laravel Dibi Laravel Package

Product Decisions This Supports

• Build vs. buy for the data-access layer. laravel-dibi remains glue, not an ORM: it wires the Dibi database abstraction library into Laravel's container, config, and artisan workflow. The decision it informs is whether to standardise on Dibi's lightweight query builder + profiler instead of writing bespoke query infrastructure or forcing everything through Eloquent.
• Build vs. buy for an internal DB-inspection surface — now a real decision. v1.0.4's release notes make concrete what earlier notes only implied: the package ships a web dashboard with a connection selector (scoped to the app's configured database.connections), table/index metadata objects (TableIndex and peers), a repository layer with a tested factory (DatabaseRepositoryFactory) covering all three drivers, and a published-asset check. That is a small, self-hosted database browser. If "give engineers/ops a read-only view of schema and indexes without a paid DB client" is on the roadmap, this is a candidate rather than a from-scratch build.
• API-stability posture has changed. The 0.x caveat in the prior assessment ("surface is still settling") no longer applies as written — the package is now on 1.0.x. A 1.x line is a maintainer commitment to semver, which is the signal the previous assessment asked for before adopting. Confirm the 0.7 → 1.0 changelog for the actual breaking-change list; this review only covers the 1.0.3 → 1.0.4 patch step.
• Operational-resilience decisions. The connection-recovery fix is decision-relevant, not just a bugfix: a remembered, now-unconfigured connection could wedge the dashboard into a permanent 500 with no in-UI escape (the selector lived on the broken page). That failure mode should be considered when deciding whether to expose this dashboard beyond a trusted operator group, and whether to add an external health check for it.
• Input-validation / least-privilege posture. The same fix makes an unconfigured connection selection rejected rather than remembered. That is a small hardening win: the dashboard cannot be steered at an arbitrary DSN by whoever can reach it.
• Observability/debuggability roadmap. Dibi's profiler and query tracing remain the main differentiator, directly relevant to slow-query visibility, N+1 diagnosis, and production debugging. Unchanged by this release.
• Performance/payload hygiene. The TableIndex duplication fix removes roughly 40% of the index payload on every dashboard load (each index was serialised twice, mapped and raw). Minor, but it is a real regression fix for anyone who has already shipped the dashboard.
• Laravel upgrade timing. Laravel 13 support (from v0.7.0) still gates the upgrade calendar: Laravel 13 adoption can proceed only once this dependency is confirmed on 13 in your environment.
• Front-end supply-chain hygiene. The Vite 8.x bump (v0.7.0) resolved security advisories; v1.0.4 reports no asset changes since v1.0.3. Security-maintenance data point for the asset pipeline, not a Dibi feature.
• Not supported by this release: no new product capabilities, no API or data-model changes, no deprecations. v1.0.4 is a bugfix-and-test-coverage patch. Its strategic weight comes from the 1.x version line it sits on, not from its own contents.

When to Consider This Package

Consider it when:

• You want a lightweight SQL builder/abstraction layer rather than a full ORM, and the team already knows or is willing to learn Dibi.
• Query-level observability (profiler, backtraces, per-query timing) matters more than Eloquent ergonomics.
• You have reporting/analytics-style or hand-written SQL that fights Eloquent, and you want it first-class rather than wrapped in DB::raw.
• You want a self-hosted, read-only schema/index dashboard for internal use and would otherwise buy a DB client or build one — the connection selector, table metadata, and three tested drivers now make that a defensible scope.
• You need a stable public API before adopting. The 1.x line materially answers this; the previous 0.x objection should be retired, subject to reading the 0.7 → 1.0 changelog for the breaking changes that shipped in that step.
• You are on, or planning, Laravel 11–13. On Laravel 11+ the service provider must be registered in bootstrap/providers.php — verify this rather than assuming package auto-discovery covers it.
• You are comfortable with a small-maintainer dependency and can vendor/pin it. The added test coverage (connection endpoint, dashboard JSON contract, published-asset check, repository factory, SQLite repository) is a genuine quality signal and partially de-risks this, but it does not change the bus factor.

Look elsewhere when:

• Your domain model is Eloquent-centric (relationships, model events, factories, policies). Mixing a second data layer adds cognitive and review cost that usually outweighs the benefit.
• You need paid support, an SLA, or a large contributor base — still a single-maintainer package, so keep an exit path (Dibi is usable directly without the Laravel wrapper).
• You rely on Laravel migrations/seeders tied to Eloquent or expect ORM-grade schema tooling.
• You intend to expose the dashboard outside a trusted network. It renders schema and index metadata from live connections; treat it as an internal operator tool with access control in front of it, and health-check it so a wedged connection (the pre-1.0.4 failure mode) is detected rather than reported by users.

Upgrade action for v1.0.4: no php artisan dibi:publish needed — the maintainer states there are no asset changes since v1.0.3, which supersedes the blanket "re-run publish" guidance in the previous assessment. Apply it as a routine patch, but do the two checks that cost nothing: confirm the provider is registered in bootstrap/providers.php on Laravel 11+, and if you run the dashboard, verify the connection selector now refuses an unconfigured connection name and that a stale remembered selection recovers instead of 500ing. For anyone still on 0.7.x, plan the 0.7 → 1.0 upgrade as its own ticket and read that changelog first — it is the step that carries the breaking changes, not this patch.

How to Pitch It (Stakeholders)

For executives (one paragraph). This is a patch release of a small integration package that lets Laravel applications use a lightweight SQL layer instead of, or alongside, Eloquent. It fixes a bug that could make the package's built-in database dashboard fail permanently on every request until a cache was cleared, removes a duplicated chunk of data from each dashboard load, and adds test coverage. The more important fact is contextual: the package has moved to a stable 1.x version line, which was the main hesitation in the earlier review. Adopting it remains a modest, reversible architectural choice that buys better query debugging, less framework coupling, and a usable internal schema view, at the cost of depending on a single-maintainer library. Recommendation: the stability objection is now resolved; allow it where teams already have the skills, keep it version-pinned, and do not let it become a blocker on the Laravel upgrade path.

For engineering (bullets).

• What changed: recovery from a remembered-but-unconfigured database connection (previously a permanent 500 on every dashboard request, unfixable from the UI); such selections are now rejected outright; TableIndex no longer serialises each index twice (~40% of index payload per dashboard load); tests added for the connection endpoint, dashboard controller and its JSON contract, the published-asset check, DatabaseRepositoryFactory, and the SQLite repository — completing coverage of all three drivers.
• Upgrade cost: none. No breaking changes, no asset changes since v1.0.3, so no dibi:publish step. Still confirm provider registration in bootstrap/providers.php on Laravel 11+.
• Why we'd use it: thin abstraction over PDO with a genuinely useful query profiler; good fit for complex/reporting SQL and for teams that find Eloquent heavyweight for read paths.
• Why the assessment changed: the 0.x "API not settled" objection is retired — 1.x is a semver commitment. Read the 0.7 → 1.0 changelog before assuming the upgrade is free from 0.x.
• Risks to accept explicitly: single maintainer; a second data-access idiom in the codebase; a live dashboard that reads real schema and must be network-restricted and health-checked. Mitigate with a pinned version, an ADR recording the choice, access control in front of the dashboard, and a tested fallback to plain Dibi or the Laravel query builder.
• Ask: a short timeboxed spike on one non-critical service to validate the Laravel 13 path, the provider registration, and the dashboard's behaviour when a connection is removed from config — then gate wider adoption on that result.