Aura.Sql: PDO with lazy connections, a profiler and a connection locator

An extension of PDO rather than a replacement

The framing in the README is the reason to care about this package. Aura.Sql provides an extension to the native PDO along with a profiler and connection locator, and because ExtendedPdo is an extension of the native PDO, code already using the native PDO or typehinted to it can use ExtendedPdo without any changes. That is a smaller promise than a database layer and a much smaller one to accept, because the semantics of PDO stay where they are and the additions sit on top. The repository is a package in the Aura family, with the src/ directory, a tests/ directory, a docs/ directory, a composer.json, a phpunit.xml.dist and a CHANGELOG.md, and the default branch is 6.x. The topics list database, pdo-instance, php and profiler, which is a fair summary of the package in four words. The licence is MIT, and the project follows Semantic Versioning.

Lazy connection, and what it saves

The first addition to PDO is lazy connection. ExtendedPdo connects to the database only on method calls that require a connection, which means you can create an instance and not incur the cost of a connection if you never make a query. In a request that touches the database conditionally, or in a worker that builds a service graph and does not always use it, that is a real saving rather than a micro-optimisation, because a connection to a remote database is a network round trip and a set of credentials to negotiate. The second is decoration. DecoratedPdo can be used to decorate an existing PDO instance, so a PDO instance can be extended at runtime to provide the ExtendedPdo behaviors. That is the option for code you do not own, since it does not require the call sites to change type, and it is the escape hatch if you are integrating Aura.Sql into a framework that constructs its own PDO objects. The practical rule is that the two mechanisms solve different problems: lazy connection applies to instances you create, decoration applies to instances someone else creates.

Array quoting and the perform() method

The features that change how you write queries come next. The quote() method accepts an array as input and returns a string of comma-separated quoted values, and there is a new perform() method that acts just like query() but binds values to a prepared statement as part of the call. In addition, placeholders that represent array values are replaced with comma-separated quoted values, which means you can bind an array of values to a placeholder used with an IN (...) condition when using perform(). The fetch*() methods then build on that. They provide for commonly-used fetch actions, so you can call fetchAll() directly on the instance instead of preparing a statement, binding values, executing and then fetching from the prepared statement, and all of the fetch*() methods take an array of values to bind and use the new perform() method internally. The yield*() methods are complements to the fetch*() methods that yield results instead of returning them, which is what you want when streaming a large result set rather than loading it all into memory.

Exceptions instead of silence, by default

One change alters behaviour rather than adding capability. ExtendedPdo starts in the ERRMODE_EXCEPTION mode for error reporting instead of the ERRMODE_SILENT mode. For a long time the silent default was PDO's, and code written against it tends to check return values rather than catch exceptions, so switching to exception mode can surface error handling that was never written. For new code the exception default is the better choice, since a failed query that returns false and is then used as a result set is a class of bug that exceptions eliminate. For existing code, this is the change to review, and it is worth noticing that the fetch*() and perform() helpers are built around the assumption that a failed statement is an exception rather than a false return.

The profiler and the connection locator

The two optional services are the reason to reach for this package rather than writing the same code yourself. The profiler is optional and comes with an interface for other implementations, and it logs to any PSR-3 interface, which means the query log lands in whatever logging setup the application already has instead of a parallel file. The connection locator is an optional lazy-loading service locator for picking different database connections, with default, read and write. That last part is the operationally interesting one. A read/write split usually means two connection parameters in the container and a decision at each call site, and a locator moves that decision into one object, so a query that only reads goes to the reader and a write goes to the writer without every repository knowing. The package depends on external interfaces rather than external implementations, as the README says for Aura packages generally, which is what allows the PSR-3 logger and the connection implementations to be swapped.

Installing it, and the PHP version that decides your major line

The package is installable and PSR-4 autoloadable via Composer as aura/sql, and the alternative is to download a release or clone the repository and map the Aura\Sql\ namespace to the package src/ directory. The version decision is more consequential than the install command. Version 6.x is compatible with PHP 8.4 and above, and if you are running PHP 8.1 to 8.3 the README asks you to use version 5.x, and it recommends using the latest available version of PHP as a matter of principle. The default branch is 6.x, and the recent releases are 6.0.1 on 2026-01-05, then 6.0.2 and 6.1.0 both on 2026-09-29, with the last push to the repository on 2026-09-29 as well. To run the unit tests at the command line, the README says to issue composer install and then ./vendor/bin/phpunit at the package root, which requires Composer to be available as composer.

Where Aura.Sql is the wrong choice

Three limits are clear. The first is that it is a wrapper, not an abstraction layer, so everything PDO does, Aura.Sql does, including the parts people often want to leave behind, and a project that wants a query builder or an ORM is looking at a different package entirely. The second is the PHP version split, and it is worth being blunt: on PHP 8.1 to 8.3 the current line does not apply and you would be adopting 5.x, which means the features described in the README for the 6.x line, including the new fetch and yield methods, may not all be present in what you can actually install. The third is the optional nature of the good parts. The profiler and the connection locator are opt-in services that need to be wired into the application, and the read/write split only helps if your infrastructure actually has a reader and a writer to point at, so on a single-server application the locator is structure without benefit. On maintenance, the 6.x line is being worked on now, with two releases and a push on the same day, and the project adheres to PSR-1, PSR-2 and PSR-4, which is a good sign of a package that has been maintained carefully for a long time.

Editorial conclusion

Aura.Sql suits a PHP codebase that already uses PDO and wants three specific improvements without rewriting its queries, a connection that is not opened until it is needed, a profiler that can be turned on in development, and the option to route reads and writes to different servers. It is the wrong tool if you are on PHP 8.1 to 8.3, since the README says version 6.x is compatible with PHP 8.4 and above and asks you to use 5.x instead, and it is the wrong tool if you want a query builder or an ORM, because this is a wrapper around PDO and nothing more. Verify first which PHP version your project runs, then check that the PSR-3 logger you want to profile into is already in the application, and note that the 6.x line shipped 6.0.2 and 6.1.0 on 2026-09-29, with 6.0.1 released earlier that year and the last push the same day.

Frequently asked questions

Official sources

1. auraphp/Aura.Sql on GitHub
2. Issues
3. License: MIT
4. README
5. Releases