Db Laravel Package

Product Decisions This Supports

• Build vs. buy for the data-access layer. Every PHP product eventually answers "PDO, a thin wrapper, or a full ORM?" This package is the thin-wrapper option: driver-agnostic SQL access with safe-by-default querying. Adopting it is a days-not-weeks decision that avoids writing and maintaining an in-house PDO abstraction.
• ORM scope on the roadmap. For products whose data model is mostly straightforward SQL — internal tools, CLIs, small APIs, back-office services — this lets you defer ORM adoption and the schema/relationship modeling work that comes with it. It buys room on the roadmap rather than adding a feature.
• Database portability. Driver-agnostic access supports a MySQL-in-prod / SQLite-in-tests split, or a later MySQL→PostgreSQL migration, without rewriting the persistence layer. That is a risk-reduction decision, not a feature.
• Security posture. Prepared-statement-style safe access moves SQL injection from "developer discipline" to "default behavior," which is a concrete line item in security reviews and compliance conversations.
• Licensing and procurement. MIT removes legal friction and vendor-negotiation time; the decision collapses to engineering evaluation only.
• Dependency risk budgeting. With ~46 stars and zero known dependents, this is an unproven dependency. That supports a deliberate posture: pilot in a containment boundary, vendor the source, or plan a fork — rather than putting it on a critical path.

When to Consider This Package

Consider it when:

• You are building outside Laravel/Symfony, or in a framework-agnostic core library where you do not want a full ORM as a dependency.
• Your team is comfortable writing SQL and wants convenience and safety, not query abstraction.
• Data needs are simple to moderate: CRUD, reporting queries, batch jobs — no complex relationship graphs or eager-loading requirements.
• You need multi-driver support for testing (SQLite) or a foreseeable database migration.
• The codebase is small enough that you can audit and vendor the wrapper yourself, and you accept a single-maintainer bus factor.

Look elsewhere when:

• You are on Laravel — the DB facade, query builder, and Eloquent already cover this, and adding a second data layer is net negative.
• You need the things this does not claim to do: migrations, schema management, relationships, connection pooling, read/write splitting, sharding, query observability.
• You are building a long-lived, high-criticality system where ecosystem size, security response process, and support SLAs matter more than a small dependency footprint.
• You need community velocity — 46 stars and zero dependents means you will not find answers, patches, or forks when something breaks.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility that handles database access safely in PHP services. It is not a platform bet — it is a days-of-engineering decision that lets us skip building our own database wrapper and avoid carrying a full ORM into services that do not need one. Cost is zero; the tradeoff is that it has a small community and one maintainer, so we would contain it and keep the ability to replace it. Recommendation: pilot on a low-criticality service, not on the core transaction path.

For engineering: Thin, driver-agnostic layer over PDO with safe querying by default. It removes boilerplate and gives us SQLite-in-tests, PostgreSQL-in-prod flexibility. What it does not give us: migrations, relationships, pooling, or read replicas — those stay our responsibility or belong to Doctrine/Laravel's stack. Because the community is tiny, pin the version, vendor the source into the repo, and write the wrapper behind our own interface so swapping in Doctrine DBAL or native PDO is a one-file change. The wrapper is small enough to audit in an afternoon, which is the main mitigation for the maintenance risk.