# Flow PHP keeps data processing inside the language your team already writes

> Flow PHP is a strongly typed data processing framework for PHP with a low memory footprint. Its DataFrame core, adapters and container image show the intended shape of a PHP pipeline, but the examples live on the documentation site rather than in the README.

**flow-php/flow** — The most advanced data processing framework allowing to build scalable data processing pipelines and move data between various data sources and destinations.

- Repository: https://github.com/flow-php/flow
- Website: https://flow-php.com
- Stars: 870 · Forks: 56
- Language: PHP
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/flow-php-flow

## Flow PHP targets pipeline work that starts inside an application

Flow PHP describes itself as a strongly typed data processing framework with a low memory footprint, built for scalable pipelines that move data between sources and destinations. The audience is not generic PHP developers but teams who already live in a PHP codebase and need to extract, transform and load data without leaving the language. That framing matters, because the alternative for many shops is a separate ETL tool or a Python sidecar, and each of those adds a runtime, a deployment and a debugging surface.

The concrete capability list is short but specific. The documentation site, linked from the README, exposes working examples for DataFrame, reading data from an array, reading data from CSV, joins, and aggregations through group by, with a note that many more examples exist. Joins and group by are the two operations that tell you this is aimed at real data work rather than a thin streaming helper, since both require a schema and typed keys before anything can run.

## The repository layout points to a framework, not a library

The top level of the repository reads like a full product rather than a single package. There is a src directory, a documentation directory, a benchmarks directory and a terraform directory, alongside composer.json, a Dockerfile, compose.yml.dist, a Justfile, a shell.nix and a .nix directory. Two entries stand out for what they imply about maintenance: phpbench.json.dist and infection.json, which are the configuration files for PHP benchmark tooling and for mutation testing of the test suite, and mago.toml, a static analysis configuration.

Also present are monorepo-builder.php, which is the tool used to split a monorepo into separate Packagist packages, and a manifest.json listing the packages that are published. The published package list on Packagist is therefore not a single entry. Adapters for individual sources and destinations are expected to live in their own packages, which is the usual arrangement when connectors need to release independently of the core, and it means the main package is one dependency among several rather than everything in one box.

## The container image installs the driver stack PHP lacks by default

Because PHP ships with limited database support, the Dockerfile is the clearest statement of what the framework expects to talk to. The base image is parameterised at the top of the file:

```dockerfile
ARG FLOW_PHP_VERSION=8.5.8
ARG FLOW_DEBIAN_SUITE=trixie
ARG FLOW_BASE_IMAGE=php:${FLOW_PHP_VERSION}-cli-${FLOW_DEBIAN_SUITE}
```

The first stage adds the PostgreSQL apt repository and its signing key so that the builder and the final stage resolve libpq from the same source, which is the kind of detail that quietly breaks container builds otherwise. The build stage then installs the extensions that cover the common storage backends:

```dockerfile
 && docker-php-ext-install bcmath gmp pdo_mysql pdo_pgsql pdo_sqlite pgsql zip \
 && pecl install protobuf \
 && docker-php-ext-enable protobuf \
```

bcmath and gmp handle arbitrary precision maths, pdo_mysql, pdo_pgsql and pdo_sqlite cover three database engines, pgsql and zip are added alongside, and protobuf is pulled in through PECL rather than the distro. If your pipeline needs anything outside that list, you are extending the image yourself.

## Compression codecs come from pie, and a Rust toolchain lands in the builder

Four compression libraries are installed with the PHP package installer pie, which the file fetches as a phar and then uses to add each extension:

```dockerfile
 && php /usr/local/bin/pie install kjdev/brotli \
 && php /usr/local/bin/pie install kjdev/lz4 \
 && php /usr/local/bin/pie install kjdev/snappy \
 && php /usr/local/bin/pie install kjdev/zstd
```

That set covers the four common columnar and streaming formats, and it is the reason the image can read compressed data sources without shelling out to system binaries. The build stage also installs a Rust toolchain with rustup, so at least one dependency path in the project is compiled rather than interpreted.

Taken together, the image is heavy on build time and deliberately wide in its codec and database coverage. That is a reasonable trade for a reusable data pipeline image and a poor trade for a quick local script, which is why the packaged install route matters more for evaluation than the container does.

## Supported PHP versions, and a Windows caveat worth reading

The README lists supported PHP versions as 8.3, 8.4 and 8.5, and supported operating systems as Linux, macOS and Windows, where Windows is explicitly labelled experimental. Both details shape a decision. The PHP floor is recent, so a team pinned to an older runtime cannot use the framework without upgrading first, and a team on the newest runtime is fine.

The Windows label is the more interesting one. Experimental status usually means the test matrix does not cover every platform, so a Windows pipeline that is on a critical path carries more risk than the same code on Linux or macOS. There is also a wasm directory at the root of the repository, which points to a browser or WebAssembly target being part of the wider plan, though the README does not describe how that target is reached.

The default branch is 1.x, so the stable line of the project is the one your composer install will land on.

## The difference from a hand written PHP script is typing and adapters

The realistic alternative is not another framework but the script your team would otherwise write. A plain PHP script using generators over fopen reads rows lazily and uses little memory, and it costs nothing to install. Where Flow PHP differs is in the contract around that work. Strong typing means column names and key types are checked before a pipeline runs rather than failing on a null at runtime, and the adapters mean each source and destination is a declared dependency rather than hand written connection code in every script.

The other difference is where the API lives. The README does not show a single usage example inline. The up to date examples are hosted at flow-php.com, with anchors for DataFrame, array reading, CSV reading, joins and group by aggregations. That means the fastest way to evaluate the API is to read the hosted examples rather than the repository front page, and it also means the code you evaluate may differ from the version pinned in your lock file, so a composer.lock based check is the reliable comparison.

## An MIT licence and releases landing in October 2026

The licence is MIT, which keeps the copyleft question off the table for most commercial use. No legal reading is offered here, and specific compliance questions belong with your own counsel.

On the release side, the last push was on 2026-10-22 and the repository is not archived. Three recent tags show a tight rhythm: 0.46.0 on 2026-10-08, 0.45.0 on 2026-10-04 and 0.44.1 on 2026-09-15. The minor version numbers are still below 1.0, and a patch tag such as 0.44.1 indicates that fixes do arrive between minors.

Upgrade cost is therefore a real factor. The project keeps an upgrading guide at flow-php.com/documentation/upgrading/, and a CHANGELOG.md at the repository root. Adopting a 0.x framework means reading that guide on every minor bump, and pinning exact versions in composer.lock is the safer habit here.

## Conclusion

Flow PHP is worth evaluating for PHP teams that already maintain ETL logic and want typed pipelines, adapters and a low memory footprint without leaving the language, and the DataFrame, array, CSV, join and group by examples on flow-php.com are the fastest way to judge the API. It is a poor fit for a single ad hoc script, for a 0.x release line that still moves between minor releases, or on Windows, where support is marked experimental. Before committing, install the package from Packagist as flow-php/flow, check the PHP version you need against the supported 8.3, 8.4 and 8.5 range, and read the upgrading guide before moving between releases.

## FAQ

### How do I install Flow PHP?

The packages are published on Packagist under the flow-php organisation, with the main package listed as flow-php/flow. The README does not give an inline composer require command, so it points to the package listing and to the documentation site at flow-php.com for setup steps.

### What can Flow PHP do with CSV files and arrays?

The documentation site lists examples for reading data from an array and reading data from CSV, alongside DataFrame, joins and aggregations through group by. The framework is described as strongly typed with a low memory footprint.

### Which PHP versions and operating systems does Flow PHP support?

The README lists PHP 8.3, 8.4 and 8.5 as supported versions, with Linux and macOS supported and Windows marked experimental. The default branch is 1.x.

## Sources

- [flow-php/flow on GitHub](https://github.com/flow-php/flow)
- [License: MIT](https://github.com/flow-php/flow/blob/1.x/LICENSE)
- [Project website](https://flow-php.com)
- [README](https://github.com/flow-php/flow/blob/1.x/README.md)
- [Releases](https://github.com/flow-php/flow/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flow-php-flow