Doctrine Cockroachdb Bundle Laravel Package

Product Decisions This Supports

• Database platform bet: Choosing CockroachDB (distributed SQL, multi-region survivability, Postgres wire compatibility) over vanilla Postgres/MySQL for a service that needs geographic resilience. This package is a small enabler of that decision, not the reason for it.
• Build vs. buy (driver layer): The alternative is writing and maintaining a custom Doctrine DBAL driver/platform for CockroachDB in-house. This package is a shortcut for that narrow piece of plumbing — schema handling, type mapping, migrations against CockroachDB.
• PHP/Symfony stack feasibility: Answers "can our Doctrine-based app talk to CockroachDB without exotic workarounds?" If yes, PHP stays viable for that service; if no, it becomes an argument for a different runtime or a different database.
• Scope correction for Laravel shops: This is a Symfony bundle, not a Laravel package. Laravel's Eloquent does not use Doctrine DBAL, so it is irrelevant to a standard Laravel codebase. It only matters if you run Doctrine inside Laravel via a bridge (e.g., laravel-doctrine/orm) or operate Symfony services alongside Laravel ones.
• Roadmap/portfolio triage: Worth a slot only if you already have (or plan) a Symfony service on CockroachDB. It should not drive a roadmap item on its own.

When to Consider This Package

Consider it when all of the following hold:

• You are on Symfony (or a Doctrine DBAL-based stack) and have already committed to CockroachDB.
• You need ORM-level integration — migrations, schema introspection, type mapping — not just a connection string.
• You are willing to vendor or fork the code and own a test suite around it, given 2 stars, 0 dependents, and a single-maintainer bus factor.
• You accept that "last release 2025-10-10" is recency, not proof of production hardening.

Look elsewhere when:

• You are Laravel/Eloquent-only — this does nothing for you.
• You only need basic connectivity: CockroachDB speaks the Postgres wire protocol, so the mature Doctrine Postgres platform often gets you most of the way with far less risk.
• You need an SLA, vendor support, security review, or a maintained dependency with multiple contributors.
• Your CockroachDB usage is read-heavy/simple and doesn't exercise the driver's CockroachDB-specific behavior — the abstraction may not pay for itself.

How to Pitch It (Stakeholders)

Executive summary: A small, MIT-licensed Symfony bundle that lets Doctrine-based PHP applications talk to CockroachDB. It is a tactical enabler, not a strategic dependency — 2 GitHub stars, zero known dependents, and a single maintainer mean it should be treated as glue code we may need to own, not a vendor relationship.

Recommendation: Only relevant if we have already chosen CockroachDB and the service is Doctrine/Symfony-based. In that case, run a time-boxed proof of concept (migrations, schema sync, representative queries), then vendor a pinned fork with our own integration tests rather than depending on the upstream directly. If either precondition is false — especially if the stack is Laravel/Eloquent — the default integration path is CockroachDB's Postgres compatibility, and this package should be dropped from consideration.