Weave Code
Cloud Bigquery Laravel Package
google/cloud-bigquery
Google Cloud BigQuery for PHP is an idiomatic client for creating, managing, and querying data in BigQuery. Install via Composer, authenticate with Google Cloud, then run load jobs and queries from your PHP app.
At a glance
Frequently asked questions about Cloud Bigquery
- How do I install google/cloud-bigquery in a Laravel project?
- Run composer require google/cloud-bigquery in your Laravel project; the package is not Laravel-specific, so it simply adds the BigQuery client and its Google Cloud dependencies. Pin it to ^1.39 and let google/cloud-core resolve transitively rather than pinning core yourself. There is no service provider registration or config publishing step, so instantiate BigQueryClient where needed or bind it in one of your own service providers.
- Does google/cloud-bigquery support Laravel 9, 10, and 11 and PHP 8.1 to 8.4?
- The SDK supports PHP 8.1 through 8.4 (8.4 was added to the test matrix in v1.31.1) and works fine inside Laravel 9 through 11. It supports Guzzle 7 and 8 as of v1.39.0, so conflicts with Laravel's HTTP client constraints are unlikely. There is no framework-level version gate because the package has no Laravel dependency at all.
- Is there a Laravel service provider, facade, or Eloquent driver for BigQuery?
- No. This is a thin idiomatic SDK over the BigQuery REST API, not a Laravel package: there is no service provider, facade, config file, query builder, migration support, or Eloquent driver, and that omission is deliberate because BigQuery is treated as an external analytics system rather than your application's system of record. The workable pattern is to bind BigQueryClient in a service provider and hide it behind your own repository interface, which also makes it straightforward to fake in tests.
- How should I authenticate google/cloud-bigquery in Laravel?
- Create a BigQueryClient with no arguments to use Application Default Credentials, which is the path Google is steering teams toward via Workload Identity Federation. The keyFile and keyFilePath options were deprecated in v1.34.2, so long-lived service account JSON in a .env file is a design decision to make deliberately rather than retrofit later. On GCP-hosted infrastructure, attach the appropriate IAM role to the service identity and let ADC resolve it.
- How do I run a BigQuery query from Laravel and iterate results without exhausting memory?
- Call $bigQuery->query() with your SQL, then $bigQuery->runQuery() and foreach over the result. Iteration is generator-based, so rows stream back instead of loading the entire result set into memory, which keeps memory flat on large result sets. The job itself still has to complete server-side, so for multi-second or multi-minute queries use the asynchronous job API and poll rather than blocking a request.
- Can I load a CSV or NDJSON file from Laravel storage into BigQuery?
- Yes. Load jobs accept stream resources, so fopen() on a Laravel storage path such as Storage::path('exports/data.csv') works directly. Build the load config with $table->load($stream) and execute it with $table->runJob($loadJobConfig); NDJSON works the same way with the matching source format option. For large files, run the job asynchronously and reconcile on completion instead of holding the request open.
- Why do BigQuery queries time out in PHP-FPM and should I queue them?
- This is the real production constraint: BigQuery jobs take seconds to minutes, while PHP-FPM timeouts and load balancer idle limits are far shorter. Queue every non-trivial query with Laravel's queue and cache the results instead of running it inside the request cycle. Reserve synchronous queries for small, bounded, dashboard-style lookups.
- How do I control BigQuery query costs from a Laravel application?
- On-demand pricing bills bytes scanned, so an unbounded SELECT * issued from PHP is a budget incident waiting to happen. Enforce maximumBytesBilled on every query job config and run a dry-run validation before executing user-influenced SQL. Do this in code rather than by convention, and use partitioning and clustering to reduce scanned bytes.
- Does google/cloud-bigquery handle Int64 and timestamp values losslessly?
- Fidelity issues here were actively fixed: v1.33.0 addressed lossless Int64 timestamps and v1.35.2 fixed a record-null bug, so stay on a recent 1.39.x release. Financial or ID-heavy datasets still need explicit type assertions before launch, because PHP integers and floats do not map cleanly onto BigQuery's Int64 and NUMERIC types. Test round-trips with realistic production-shaped data.
- Is google/cloud-bigquery actively maintained, and why is the star count so low?
- It is GA and steadily maintained, but read the signals correctly: the low star count and zero dependents reflect that this is a split read-only subtree of the googleapis/google-cloud-php monorepo, where stars, issues, and support actually live. The component carries a no-backwards-incompatible-changes guarantee for minor and patch releases, and the v1.28 to v1.39 stream reads as maintenance rather than active feature development. Pin to ^1.39 and avoid fork or path-repository patches, which will drift from the monorepo.
Weaver
How can I help you explore Laravel packages today?