- Does flow-php/symfony-postgresql-bundle work with Laravel?
- No. Laravel does not boot Symfony bundles; it uses service providers, the config repository, and facades. The Bundle class and DI Extension in this package are effectively dead weight in a Laravel app, and loading its extension outside a Symfony kernel is not supported. Only the underlying Flow PHP PostgreSQL adapter services it registers are reusable, so you should depend on flow-php/postgresql directly instead.
- How do I install and configure Flow PHP PostgreSQL in a Laravel application?
- Install flow-php/etl and flow-php/postgresql, deliberately skip the Symfony bundle, and register the adapter as a singleton in an App\Providers\FlowServiceProvider. Read connection settings from config/database.php or a dedicated config/flow.php rather than duplicating credentials. Reusing Laravel's existing connection config avoids the credential drift that is the most predictable integration bug.
- Which Laravel and PHP versions are supported by this package?
- The package publishes no Laravel version constraints because it targets Symfony kernels, so compatibility has to be verified rather than assumed. Run composer why-not against your Laravel install to check for symfony/* major version collisions, since Laravel 10 and 11 pin different Symfony majors. On the PHP side, confirm Flow PHP's PHP version floor against your runtime; the recommended target stack is Laravel 10 or 11 on PHP 8.2+ with pdo_pgsql enabled in every environment image.
- Is flow-php/symfony-postgresql-bundle safe to use in production?
- There is no production usage signal: the package has zero stars, zero dependents, and a composite score of zero. Expect a small maintainer surface, sparse Laravel-adjacent documentation, and pre-1.0 API churn. The MIT license and the underlying Flow PHP project's activity are the main positives. Treat it as an internal spike rather than an adopted dependency, and validate the extract, transform, load path before committing.
- What is the difference between this bundle and flow-php/postgresql?
- flow-php/symfony-postgresql-bundle is only a Symfony integration layer: a Bundle class plus a DI Extension that wires Flow PHP's PostgreSQL adapter into a Symfony service container via a Configuration tree and compiler passes. The actual Postgres reading and writing logic lives in the underlying Flow PHP packages. In Laravel, the bundle adds nothing you cannot register yourself, so depend on flow-php/etl and flow-php/postgresql and write the service-provider wiring by hand.
- Can I use Flow PHP PostgreSQL alongside Eloquent and Laravel's DB facade?
- Yes, they can coexist in the same application, but they serve different workloads. Flow PHP is suited to batch and ELT jobs such as nightly extracts, cross-system syncs, and warehouse loads; Eloquent and the query builder remain the better choice for request-path CRUD. Wrap the Flow adapter behind a thin interface like App\Data\Contracts\PostgresExtractor so a later swap to DB::cursor() or a queue-driven job is a one-file change.
- How should I test Flow PHP Postgres pipelines in a Laravel project?
- Start with a plain PHP script outside Laravel to prove the extract, transform, and load path end to end before touching the framework. Once that works, wrap the validated path in a service provider and write integration tests against a real Postgres instance rather than a mock. Confirm type mapping for numeric, timestamptz, jsonb, and arrays during testing, because Flow's schema inference is stricter than Eloquent's casting and mismatches surface as runtime errors, not install errors.
- What PostgreSQL version and role permissions do I need for Flow PHP bulk loads?
- Confirm the target Postgres server version and that the connecting role has the privileges required for bulk COPY operations, since COPY is the usual mechanism behind fast loads. Also verify the role's access to every schema and table in the pipeline. Test with the same server version and permissions in CI, staging, and production containers to avoid surprises late in a release.
- Are there alternatives to this package for ETL and data pipelines in Laravel?
- Yes. For most Laravel workloads, a scheduled Artisan command using chunked Eloquent queries or DB::cursor() is simpler, better instrumented, and already understood by the team. If you genuinely need streaming transforms and dataframe-style operators, use flow-php/etl with flow-php/postgresql directly and wire it yourself. Queue-driven jobs and dedicated warehouse loaders are other options worth benchmarking before adding a new ETL framework.
- Who maintains flow-php/symfony-postgresql-bundle and what happens if it is abandoned?
- The package shows no third-party validation and a small maintainer surface, so assume a single or narrow maintainer team upstream. Because this Laravel integration is your own service-provider wiring, an upstream pause mainly affects adapter upgrades rather than your application structure. Pin the underlying Flow PHP versions, keep the adapter behind your own interface, and decide in advance who owns upgrades if upstream goes quiet for six months or more.