- Can I use fwolfsjaeger/doctrine-cockroachdb-bundle in a Laravel application?
- No. This is a Symfony bundle whose only job is dependency-injection wiring; Laravel has no bundle loader and nothing in the package runs in a Laravel request lifecycle. For Laravel you would use the stock pdo_pgsql driver or copy the underlying Doctrine DBAL driver class into your app and register it from a service provider. If you are Eloquent-only, you would write an Illuminate connector and config/database.php entry instead.
- What does this package actually add for CockroachDB?
- It adds Doctrine DBAL support for CockroachDB inside Symfony by registering a driver and connection factory with the container and providing configuration, platform detection, and schema handling. The bundle wrapper is Symfony-specific, but the reusable part is the driver class and its transaction-retry behavior. Treat the repo as driver source to evaluate, not as a Laravel dependency.
- Do I need a dedicated CockroachDB driver, or is the standard Postgres driver enough?
- For most workloads, CockroachDB speaks the PostgreSQL wire protocol and a stock pdo_pgsql connection works. The main reason to consider a dedicated driver is transaction retry semantics: CockroachDB runs SERIALIZABLE isolation and returns SQLSTATE 40001 on contention, which naive Postgres drivers do not retry. Start with pdo_pgsql and only adopt a custom driver if serialization retries are a measurable production problem.
- How do I install and configure it in Symfony?
- Install it with Composer and register the bundle in your Symfony application, then point doctrine.dbal at your CockroachDB cluster using the driver it registers. Configuration is handled through the bundle's Doctrine connection settings rather than Laravel-style config/database.php entries. Check the README for the exact driver name and connection parameters, because the package is a thin DI layer over the underlying DBAL driver.
- Is it compatible with Doctrine DBAL 4?
- That is one of the first things to verify. DBAL 4 compatibility is an open risk because DBAL 4 reworked the driver and middleware APIs, and a niche driver with no dependents has little pressure to track that change. Confirm whether the driver supports DBAL 4 or is pinned to 3.x before you commit.
- How does the driver handle CockroachDB transaction retries on SQLSTATE 40001?
- The retry loop is the main technical reason to look at this repository, so inspect it closely. You want bounded retries with exponential backoff and jitter, not an unbounded immediate retry loop that can amplify contention. Verify the backoff strategy and retry limits against your expected transaction contention before trusting it in production.
- Does it retry correctly inside savepoints and under SELECT ... FOR UPDATE?
- This is a key question to verify, not a documented guarantee. Retrying inside savepoints and under SELECT ... FOR UPDATE is where naive retry implementations often break correctness by replaying partial work or releasing locks incorrectly. Test those paths explicitly if you vendor the driver.
- What CockroachDB schema and migration limitations should I expect?
- CockroachDB diverges from Postgres in ways that affect migrations and introspection, not just queries. Expect no advisory locks, no LISTEN/NOTIFY, no stored procedures, restricted trigger support, and schema-change restrictions around column type changes. A driver can smooth over some platform detection, but it cannot make unsupported Postgres features work.
- How should I test the driver before adopting it in a Laravel or Symfony app?
- Run a spike against a real CockroachDB cluster with stock pdo_pgsql first and measure whether 40001 serialization errors are actually a problem. If you vendor the driver, write tests that force serialization failures, exercise savepoints and SELECT ... FOR UPDATE, and assert bounded retry behavior. Instrument retry attempts, retry exhaustion, and added latency per transaction so you can compare it with the plain Postgres driver.
- Is it production-ready and maintained, and what are the alternatives?
- Treat it as high-risk: it has two stars, zero dependents, a single maintainer, and no release history to extrapolate, so the bus factor is one. There is no evidence in the assessment that it is running in production anywhere, and the better-trodden alternative is the stock pgsql driver. If your Laravel app already uses Doctrine through laravel-doctrine/orm, fork the driver class into an internal namespace with the upstream commit SHA recorded and register it from a service provider.