Laravel Sql Dashboard Laravel Package

Product Decisions This Supports

• Internal data access for non-engineers / on-call ops. A self-hosted SQL dashboard with saved queries, shared dashboards and checks (alerting) is a candidate to replace ad-hoc "ping an engineer to run this query" workflows. This release hardens exactly the risk that decision hinges on.
• Build vs. buy for a query console. The scope is narrow (read-only queries, saved/shared queries, dashboards, threshold checks, Slack/mail alerts). Adopting a v0.1.x package is cheaper than building — but only if you accept ownership of the security review, because the package's safety model is deny-lists plus DB-privilege checks, not a SQL parser.
• Feature/roadmap scoping. v0.1.1 tells you where the product is immature: authorization is coarse ("anyone with the edit gate can edit or delete shared queries, dashboards and checks"), alert channels are partially unverified (Slack tested only against a faked HTTP client; mail alerts are in the art), and the default gate is local only. If your roadmap needs per-team/per-row access control or write queries, this package is not the substrate — plan a different architecture rather than a fork.
• Security posture as a launch gate. The v0.1.1 fixes are a genuine bypass class (quoted/bracketed/back-ticked/schema-qualified function names, U&"..." escapes) plus privilege-check gaps (PostgreSQL file/replication/signal roles, dblink, foreign-server USAGE, standby superusers, MySQL PROCESS). Treat "expose this dashboard to anyone but local" as a decision requiring a documented DB-role hardening standard, not a config flag.
• Reliability/cleanup behavior worth knowing before rollout. Advisory locks and GET_LOCK locks outlive a rolled-back transaction; v0.1.1 releases them after each query. Prior versions could leak session locks — relevant if you point this at a pooled production connection.
• Vendor/upstream signal. The find came from an internal code review, and the release explicitly downgrades the README's claims ("a tokenizer, not a full SQL parser"). That candor is a positive maintenance signal, but it also confirms the guardrail is best-effort defense-in-depth, not a sandbox.

When to Consider This Package

Consider adoption when:

• The use case is internal, low-blast-radius tooling: engineers, support or analysts running read-only SELECTs against a small number of known connections.
• You can run it local/staging-first and keep the default app()->environment('local') gate until you have consciously designed the surrounding access control.
• You can give it a dedicated least-privilege DB user — no SUPER/FILE/PROCESS on MySQL, no pg_read_server_files/pg_write_server_files/pg_execute_server_program/pg_signal_backend membership, no dblink/foreign-server USAGE, non-superuser, on PostgreSQL. The package checks these, but your DB grants are the actual control.
• You are on PostgreSQL, MySQL or SQLite and want the SQLite read-only authorizer benefit (requires PHP 8.5+).
• You want saved queries + dashboards + threshold checks with alerts as a single small dependency, and can live with mail alerts and unverified Slack integration — or can verify Slack yourself against a real workspace.
• You accept pinning and prompt upgrades: expect more security patches in the 0.1.x line, and treat "upgrade on release" as an operational commitment, not a nice-to-have.

Look elsewhere when:

• The audience is customers, prospects or anyone outside your trust boundary — the edit gate is all-or-nothing and anyone with it can modify or delete shared artifacts.
• You need per-user, per-team or per-row authorization, query auditing to a compliance standard, or approval workflows. That is a different product; build on your BI/warehouse layer (or a governed query engine) instead.
• You need write queries, DDL, or arbitrary multi-statement execution — this is designed and hardened around read-only.
• You require an audited, parser-level SQL safety boundary. The README now says plainly it is a tokenizer; if your threat model needs semantic SQL validation, this is the wrong layer.
• Your platform is not PHP 8.5-capable and SQLite read-only enforcement at the engine level matters to you.
• You have no appetite for 0.x churn or for owning a security review of a component that executes user-supplied SQL.

How to Pitch It (Stakeholders)

To executives: This is a small, self-hosted internal tool that lets trusted staff query databases and set up alerting without going through engineering each time. It is cheap to adopt and cheap to remove. The tradeoff is that it is early-stage software (v0.1.x) that runs SQL, so it is security-sensitive by nature and must stay behind our network boundary and a restricted database account. The just-published v0.1.1 is a security patch — it closes a way to sneak dangerous database functions past the built-in deny-list and tightens which database privileges are acceptable. That is a good sign (the project reviews and fixes its own guardrails) and a warning (the guardrails are heuristics, not a sandbox).

To engineering: Adopt it as an internal read-only console, not as a platform. Concretely: pin the version, upgrade to v0.1.1 immediately if 0.1.0 is anywhere, keep the default local-only gate until you have designed access control, and provision a dedicated DB role that satisfies the package's privilege checks rather than relying on them. Two known rough edges to plan around: the edit gate is coarse (anyone who can edit can delete shared queries, dashboards and checks), and Slack alerting has only been exercised against a faked HTTP client — validate it against a real workspace before promising it to anyone. If we later need per-team permissions, per-row filtering or write access, that is a new design, not a config change.

To security/ops: The stated safety model is a tokenizer-based deny-list plus connection privilege checks plus (on SQLite with PHP 8.5) the authorizer in read-only mode. Treat the deny-list as defense-in-depth over database grants, not as the boundary. v0.1.1 also fixes leaked session locks — PostgreSQL advisory locks and MySQL GET_LOCK survive transaction rollback — so pooled production connections should be re-tested if we had run 0.1.0.