Scylloquent Laravel Package

Product Decisions This Supports

• Polyglot persistence for a Laravel codebase. Decides whether to add ScyllaDB/Cassandra as a second data store for a specific workload (high write throughput, time-series, event/audit logs, telemetry, feeds, session or notification fan-out) without introducing a second service, a second language, or a second data-access paradigm.
• Standardizing on Eloquent as the single data facade. Whether developers should keep one mental model (models, attributes, query builder) across SQL and wide-column stores — a real onboarding and cognitive-load decision that affects hiring and velocity.
• Build vs. buy vs. fork. The realistic options are: (a) adopt this MIT adapter, (b) build an in-house repository/CQL layer over the native ext-cassandra driver, or (c) isolate ScyllaDB behind a dedicated ingestion microservice. This package makes (a) cheap to try and cheap to abandon.
• Scope containment decisions. Whether a bounded context (analytics sink, activity log, IoT ingest) can ship on Laravel + ScyllaDB, while the transactional core stays on PostgreSQL/MySQL.
• Roadmap sequencing. Whether the NoSQL path is a spike, an internal-tool dependency, or a platform commitment — each implies different due diligence on maintenance risk.
• Use-case fit: partition-key lookups, inserts, and clustering-key range scans over pre-modeled tables. Not ad-hoc querying, joins, or cross-entity transactions.

When to Consider This Package

Adopt when:

• ScyllaDB/Cassandra has already been chosen for a concrete, well-understood workload — not the other way around.
• Access patterns are known in advance and simple (get-by-partition-key, insert, range scan). Wide-column modeling requires query-first design; an ORM does not remove that constraint.
• You are on a modern Laravel version and accept partial Eloquent semantics — expect limited or no relationship/eager-loading support, no conventional migrations, and a constrained query builder. Verify before committing.
• The blast radius is small: one bounded context, non-transactional data, tolerant of eventual consistency.
• Your team can vendor or fork the package (MIT permits it) and own it. With ~29 stars and a single maintainer, treat maintenance as an internal responsibility from day one.

Look elsewhere when:

• You need joins, referential integrity, or multi-table transactions — use a relational store and standard Eloquent.
• You need migrations, full relationship graphs, model events, or soft deletes as first-class features.
• You require vendor support, an SLA, security patching cadence, or a broad community to hire against. At this adoption level, the package is a convenience layer, not a platform.
• Query patterns are unknown or ad-hoc. The Eloquent abstraction can make CQL look more flexible than it is; ALLOW FILTERING and full scans are production incidents waiting to happen.
• Team lacks Cassandra/ScyllaDB data-modeling expertise — the ORM will not compensate, and the failure mode is a performance cliff, not an exception.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed adapter that lets our existing Laravel team write to ScyllaDB using the Eloquent syntax they already know. It lowers the cost and time-to-value of adding a high-throughput data path — potentially avoiding a new microservice or a new language in the stack. It is not a platform commitment: low adoption and a single maintainer mean we treat it as a prototype enabler with a fork-and-own fallback to the native driver.

To engineering: It reduces boilerplate and keeps one data-access idiom across stores, which helps velocity and onboarding. But it does not abstract away Cassandra's real costs — denormalization, partition-key design, consistency levels, and tombstone/compaction behavior remain ours to own. Recommendation: run a time-boxed spike with explicit exit criteria (supported operations, performance vs. native driver, upgrade path on the next Laravel major), and decide fork-vs-replace before it touches production traffic.