Scylloquent Laravel Package

Technical Evaluation

Architecture fit

Scylloquent is an Eloquent driver that maps Laravel's Active Record layer onto Cassandra/ScyllaDB via CQL. The core tension is that Eloquent's contract is relational: joins, eager-loaded relationships, foreign keys, transactions/savepoints, auto-incrementing keys, offset pagination, and arbitrary WHERE/ORDER BY composition. Cassandra/ScyllaDB has none of these in the relational sense — it is a partitioned wide-column store where the query pattern dictates the schema, joins do not exist, ORDER BY is limited to clustering columns, and non-key filtering either fails or requires ALLOW FILTERING (a full-scan footgun at scale).

This means the package can plausibly give us Eloquent-flavored syntax over single-table, partition-key-addressable access paths — models, casts, accessors, events, basic CRUD — but it cannot give us Eloquent semantics. Any model that leans on relationships, ad-hoc filtering, or transactional integrity will either break or silently degrade into expensive cluster operations. The fit is therefore narrow: a secondary connection for a bounded set of high-write, query-first workloads, not a drop-in replacement for the primary RDBMS.

Integration feasibility

Feasible but with a non-trivial native dependency chain. CQL access from PHP typically requires the Cassandra native extension (or a pure-PHP CQL client), which in turn pulls in the DataStax/cpp-driver toolchain. That has to be compiled or installed consistently across developer machines, CI runners, and container images — a recurring source of "works locally, fails in the pipeline" friction.

Migrations are the second feasibility question. Cassandra DDL is CREATE TABLE ... PRIMARY KEY (...) with no Blueprint equivalent; schema portability across the two engines is not achievable, so we should expect to maintain CQL DDL by hand or accept partial migration support.

Third, connection semantics: consistency levels, token-aware routing, prepared statements, and per-query timeouts are first-class concerns in Cassandra that Eloquent's connection abstraction has no vocabulary for. We would need to verify how (or whether) these are configurable, because defaults chosen for a relational driver are wrong for a distributed store.

Technical risk

• Semantic mismatch (high). Teams will write Eloquent idioms out of habit and get either exceptions or pathological cluster load. This is a training and code-review risk, not just a library risk.
• Vendor/maintainer risk (high). 29 stars, single maintainer, low opportunity score (1.14) and low composite score (1.55) indicate minimal ecosystem pull. Bus factor is effectively one; Laravel major-version compatibility is unlikely to be prompt. Budget for the possibility of forking.
• Native extension risk (medium-high). Extension availability, PHP version coupling, and container image maintenance are ongoing costs.
• Silent-correctness risk (medium). Wrong consistency level or a mis-specified partition key produces wrong answers under load rather than errors. Harder to catch in tests than a SQL failure.
• Lock-in risk (medium). The data model is not portable. Choosing Scylla means the schema, not just the driver, is committed.

Key questions

1. Which specific access paths justify Scylla over Postgres/MySQL, and are they all single-partition lookups or bounded range scans?
2. Does the package support CQL DDL/migrations, and to what degree?
3. How are consistency level, timeouts, retry policy, and prepared-statement reuse configured per connection?
4. Is it built on the native extension or a pure-PHP client — and what does that mean for our CI images?
5. Which Eloquent features are explicitly unsupported (relationships, transactions, chunkById, offset pagination, whereHas)? Is there a documented failure mode versus silent degradation?
6. What is the Laravel/PHP version support matrix, and is there any release cadence history?
7. Who owns the fork if the maintainer goes dormant?

Integration Approach

Stack fit

Treat Scylloquent as a secondary connection, sibling to the primary relational database, configured as a distinct Eloquent connection. Do not attempt to move existing models onto it. The relational core (users, billing, permissions, anything requiring joins or multi-row transactions) stays where it is. Scylla earns its place only for append-heavy, high-throughput, partition-addressable domains: event/audit streams, activity feeds, time-series metrics, session or token stores, notification queues.

A cleaner long-term shape is to keep Eloquent out of the hot path entirely: define a small repository interface per Scylla-backed domain and let Scylloquent be one implementation detail behind it. That preserves an exit to the raw driver or a different store without touching domain code, and it gives us a natural place to enforce partition-key discipline.

Migration path

No migration path exists for existing relational data in any automated sense — this is greenfield schema design. Sequence:

1. Schema derivation first, code second. Pick candidate domains, enumerate the exact queries the application will run, and derive partition/clustering keys from those queries. Any domain whose queries cannot be enumerated up front is a non-candidate.
2. Spike (2–3 weeks). Stand up ScyllaDB in Docker locally and in CI. Prove the extension installs reproducibly on our base image. Implement two or three of the enumerated queries as Scylloquent models, including one deliberately relational-ish query to document where it fails.
3. Repository seam. Wrap the validated models behind interfaces so application code never imports Eloquent for Scylla domains.
4. Pilot one non-critical, write-heavy domain. Instrument it. Compare latency and error rates against the current relational implementation before committing more surface area.

Compatibility

Pin the package version and the PHP/Laravel versions in CI, and add a compatibility gate: if the package has no release supporting our Laravel target, the pilot does not start. Confirm the native extension is available for our PHP minor in the base image before any application work begins — this is a hard prerequisite, not a detail.

Sequencing

Data modeling → driver/extension feasibility → repository seam → single-domain pilot → measure → expand or abandon. Explicitly gate expansion on measured benefit; the low adoption signal suggests the default answer to "expand" should be no unless the pilot is clearly favorable.

Operational Impact

Maintenance

Ongoing costs sit mostly outside the package: container images must carry the CQL extension and its native driver, base-image upgrades require recompiling or re-pinning, and PHP minor upgrades require re-validating the whole chain. The package itself is small and slow-moving — we should plan to vendor or fork it rather than depend on upstream responsiveness for Laravel major bumps. Budget roughly a fraction of an engineer's time for the dependency chain alone, plus the initial fork-readiness work.

Support

Effectively no commercial or community support. Internal ownership must be explicit: one named owner for the driver/extension chain and one for the data model. Documentation for Eloquent usage over Cassandra is thin, so our own runbook — supported idioms, forbidden patterns, consistency defaults — becomes the real support surface. That runbook is a deliverable, not an afterthought.

Scaling

Where Scylla shines, it shines genuinely: linear horizontal scale, predictable tail latency at high write volume, no primary-write bottleneck. Scylloquent does not impede that as long as queries stay partition-scoped. Scaling hazards are all modeling hazards — unbounded partition growth (a hot partition key like a tenant ID or a date bucket), tombstone accumulation from delete-heavy or TTL-heavy access, and ALLOW FILTERING sneaking into generated queries. Offset-based pagination through Eloquent is the highest-risk scaling pattern; cursor/token paging must be mandated and enforced in review.

Failure modes

• Full-cluster scans from non-key filters; latency cliff appears only under production data volume.
• Coordinator timeouts and retry amplification under partial failure (a Cassandra-specific behavior Eloquent has no mental model for).
• Wrong consistency level → stale or lost reads/writes without an exception.
• Hot partition saturation from a poorly chosen key — invisible in staging, fatal in production.
• Migration/DDL drift because schema is hand-maintained CQL rather than versioned through artisan migrate.
• Package abandonment leaving us pinned to an aging Laravel.
• Silent feature degradation if unsupported Eloquent methods return partial results instead of throwing — must be verified during the spike.

Ramp-up

The library is easy to learn; the data modeling is not. Engineers fluent in Eloquent will need genuine Cassandra/Scylla training — partition and clustering key design, denormalization as a deliberate choice, consistency tradeoffs, and the operational vocabulary of compaction, repair, and tombstones. Estimate several weeks before a mid-level engineer produces trustworthy Scylla schemas unsupervised, and note that Scylla operational knowledge (node management, repair scheduling, capacity planning) is a separate skill from application-side data modeling. That expertise gap, not the 29-star package, is the dominant cost in this evaluation.