An increasing number of customers are migrating to Spanner from legacy NoSQL environments like Apache Cassandra. The strategic drivers are evident: a markedly lower total cost of ownership (TCO), elastic scalability, and near-zero maintenance overhead.
With the general availability of the native endpoint enabling Cassandra Query Language (CQL) APIs on Spanner, your existing Cassandra applications can now leverage Spanner’s enterprise foundation, featuring strong consistency, virtually limitless scale, and 99.999% availability — all while utilizing familiar CQL.
Better yet, migrating your application to Spanner with the CQL interface typically requires only a one-line code change, as your existing CQL statements remain valid. Combined with our integrated, high performance bulk and live migration tools, your transition from Cassandra to Spanner is simple.
Beyond NoSQL: Strategic solutions for Cassandra Users
While the CQL API facilitates the move, Spanner addresses the fundamental data integrity and operational constraints inherent in traditional Cassandra architectures:
-
Global ACID transactions: Minimize concerns regarding eventual consistency. Achieve comprehensive global ACID transactions to help ensure data integrity at any scale.
-
Powerful indexing: Strongly consistent secondary indexes support complex query patterns with built-in optimization and no integrity risks.
-
Rich SQL: Utilize a sophisticated SQL interface that supports joins and aggregations.
-
High reliability: Benefit from 99.99% availability in regional setups and 99.999% in multi-regional configurations.
-
Compliance and latency: Simplify data residency compliance with geo-partitioning, delivering low-latency local reads and writes to a global user base.
-
Built-in observability: Access a suite of performance metrics and charts directly in the Google Cloud console at no additional cost.
The native CQL endpoint provides a clear pathway to decouple your existing Cassandra applications and modernize them using the full power of Spanner. Let’s look at the next steps after migrating your data and applications from Cassandra to Spanner.
Tweak Spanner for your specific workload
Following your migration, here’s how to optimize your Spanner environment for your workload.
1. Optimize costs and operational efficiency
|
Workload Characteristics |
Recommended Solution |
Primary Benefit |
|
Write-intensive traffic |
Up to a 6x increase in write throughput via request bundling (with minimal latency impact). |
|
|
Variable or fluctuating traffic |
Automatically aligns capacity with demand, eliminating over-provisioning costs. |
|
|
Steady-state, baseline capacity |
Secure up to 40% savings on steady-state operational costs. |
|
|
Storage-intensive workloads |
Utilize cost-effective HDD storage for a significant reduction in long-term storage expenses. |
2. Achieve low latencies
We continuously enhance Spanner’s performance to support mission-critical, high-concurrency workloads.
-
Single-digit millisecond performance: Spanner consistently delivers under 5ms latency for both read and write operations.
-
Repeatable read isolation: This feature utilizes optimistic concurrency to reduce latency and transaction aborts in read-heavy, low-contention scenarios.
-
Read leases: Enable strongly consistent reads in multi-region instances without cross-region coordination, maximizing node efficiency and performance.
3. Prepare for peak traffic surges
For planned events like marketing launches or massive data ingestions, you can proactively manage capacity:
-
Manual split APIs: While Spanner handles data partitioning automatically, the pre-splitting capability allows you to exactly define how your database distributes data ahead of peak loads. This helps ensure immediate utilization of new capacity for stable performance.
4. Isolate operational and analytical pipelines
Prevent resource contention by isolating BI and ETL processes from core operations:
Deconstruct your Cassandra ecosystem
Migrating from Apache Cassandra to Spanner is a strategic opportunity to decouple your architecture from a complex web of sidecar utilities. While the Cassandra-compatible API serves as the entry point, the true value lies in collapsing the operational “Cassandra tax” into a unified, managed multi-model ecosystem.
