- Is FluentPDO compatible with Laravel?
- FluentPDO is framework-agnostic and ships no Laravel service provider, facade, config, or testing helpers. You can use it inside Laravel by handing it an existing PDO handle, typically from DB::connection()->getPdo(). It works mechanically on Laravel 9–11 with PHP 8.1+ and MySQL, PostgreSQL, or SQLite, but it is not officially supported or integrated with Laravel.
- How do I install FluentPDO in a Laravel application?
- Install it with composer require envms/fluentpdo and pin the exact version. Then write a small internal factory that returns a FluentPDO instance bound to DB::connection()->getPdo(), and never construct a second PDO connection. Add a config toggle so the dependency can be removed later without a code archaeology exercise.
- Does FluentPDO work with Eloquent models and relationships?
- No. FluentPDO sits at the PDO boundary and bypasses Eloquent events, observers, casts, accessors, and model lifecycle behavior entirely. It is a poor fit for domain modeling or anything relationship-driven. Use it only for narrow read-path reporting or a legacy raw-PDO data-access shim, not as an Eloquent replacement.
- Which databases does FluentPDO support?
- FluentPDO supports MySQL, SQLite, and PostgreSQL on existing PDO connections. It does not support SQL Server or other non-listed drivers. Confirm your target driver before adoption, because identifier quoting and grammar edge cases differ by database and a stale builder can emit invalid SQL at runtime.
- Is FluentPDO maintained and safe for production?
- It is effectively unmaintained upstream, with the last release dated 2022-01-27. The main risk is identifier handling, such as aliases, join keys, schema-qualified names, reserved words, and PostgreSQL case folding, rather than value binding. Pin the version, add composer audit to CI, verify PHP 8.2 and 8.3 compatibility against the source, and budget internal stewardship or a fork before production use.
- FluentPDO vs Laravel DB::table(): which should I use?
- For most Laravel code, use DB::table() or Eloquent because they are maintained, integrated with the query log, and understood by the team. FluentPDO may produce more readable SQL for a few complex reporting queries thanks to its smart join aliasing. Run a time-boxed spike by rewriting three real queries and compare readability, correctness, and execution plans before adopting it.
- Does FluentPDO support prepared statements and parameter binding?
- Yes. FluentPDO automatically builds prepared statements and binds values as parameters for SELECT, INSERT, UPDATE, and DELETE queries. That protects values, but it does not remove the need to validate identifier names such as table aliases, column names, and sort directions. Never interpolate untrusted identifiers into the fluent API.
- Why do FluentPDO queries not appear in Laravel Telescope or the query log?
- FluentPDO talks directly to the PDO handle, bypassing Laravel's DB layer, so its queries do not appear in the query log, Telescope, or APM traces. That creates a real observability gap in production. Add a small shim that logs the generated SQL and bindings through Laravel's logger if you adopt it.
- Can I use FluentPDO for INSERT, UPDATE, and DELETE in Laravel?
- FluentPDO supports INSERT, UPDATE, and DELETE, but avoid using it in transactional write flows until your wrapper proves it composes correctly with DB::transaction(). Keep greenfield write paths on Eloquent so model events, casts, and transaction coordination keep working. Restrict early adoption to read-only reporting or legacy shim modules behind a feature flag.
- What are good alternatives to FluentPDO in a Laravel project?
- The closest alternatives are Laravel's own DB query builder and Eloquent, which are maintained and integrated with logging and transactions. Doctrine DBAL, Aura.Sql, Laminas Db, or plain PDO are options outside Laravel, but they carry similar integration and stewardship tradeoffs. For most Laravel work, DB::table() covers the same ground with less long-term ownership.