What one Composer command actually buys

composer require visorcraft/mongreldb-php pulls a package whose entire production dependency list fits on one screen:

"require": {
    "php": ">=8.4",
    "ext-curl": "*",
    "ext-json": "*"
}

Read that list the way an ops person reads it, because ext-json has been compiled into PHP 8 since day one and cannot be disabled, which makes it a dependency in name only, and ext-curl ships in the PHP source tree and comes enabled in every standard distribution build we have ever checked, so on a standard PHP 8.4 or 8.5 build from any major distribution the real requirement reduces to “PHP exists,” and the worst case on a minimal install is one distro package like php-curl, not a compile step. Just as important is what is not there: no third-party packages underneath, a dependency tree with depth one, nothing transitive for composer update to surprise you with at 2 AM, and a supply chain audit that means reading one repository instead of forty.

Why the ABI treadmill still matters

The extension ecosystem has not gotten calmer with age, since every PHP minor release bumps the internal API and every native extension has to be rebuilt against it, which is why Xdebug publishes a new build per PHP version and why smaller PECL packages routinely lag a fresh PHP release by weeks or months, leaving teams that depend on a native database driver unable to upgrade PHP when they want to and only able to upgrade when their driver’s maintainer gets around to it. Docker makes the cost quieter but not smaller: the moment a Dockerfile contains pecl install or docker-php-ext-install, the image build needs a compiler toolchain and the -dev headers, the image either grows by hundreds of megabytes or you learn multi-stage builds the hard way, and every CI run pays for a compile that has nothing to do with your application code. A pure PHP client collapses all of that into the same composer install the rest of your dependencies already use, against a base image that never needed gcc, with a composer.lock that makes the whole thing reproducible and rollback a one-line revert.

Where the speed actually comes from

The honest objection to a pure PHP database client is that PHP code runs slower than C code, which is true as far as it goes but misidentifies where the time actually goes in a client-server conversation. This client’s job is to serialize a request, send it to mongreldb-server over a keep-alive HTTP connection, and decode the JSON that comes back, while the heavy lifting, meaning index traversal, vector search, constraint checks, and the WAL fsync, happens in Rust on the other side of the socket, so the PHP-side cost per call is microseconds of json_encode wrapped around milliseconds of work the engine was going to do anyway. Within a single request the cURL transport pools keep-alive connections on its own, and on PHP 8.5 you can opt into persistent cURL sharing so DNS results, TLS sessions, and where libcurl allows it the connection cache itself survive across FPM requests, which is exactly the kind of runtime feature a pure PHP client can adopt the day it ships, because adopting it means a function_exists('curl_share_init_persistent') check and a function call, not waiting for an extension maintainer to cut a release.

Could we have shaved the serialization cost with FFI, which has shipped since PHP 7.4 and could call libmongreldb.so directly in process? Probably, and we chose not to, because FFI drags back precisely what we set out to remove: a native artifact that must exist on every host at a path everyone agrees on, built for the right platform, plus an ffi.enable setting that hardened setups and most shared hosts leave off. HTTP costs a round trip and a JSON pass that we can measure, and it buys a client that runs anywhere PHP runs with zero install ceremony, a trade that reads better every year rather than worse.

The modern equivalent of the old convenience

We accepted the compile step for years because there was no alternative, since the old mysql extension lived inside the PHP source tree itself and you got your driver by building PHP, which felt like convenience only because nobody had shown us anything better. The modern equivalent of that convenience is not a better extension but no extension at all: a client that arrives through the same tool managing the rest of your dependencies, upgrades atomically with your application, and never turns a PHP minor release into a two-ticket sprint waiting on someone else’s build farm. Twenty years ago the best database driver was the one already compiled into your PHP; in 2026 the best one is the one that never needed compiling, and everything else in this series, the idempotent transactions, the index-aware query builder, the status-code-shaped exceptions, stands on top of that one decision.