File Sql Logger Bundle Laravel Package

Technical Evaluation

Architecture fit. This package sits at the Doctrine DBAL layer, implementing the SQLLogger interface to capture mutating statements (INSERT/UPDATE/DELETE and DDL) rather than the read-heavy traffic most Laravel apps emit. That is a narrow seam in a typical Laravel codebase: Eloquent and the Query Builder talk to PDO directly, and only reach Doctrine when a connection is explicitly doctrine-backed (or when a third-party package routes through doctrine/dbal). So the realistic fit is a Laravel service that either uses Doctrine ORM/DBAL alongside or instead of Eloquent, or one with a compliance/audit requirement specifically on write statements. For a standard Eloquent-first application this is duplicative of Laravel's own DB::listen / query-event facilities at a higher integration cost.

Integration feasibility. Mechanically simple: a Composer install, a config publish, and attaching the logger to a DBAL connection's configuration. There is no schema change, no service provider contract to satisfy beyond Laravel's package auto-discovery, and no runtime dependency on a queue or external service. The friction is configuration placement, not engineering effort — a spike should be measured in hours, not sprints.

Technical risk. The dominant risk is the interface itself. Doctrine\DBAL\Logging\SQLLogger was deprecated in DBAL 3.x and removed in DBAL 4.0; a v1.0.0 built on it has a built-in end-of-life clock tied to whatever DBAL major the host application pins. If the app is on DBAL 3, the package works but inherits a deprecation; if the org plans a DBAL 4 upgrade, this package becomes a blocker rather than an enabler. Secondary risks: mutating-statement logging captures literal parameter values, which is a PII and secrets-in-logs exposure (emails, tokens, free-text columns written on every UPDATE); synchronous logging on the write path adds latency to exactly the queries that already hold locks; and log volume scales with write throughput, not read throughput, so cost estimates based on existing query logs will be wrong. The release note is one line with no supported-version matrix, no changelog history, and no indication of test coverage or maintainer backing — evidence confidence is low and the assessment should be treated as provisional.

Key questions. Which DBAL majors and which Laravel versions are supported and CI-tested? Is there a DBAL 4 / middleware-based path on the roadmap, and what is the stated deprecation policy? Does it log bound parameters, and is there built-in redaction or a masking hook? Is logging synchronous and can a logger failure throw into the write path? What is the sampling/filtering story for high-write tables? Who maintains it — internal team, single author, or vendor — and what is the release cadence? Does it coexist with Laravel's own query listener without double-counting?

Integration Approach

Stack fit. Adopt only where the connection is genuinely doctrine-backed. If the application is Eloquent-first, the correct decision is to decline this package and implement write-statement auditing through Laravel's query event listener, which reaches the same statements without the DBAL coupling. If the application already uses Doctrine for a bounded context — reporting, legacy module, or an audit-sensitive subsystem — scope the package to that connection alone rather than registering it globally.

Migration path. Greenfield: there is no incumbent to migrate from and no data migration. The migration that matters is the exit path, and it should be designed before adoption: an abstraction seam (a single wrapper or config flag) that lets the logger be swapped for a DBAL 4 middleware or a Laravel listener without touching call sites. Treat the SQLLogger dependency as a bet with a known expiry date, not a permanent foundation.

Compatibility. Pin the DBAL and Laravel versions explicitly in the spike and record the tested matrix. Verify behaviour against the exact DBAL minor in production today, and confirm the package does not force a DBAL downgrade in the lockfile. Check PHP version support against the platform baseline, and verify no conflict with existing Doctrine logging or profiling middleware in dev environments (Debugbar, Telescope) which can double-log or mask output.

Sequencing. (1) Half-day spike on a branch: install, register on one non-production doctrine connection, confirm mutating statements are captured and reads are excluded as intended. (2) Security review of what lands in logs — sample real payloads and check for PII. (3) Enable in staging behind a feature flag with redaction and sampling applied; measure latency delta on the write path and log volume per day. (4) Production rollout scoped to the one connection, with an alert on logger errors. (5) Book a review at the DBAL upgrade boundary to decide replace-or-retire. Do not sequence this ahead of a compliance requirement that actually demands it — if no team has asked for write-statement auditing, the correct outcome of the spike is a documented "not now."

Operational Impact

Maintenance. Low day-to-day effort, but a real and dated maintenance liability: the package carries the DBAL 3 deprecation forward, so someone must own the DBAL 4 migration conversation. Budget a recurring line item — a dependency-review check each time DBAL or Laravel majors move — rather than assuming it is set-and-forget. A single-author package with a one-line changelog also implies a fork risk if the upstream goes quiet.

Support. Internal support surface is small (config plus one registration), but dependency support is the exposure. Confirm there is a named internal owner, and that the team can read the source if needed — the package is small enough that forking or reimplementing is a realistic fallback rather than a crisis, which materially lowers the support risk.

Scaling. Log volume scales with write throughput. On a write-heavy service (high-frequency updates, job queues, event sourcing) this can dominate log spend quickly; sampling and per-table filtering are prerequisites, not refinements. The synchronous write-path logging also compounds under lock contention, so measure p99 on write statements, not average. Retention policy should be set at rollout, not after the first invoice.

Failure modes. Three to design against: (a) logger throws or blocks and takes down writes — must be wrapped so logging failures are swallowed and counted, never propagated; (b) PII or credentials land in logs — requires redaction before production, with a test asserting the masking; (c) silent gaps — if the doctrine connection is bypassed by direct PDO usage, auditors will believe coverage exists when it does not, so document the exact scope of what is and is not captured. Add a heartbeat metric on logger invocations so "no logs" is distinguishable from "no writes."

Ramp-up. Low for any PHP developer: an hour to read the source and the registration, half a day to a working local setup with redaction. The cost is not learning the package but learning the org's log-retention and PII policy and getting sign-off, which is where the calendar time actually goes.