Cassandra Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. skip for Cassandra access (revisited in light of v1.8.0). The package is no longer purely a cluster/session DI wrapper — v1.8.0 exposes CQL table options (comment, speculative_retry, additional_write_policy, gc_grace_seconds, bloom_filter_fp_chance, default_time_to_live, compaction, compression, caching, memtable_flush_period_in_ms, read_repair). That moves it from "container wiring" into declarative schema/DDL management. The decision it informs is now: do we own schema-option plumbing in-house, or adopt this? The hand-rolled alternative is meaningfully larger than the ~150 lines of service config previously assumed — so the buy case is stronger than the last review concluded, but only if the option handling is validated and versioned.
• Vendor-risk reclassification — provisional. The prior assessment's core premise ("last release April 2019, dormant") no longer holds: there is now a v1.8.0. Treat this as unverified reanimation, not renewed health — a single release note is not a maintenance cadence, and the note reads like a fragment of documentation with no changelog, no BC statement, and no author/support signal. Downgrade from "clear retire signal" to "requires provenance check": who published it, is it a fork, are there open issues/commits since 2019? Two outcomes drive different decisions — a genuine revival lowers risk; an unsourced one-off bump raises it (unreviewed schema code is worse than none).
• Cassandra version-targeting decision. Several listed options (additional_write_policy, read_repair, speculative_retry) are Cassandra 4.0-era table options. A wrapper advertising them implies a newer cluster/protocol target than a 2019-era driver pin, which is exactly the kind of silent assumption that breaks in production. Use this as an input to which cluster versions we officially support from app code — and verify the pinned driver/protocol actually matches.
• Data-lifecycle risk as a product concern, not just an engineering one. default_time_to_live, gc_grace_seconds, and compaction are now configurable from application code. A config typo in a deploy can silently expire customer records or change tombstone/repair behaviour with no application error. This is a governance decision: does app config get authority over table lifecycle, or does that stay with the DBA/schema-owner workflow? For most orgs the right answer is "schema options stay out of app deploys" — which itself argues against adopting this feature even if the package is healthy.
• Feature scoping for internal tooling. For ops dashboards / reporting / admin surfaces where the team already creates tables in-app, the expanded option surface is sufficient and avoids a separate data-access service. For customer-facing data, it is not.
• Not supported: greenfield architecture, multi-region/HA claims, SLA-backed support, or any workflow where schema ownership sits outside the app team.

When to Consider This Package

Consider it only when all of the following hold:

• You have an existing Symfony 2.x/3.x application on PHP 7.x in production, already committed to datastax/php-driver, and cannot move it this quarter.
• You want container-managed cluster/session wiring and are willing to let the app own table-option configuration (not just connections) — i.e., your schema-owner model already permits that.
• You have independently verified v1.8.0's provenance: publisher identity, commit history since 2019, open-issue responsiveness, and whether the note reflects code or docs. Do not infer maintenance from a version number.
• You have read the source to confirm what the option list actually does: are options applied via migrations, at runtime, or only passed through to a DDL builder? What are the defaults, validation rules, and BC guarantees versus the previous config schema?
• Your composer install resolves on your current PHP/Symfony matrix and the pinned driver version matches your cluster's protocol version.
• The integration is internal-facing, and a bad option or unsupported driver is a contained outage — not a customer-data expiry or compliance event.

Look elsewhere (or write it yourself) when:

• You are on Symfony 4+/PHP 8.x — constraints and the driver will fight you; new work should target CQL-over-HTTP or a managed-service gateway.
• You are greenfield — register the driver in services.yaml; the abstraction's value is convenience, not capability.
• Schema options must stay under DBA/schema-owner control — v1.8.0's headline feature is then a liability, not a benefit, and you should pin to the wiring-only behaviour or fork with the DDL surface removed.
• You need maintenance guarantees, observability depth, connection-pool policy, or multi-cluster routing — still not credible at this adoption level, and one release does not change that.
• You are evaluating managed Cassandra/Astra/Stargate — prefer the HTTP API path.

Gate before adoption: (1) provenance check on v1.8.0 — publisher, commits, issues, changelog, whether a release exists in the repo at all; (2) read the option-handling source and confirm it is additive — a table-option config surface can break strict config validation on upgrade; (3) composer-resolve spike on your PHP/Symfony matrix against your cluster protocol version; (4) explicitly decide who owns default_time_to_live/gc_grace_seconds before enabling the feature. Budget 1–2 engineering days; if it fails, the fork-and-own path costs roughly the same and lets you keep the DDL surface out.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed convenience layer for an older generation of our stack, with essentially no community behind it. The prior read was "dormant, plan to retire." A new v1.8.0 exists, but it expands the package's authority rather than demonstrating health: it now lets application config set table-level data-lifecycle parameters (TTL, tombstone grace, compaction). That is more surface area and more blast radius, from a supplier with no support commitment and unverified provenance. Recommendation is unchanged in direction and firmer in urgency: not a strategic dependency, not approved as a data-access foundation for anything new, and now carrying a schema-ownership question we should not delegate to it. Replacing it remains measured in days, so eliminating it during the next planned upgrade is cheap; the new risk is that teams start using the DDL feature before we've decided who owns table lifecycle.

To engineering: Treat this as a reference implementation, not a library, and treat v1.8.0 as unproven — verify the publisher, the commit history, and whether the release note describes shipped code or only documentation of accepted keys. The option list (compaction, compression, caching, gc_grace_seconds, default_time_to_live, speculative_retry, read_repair, additional_write_policy, bloom_filter_fp_chance, memtable_flush_period_in_ms) is Cassandra 4.0-era, which conflicts with a 2019 driver pin — check the actual driver/protocol requirement before trusting it. Several of those keys are destructive if mistyped from config; schema options should stay in migrations reviewed by whoever owns the cluster, not in app deploys. Recommended path: (1) provenance and source-read spike; (2) confirm the option surface is additive and does not break existing config validation; (3) if the service is legacy, frozen, and internal, use the wiring and explicitly disable or fork out the DDL surface, recording the fork obligation; (4) otherwise vendor the service configuration yourself and keep the dependency off the graph. Either way, pin the driver version explicitly and do not build new abstractions on top of it.