I'm not part of a large engineering team. I'm a freelance software engineer maintaining several repositories around the Turso and libSQL PHP ecosystem, mostly in the time left between paid work and everything else.
On November 9, 2026, several things finally moved forward.
The core PHP extension received a significant reliability overhaul. The installer addressed a long-standing PHP 8.5 installation issue. The Laravel driver fixed a bug that could silently swallow database constraint violations.
It was a productive day.
But looking at the entire ecosystem, there's another story worth telling: not every repository is moving at the same pace.
Some components are actively maintained. Others have been sitting untouched for months or even years.
This is an honest account of where things stand.
The Core Extension: Reliability Before New Features
The biggest development happened in turso-client-php.
On November 9, I merged PR #27, a reliability overhaul covering several problems that needed attention.
This wasn't a cosmetic refactoring.
Some of the issues were serious enough to affect application stability and data correctness:
- FFI error mapping: Constructor and provider errors now throw
PhpExceptioninstead of potentially triggering a panic that terminates the PHP process. - Memory safety: Fixed a dangling-pointer and double-free risk in
fetchSingle(ALL). - Extension loading: Fixed
enableLoadExtension(false), which previously failed to properly disable extension loading. - Statement reuse: Fixed a binding issue where reusing a fully bound statement could execute with the original parameters instead of the newly supplied ones.
- Typed configuration and bindings: Improved configuration handling and parameter binding.
- Lazy streaming: Implemented actual
LIBSQL_LAZYstreaming behavior. - Configuration compatibility: Fixed the
cdc_urlproperty silently being transformed intocdcUrl.
The changes also included additional documentation, end-to-end tests, and a production-oriented Docker test harness.
Shortly afterward, I published turso-php-extension v1.7.0.
The release also brought back Windows builds and introduced PHP 8.5 binaries across Linux x86_64, macOS Intel and Apple Silicon, and Windows TS.
There are still limitations. Windows PHP 8.5 NTS binaries are not included yet and are planned for v1.7.1.
One more thing: the underlying libSQL core remains at crate 0.9.19, corresponding to LibSQL Core 3.45.1. This release was primarily about PHP compatibility, platform coverage, and reliability rather than upgrading the underlying database engine.
I would rather make the extension safer than publish another release number just to make the changelog look busy.
The Installer: Fixing the First Experience
A database extension can be technically excellent and still fail before users even get to write their first query.
That's why the installer deserves attention.
In turso-php-installer, I finally closed issue #10, originally reported in March 2026.
The issue involved PHP 8.5 installation problems, including a PDO deprecation warning related to PDO::MYSQL_ATTR_SSL_CA and:
stty: invalid argument
There were two separate symptoms.
First, the terminal error was no longer reproducible with the current stack because Laravel Prompts handled the terminal environment differently.
Second, the PHP 8.5 deprecation needed to be handled at the PHAR entry point.
The fix was included in version 2.2.1. The installer masks that specific deprecation for PHP 8.5 and newer without changing error reporting behavior for older PHP versions.
Then another contribution came in.
PR #11, submitted by brendt, removed the redundant paragonie/sodium_compat dependency.
Since libsodium has been available natively since PHP 7.2, keeping a compatibility package in a project requiring PHP ^8.2 was unnecessary.
I merged it and prepared version 2.2.2.
Small changes, but these are exactly the kinds of maintenance tasks that improve the experience of using an open-source project.
Laravel Driver: When Database Errors Disappear
The next important change happened in turso-driver-laravel.
PR #114, contributed by WilliamIsted, fixed a particularly dangerous behavior.
The problem was documented in issue #113.
Previously, LibSQLPDOStatement::execute() caught exceptions and returned false.
That might look reasonable from a PDO perspective, but it created a problem when interacting with Laravel.
Laravel expects database failures to surface as exceptions. It does not simply treat every false return value from statement execution as a failed query.
The result?
Constraint violations could disappear silently.
This affected operations involving:
- Unique constraints.
- NOT NULL constraints.
- CHECK constraints.
- Foreign key constraints.
In certain situations, insertGetId() could even return an ID belonging to a previous row.
That's not a minor compatibility issue. That's a data integrity problem.
The fix was straightforward in principle: throw PDOException while preserving the original exception as the previous exception.
Laravel can then wrap it in its normal QueryException handling flow.
The reported test run passed 155 tests, with 6 skipped, using PHP 8.4.20, libsql_php 1.6.2, and Laravel 12.61.0.
I also prepared the 1.3.2 and 1.4.0 tags.
Version 1.4.0 introduces the Laravel-facing configuration for encryption and offline writes, which requires extension version 1.7.0 or newer.
This is an important distinction: adding a feature is useful, but ensuring database failures are properly reported is essential.
The Part Nobody Likes Talking About: Dormant Repositories
Now comes the less exciting part.
The ecosystem isn't just the core extension, installer, and Laravel driver.
There are other repositories that need maintenance too.
And honestly, I haven't kept up with all of them.
Doctrine DBAL
turso-doctrine-dbal has had no new commits since September 7, 2024.
There is still PR #1, opened in July 2026, proposing improvements for Doctrine DBAL 4 compatibility.
It includes changes to remote/local mode selection, result column handling, and lastInsertId() behavior.
However, one important part depends on turso-client-php PR #26.
That dependency is still a draft.
This means the DBAL 4 compatibility work is not yet in the main release path.
HTTP Client
turso-client-http has had no new commits since September 2024.
There are no recent releases or open issues indicating active development.
I cannot claim that the library is broken. But I also cannot claim that it has kept pace with the newer extension behavior.
MyLibSQLAdmin
mylibsqladmin last received a commit on July 27, 2025.
Its latest release is v1.4.2, published in June 2025.
The project remains part of the ecosystem, but it hasn't been updated alongside the newer encryption and offline-write capabilities.
That doesn't automatically mean the admin interface is incompatible. It simply means those newer capabilities have not been demonstrated as integrated into the current administration workflow.
PR #26: One of the Things Still on My Desk
There is another unfinished piece.
PR #26 is still a draft.
It includes:
- Linux ARM64 support for TS and NTS builds.
- Fixes involving
LIBSQL_NUM. - PHP 8.5 and ARM64 documentation updates.
- Small driver-related corrections.
The Doctrine DBAL compatibility work depends on part of this change.
I know it needs attention. But knowing something needs attention and actually having enough time to finish it are two different things.
That's one of the realities of maintaining multiple repositories independently.
A change in one project can block another project. A small unfinished pull request can become an ecosystem-wide compatibility issue.
The Reality of Solo Maintenance
Looking at November 9, there is a clear pattern.
The core extension, installer, and Laravel driver moved forward together.
But the surrounding repositories did not.
A large portion of the maintenance work still depends on one primary maintainer.
There are valuable community contributions. brendt contributed the installer dependency cleanup. WilliamIsted contributed the Laravel exception-handling fix. Other contributors have also opened work around Doctrine and ARM64 compatibility.
I'm grateful for that.
But the maintenance workload is still uneven.
I maintain these projects alongside freelance engineering work. That means there are competing priorities, limited hours, and sometimes a backlog that grows faster than I can clear it.
I'm not saying this to ask for sympathy.
I'm saying it because open-source maintenance should be discussed honestly.
A repository being public doesn't mean it is actively maintained.
A working core extension doesn't automatically mean every integration is ready.
And a new release doesn't magically resolve every compatibility issue across an ecosystem.
The health of an ecosystem depends on the components surrounding its core.
What Needs to Happen Next?
Here are the things I want to move forward:
- Windows PHP 8.5 NTS: Complete the missing binary for extension v1.7.1.
- ARM64 Linux: Resolve and merge the relevant changes in PR #26.
- Doctrine DBAL 4: Move PR #1 forward and address its dependency on the extension.
- Laravel compatibility: Validate driver v1.4.0 against extension v1.7.0.
- Installer distribution: Verify the Packagist publication status of version 2.2.2.
- HTTP client: Review whether the repository should receive active maintenance or an explicit maintenance-status update.
- MyLibSQLAdmin: Reassess compatibility with newer extension capabilities.
- Documentation: Remove remaining references to retired repositories.
These are not all equally urgent, but they are all part of maintaining a coherent ecosystem.
8. Want to Help?
If you are interested in contributing to the Turso PHP ecosystem, there are concrete places to start.
You don't need to build another database abstraction layer.
You can help by:
- Reviewing PR PR #26 for ARM64 and
LIBSQL_NUM. - Helping move Doctrine DBAL 4 compatibility forward.
- Testing Laravel driver 1.4.0 against extension 1.7.0.
- Testing PHP 8.5 installation across different environments.
- Reviewing compatibility in the HTTP client and administration interface.
- Improving documentation and reporting reproducible issues.
Start with the existing work instead of opening another disconnected implementation.
The open-source ecosystem doesn't need more repositories just for the sake of having more repositories.
It needs people willing to maintain what already exists.
The core is moving forward. Now the edges need attention too.
