What pure PHP actually means in 2026

The phrase “pure PHP” has accumulated some baggage over the years, partly because PHP’s early reputation as a slow interpreted language made “pure PHP” sound like “slow PHP,” and partly because the PHP ecosystem spent a decade leaning on C extensions as proof of seriousness. Neither of those associations is accurate anymore, and the PHP client does not trade on either of them.

What pure PHP means here is concrete: the entire client is written in PHP 8.4 syntax, it ships as a Composer package, it has no native code dependencies, and it does not call any function that requires a C extension. HTTP is handled by curl via ext-curl when PHP 8.5 persistent handle sharing is available (PHP 8.5 being the newer of the two runtimes, so the stream-context path remains the common case for now), and by regular stream contexts when it is not; both are in the standard PHP distribution and neither requires a compile step. JSON is handled by json_decode and json_encode, which have been built into PHP since 5.2 and have been reliably fast since 7.0. There is no binary .so to load, no phpize to run, no ABI version to match against the server’s architecture, and no risk that pecl install mongrel fails because your host has disabled exec() in php.ini.

The install experience

composer require visorcraft/mongreldb-php

That is the entire install. The package lands in vendor/, autoloading is configured, and you can instantiate the client in one line:

use Visorcraft\MongrelDB\Client;

$db = new Client('https://db.example.com', token: getenv('MONGRELDB_TOKEN'));

No bootstrap scripts, no extension loading in php.ini, no running mongreldb-php-setup as a post-install script. The Composer package ships the client, the type stubs, and the error hierarchy; you require the package and you are talking to the database.

Why HTTP is the right transport for a pure PHP client

The PHP client could have used a Unix socket or a raw TCP protocol with a binary framing layer, and in a pure-server context those choices would make sense for latency. But PHP is not a long-running process by default; PHP-FPM spawns a process per request or per few requests, and the typical PHP application opens a fresh database connection on every web request, closes it at the end, and does not reuse it unless you have gone out of your way to implement connection pooling. An HTTP client reuses keep-alive connections across requests in the same process lifetime, and when PHP-FPM recycles a worker the next request starts fresh, which is the same behavior the database would have expected anyway.

HTTP also means the PHP client works through every HTTP-aware proxy, load balancer, and API gateway that already exists in your infrastructure, and it means TLS termination happens at the normal layer rather than requiring a special database-facing certificate setup. You are already doing HTTP for every other external service your application calls; the database does not need to be special.

What you give up and what you do not

You give up the single-digit-microsecond in-process path, because HTTP adds a header processing layer that a raw TCP protocol would not have (a few hundred microseconds of framing overhead per operation, not a category shift), and you give up the ability to operate without a network path to the server, which is the embedded-database use case that MongrelDB handles differently through its Kit SDK. For a PHP web application that talks to a mongreldb-server over a LAN or a VPC, those tradeoffs are not on the critical path; the query execution time inside the database dominates the HTTP overhead by two orders of magnitude.

You do not give up type safety, because the client speaks a typed wire format and deserializes responses into PHP native types with a full exception hierarchy that maps HTTP status codes to domain exceptions, so a 404 from the server becomes a NotFoundException in your application code rather than a generic runtime error. You do not give up connection pooling in the PHP-FPM context, because the client uses persistent curl handles when PHP 8.5 is available, which means the underlying TCP connection is reused across requests in the same worker process without the TLS handshake cost on every page load. And you do not give up SQL surface area, because the wire format carries the same query plans and constraint semantics as the Kit SDK and the Rust core, so the PHP client is not a reduced-surface wrapper; it is the full client in a different transport.

Who benefits from this in practice

The obvious answer is the shared-hosting developer who is on a cPanel machine with no root access and no ability to run phpize, and that answer is correct but incomplete. The more interesting case is the CI pipeline: a composer require in a Dockerfile that uses php:cli as its base image does not need any system package installed beyond the PHP runtime and Composer itself, which means your test matrix can cover PHP 8.4 and PHP 8.5 on the same Docker image without an extension compilation step slowing down every build. The pure PHP client makes your database client a first-class Composer dependency rather than a system-level install, and that distinction matters when your CI minutes are metered and your container build time is on the critical path.