Cassandra Bundle Laravel Package

Product Decisions This Supports

• Framework-fit triage (the first decision, and it's a "no"): Despite being filed alongside Laravel/PHP packages, this is a Symfony 2-era bundle, not a Laravel package. There is no service provider, no facade, no config publishing, no Laravel-compatible autowiring. The PM decision is therefore not "adopt or skip" but "treat as reference architecture": read it, extract the pattern (YAML-defined clusters → lazily created session services → injected connection objects), and spend 1–3 engineer-days writing a thin Laravel service provider plus a Cassandra\Connection binding of our own. That is a spike, not a procurement, and it produces code we own.
• Build vs. buy where "buy" doesn't exist: 29 stars, 0 dependents, last release March 2020, archived, MIT. There is no vendor, no support contract, no maintenance path. The real comparison is "write ~300 lines of Laravel glue around a driver" versus "fork and own an abandoned Symfony bundle." The fork is strictly worse: same ownership burden, more surface area, wrong framework.
• Roadmap scoping for legacy estates: The only environment where this ships as-is is an existing Symfony 2.x monolith already running a live Cassandra cluster. For a PM with such a service in the portfolio, this bundle is a migration scoping artifact: its configuration schema is effectively the checklist of what our replacement layer must own — cluster/contact-point config, keyspace selection, consistency and retry policy, prepared statements, connection pooling, profiling hooks. That checklist is the input to the replacement estimate.
• Prior-art review before committing to Cassandra at all: If the roadmap question is "is Cassandra right for our write-heavy / time-series / multi-DC workload," inspecting this bundle calibrates how much application complexity the framework layer absorbs — and the answer is: very little. The hard parts live in the driver, in data modeling, and in operations (compaction, repair, tombstones, consistency tuning). The PM takeaway is that the integration is cheap and the operational commitment is expensive, which redirects the decision toward "do we staff Cassandra ops?" rather than "which package do we install?"
• Dependency hygiene / risk register: Archived repo + deprecated datastax/php-driver + native ext-cassandra compilation requirement is an automatic tech-debt entry with an explicit trigger condition. PM decision to fund: if this service needs a PHP 8 upgrade, the driver layer must be replaced first. Better to schedule that as bounded work than to discover it during an emergency.
• Use-case validation: Cassandra is defensible for append-heavy, high-write, query-by-known-key, multi-DC workloads. It is a poor fit for ad-hoc reporting and evolving access patterns. This package offers zero help with that judgement — which is precisely the judgement the PM must make before any integration work is greenlit.
• Opportunity signal (score 0.46, opportunity 2.41): Quantitatively corroborates the qualitative read — tiny audience, dead framework target, no downstream consumers, no ecosystem safety net. A cheap spike must not be allowed to become a permanent dependency by default.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining a Symfony 2.x application with a live Cassandra cluster and an already-working ext-cassandra install.
• You need the container wiring immediately for an internal tool or throwaway bridge, and you are willing to vendor/fork the source rather than depend on a Packagist release frozen at March 2020.
• You have a named owner, a pinned PHP version, and a documented removal date — the repo is archived, so upstream fixes will never arrive.
• Your PHP/driver versions still match what the bundle was built against.

Look elsewhere — decisively — when:

• The target is Laravel. There is no Laravel integration here. Budget a custom service provider; do not attempt to bend a Symfony bundle into a Laravel app.
• The target is Symfony 5/6/7 or any current framework. Flex, autoconfiguration, and modern DI conventions are incompatible with this bundle's service definitions without a fork.
• The project is greenfield. Building a new product on an archived bundle plus an EOL driver guarantees a migration project before the first renewal.
• You require PHP 8 support, maintained CI, security patching, or vendor accountability. None of these exist here, and there are no public references or community answers given the zero-dependent count.
• Your team lacks Cassandra operations experience. The package solves DI wiring; it solves nothing about the failure modes that actually sink Cassandra projects.
• You are on a managed Cassandra-compatible service (Astra, Keyspaces, ScyllaDB Cloud). Driver and CQL protocol compatibility are the binding constraint — verify those before any framework glue discussion.
• The workload is read-latency-sensitive or needs ad-hoc queries. Choose Postgres, DynamoDB, or ScyllaDB and skip the integration cost entirely.

How to Pitch It (Stakeholders)

One-liner: A tiny, archived Symfony 2 glue layer for Cassandra that is valuable as a reference design and useless as a Laravel dependency — cheap to learn from, expensive to depend on.

For executives: Approve a short, time-boxed spike to extract the wiring pattern if we have a genuine Cassandra requirement; do not approve this as a production dependency for a Laravel product. It is archived, has no maintainers and no consumers, and is built for a framework we do not ship. The strategic value is that it clarifies where the real cost sits: the bundle is ~300 lines of container configuration, while the binding commitments are driver lifecycle, schema and query design, and Cassandra operations staffing. If any live service already depends on it, that service is on a frozen platform — a known, bounded replacement item to schedule deliberately rather than inherit during an upgrade fire.

For engineering: 29 stars, zero dependents, last release March 2020, archived, built on the deprecated datastax/php-driver for Symfony 2. Read the source in an hour — take the config schema and the session-management pattern, then write a small Laravel service provider that binds a Cassandra\Connection and encapsulates session creation, prepared statements, consistency, and retry policy behind an application-owned interface. Keep CQL in repositories, not controllers, so the driver can be swapped later without touching product code. Document the ext-cassandra native-extension requirement up front — it is the single most common first-day failure. If we must consume the bundle, vendor it into the repo with a named owner, a pinned PHP version, and a removal ticket.

Framing to use: "Cheap to learn from, expensive to depend on — and it isn't a Laravel package anyway, so we're really deciding whether to build a small adapter, not which dependency to take."