Df Sqldb Laravel Package

Product Decisions This Supports

• Build vs. buy for the data-access layer. This package is the SQL connector inside DreamFactory, a self-hosted platform that auto-generates governed REST APIs over databases. The real decision is not "should we install this Composer package" but "should we buy a data-API platform instead of hand-building schema introspection, auth, rate limiting, and audit logging ourselves."
• Roadmap acceleration for "API-ify the database" work. If a quarter is blocked on exposing legacy MySQL/PostgreSQL/SQL Server/Oracle data to internal apps or partners, this shortens the path from schema to secured endpoint from weeks to days.
• Governance and compliance feature bets. Because access control, API keys, role-based permissions, rate limits, and request logging ship with the platform, it supports decisions to standardize on a governed gateway rather than per-team ad-hoc endpoints.
• LLM and agent data-access strategy. The platform positions itself for "enterprise apps and local LLMs," so this connector is relevant when deciding how internal models and agents reach relational data without direct database credentials.
• Prototyping and internal-tool investment. Useful for deciding whether to fund custom admin/BI backends or generate them from existing schemas.
• Not a decision this supports: choosing a general-purpose Laravel database abstraction or ORM layer. It is a platform module, not a standalone library.

When to Consider This Package

Consider it when:

• You are already evaluating or running DreamFactory and need SQL database connectivity; the package is a component, not an independent dependency (0 dependents, minimal standalone community).
• You need many heterogeneous databases exposed through one consistent, governed REST surface.
• Self-hosting and data residency are requirements — no third-party SaaS in the data path.
• Compliance needs include RBAC, API key management, rate limiting, and audit trails out of the box.
• Your team is PHP/Laravel-comfortable and wants configuration-driven endpoints rather than bespoke controllers.
• You value Apache-2.0 licensing and the option to fork or extend.

Look elsewhere when:

• You have one database and simple CRUD needs — Laravel API resources, PostgREST, or Supabase will be lighter and better supported.
• You need GraphQL-first access — Hasura is the stronger fit.
• Your domain logic is complex and custom; generic generated endpoints will fight you, and a purpose-built service layer wins.
• You require a large OSS community, third-party integrations, or commercial SLA visibility — 2 stars and 0 dependents mean support comes from the vendor relationship, not the ecosystem.
• You are not on PHP/Laravel, or you need edge/serverless deployment.
• You need schema migrations, ORM modeling, or query-building — this is an access layer, not a persistence framework.

How to Pitch It (Stakeholders)

For executives: We can expose our existing databases as secured, auditable APIs in days instead of building and maintaining a custom middleware layer. The platform is self-hosted and Apache-2.0, so data never leaves our infrastructure, and governance controls — roles, keys, rate limits, logging — are included rather than bolted on later. The trade-off is vendor dependence: the package itself has negligible independent adoption, so we should evaluate and contract with DreamFactory as a platform, not treat this as a commodity library. Recommendation: run a time-boxed pilot against two data sources and compare total cost against a custom build before committing.

For engineering: This is DreamFactory's SQL connector — a Laravel service-provider module configured per data source. It handles driver support, schema introspection, endpoint generation, and request lifecycle integration so we don't reimplement them. It is actively released alongside the platform (latest 2026-09-24) but has effectively no standalone consumer base, so treat the platform's release cadence and issue tracker as our support channel. Integration cost is low; the real work is schema hygiene, permission modeling, and deciding which databases should be exposed at all. Risks to validate in the pilot: query performance on large tables, connection pooling under load, and how much custom logic we can express before we need a separate service.