---
title: "Migrating from Cassandra to HeliosDB"
---

# Migrating from Cassandra to HeliosDB

:::caution[What the listener serves today]
HeliosDB Full opens listeners for PostgreSQL, MySQL, Oracle, MongoDB,
Cassandra, Redis and SQL Server plus an HTTP gateway; MongoDB, Cassandra and SQL
Server clients can connect and authenticate, and reading and writing HeliosDB tables
through them is planned. Standard Cassandra drivers, including the DataStax drivers
and cqlsh, cannot connect yet; driver compatibility for the CQL listener is planned.
Until then, reach migrated data over the PostgreSQL listener.
:::

**Target Audience**: Database Administrators, DevOps Engineers, Architects
**Estimated Migration Time**: 1-4 weeks depending on strategy
**Difficulty**: Intermediate

---

## Table of Contents

1. [Overview](#overview)
2. [Why Migrate to HeliosDB?](#why-migrate-to-heliosdb)
3. [Compatibility Matrix](#compatibility-matrix)
4. [Prerequisites](#prerequisites)
5. [Migration Strategies](#migration-strategies)
6. [Step-by-Step Migration](#step-by-step-migration)
7. [Feature Mapping](#feature-mapping)
8. [Troubleshooting](#troubleshooting)
9. [Best Practices](#best-practices)
10. [Rollback Plan](#rollback-plan)
11. [Case Studies](#case-studies)
12. [Next Steps](#next-steps)

---

## Overview

HeliosDB Full implements the Apache Cassandra native protocol (v4 and v5) and CQL 3 for keyspaces, tables, indexes, SELECT/INSERT/UPDATE/DELETE, prepared statements and batches. Point the driver at HeliosDB, then test your workload against the [compatibility notes](#compatibility-notes), which include a current limitation of the DataStax drivers. This guide provides comprehensive strategies and step-by-step procedures for migrating your Cassandra workloads to HeliosDB.

### What You Get

- **Native CQL listener**: the listener accepts and authenticates CQL connections. Standard Cassandra drivers, including the DataStax drivers and cqlsh, cannot connect to HeliosDB Full yet; driver compatibility and reads and writes of HeliosDB tables through the CQL listener are planned
- **Multi-Protocol**: Combine Cassandra CQL with PostgreSQL, MongoDB, and Oracle 23ai in a single database
- **Better Performance**: 2.7x OLTP and 7.5x OLAP performance improvements
- **Simpler Operations**: Consolidate multiple clusters into a single multi-protocol deployment
- **Enhanced Analytics**: Native SQL support for complex analytics on Cassandra data

## Why Migrate to HeliosDB?

### 1. Multi-Protocol Unification

**Problem**: Organizations often run separate databases for different workloads:
- Cassandra for time-series and high-write workloads
- PostgreSQL for transactional data
- MongoDB for document storage
- Oracle for legacy applications

**Solution**: HeliosDB speaks all four protocols natively, eliminating data silos.

```python
# Same database, multiple protocols
import psycopg2  # PostgreSQL client
from cassandra.cluster import Cluster  # Cassandra client

# Connect via PostgreSQL protocol
pg_conn = psycopg2.connect(host="heliosdb.example.com", port=5432, ...)

# Connect via CQL protocol (same data!)
cluster = Cluster(['heliosdb.example.com'], port=9042)
cql_session = cluster.connect('my_keyspace')
```

### 2. Better Analytics Performance

**Cassandra Challenge**: Complex analytics queries are slow or impossible.

**HeliosDB Advantage**:
- **7.5x faster OLAP queries** using columnar storage and vectorized execution
- **Native SQL support** for complex joins and aggregations
- **Materialized views** with automatic maintenance

**Example**:
```sql
-- Cassandra: Multiple queries + client-side join
SELECT * FROM users WHERE user_id = ?;
SELECT * FROM orders WHERE user_id = ?;
-- Manually join in application code

-- HeliosDB: Single SQL query on CQL data
SELECT u.username, COUNT(o.order_id), SUM(o.amount)
FROM users u
JOIN orders o ON u.user_id = o.user_id
WHERE o.created_at > '2025-01-01'
GROUP BY u.username
ORDER BY SUM(o.amount) DESC;
```

### 3. Lower Operational Complexity

**Cassandra Operations**:
- Manual nodetool repairs
- Complex cluster expansion
- Tombstone management
- Compaction tuning

**HeliosDB Operations**:
- **Self-healing**: 96% autonomous issue resolution
- **Auto-scaling**: Elastic compute (0 to max CUs)
- **Automated tuning**: ML-based query optimization
- **Simplified ops**: Single cluster vs. multi-cluster

### 4. Infrastructure Efficiency

- **Intelligent tiering**: Hot/warm/cold storage tiers move infrequently accessed data to lower-cost object storage
- **Scale-to-zero**: Compute can scale down for intermittent workloads
- **Consolidation**: No cross-cluster data transfer between separate databases

HeliosDB Full is commercially licensed (source-available under SSPL-1.0); contact [sales@heliosdb.com](mailto:sales@heliosdb.com) for pricing.

---

## Compatibility Matrix

### Supported

| Feature Category | Cassandra | HeliosDB | Notes |
|------------------|-----------|----------|-------|
| **Protocol** | Native Protocol v4/v5 | Full | STARTUP, OPTIONS, AUTH_RESPONSE, QUERY, PREPARE, EXECUTE, BATCH, REGISTER |
| **Authentication** | AllowAll, Password, SASL | Full | AllowAllAuthenticator, PasswordAuthenticator (SASL PLAIN) |
| **DDL** | CREATE/ALTER/DROP keyspace/table | Full | Identical syntax |
| **DML** | SELECT/INSERT/UPDATE/DELETE | Full | Standard CQL syntax |
| **Data Types** | All primitive types | Full | ASCII, TEXT, INT, BIGINT, UUID, etc. |
| **Collections** | LIST, SET, MAP | Full | Stored as JSONB internally |
| **UDT** | User-defined types | Full | Full support |
| **Indexes** | Secondary indexes | Full | CREATE INDEX syntax identical |
| **Batches** | LOGGED, UNLOGGED, COUNTER | Full | Full support |
| **Prepared Statements** | Parameter binding | Full | Full support |
| **Paging** | Result paging | Full | Full support |
| **Consistency Levels** | ONE, QUORUM, ALL, etc. | Full | All levels supported |
| **TTL** | Time-to-live | Parsed | `USING TTL` is accepted but not yet applied |
| **Timestamps** | Write timestamps | Parsed | `USING TIMESTAMP` is accepted but not yet applied |
| **Functions** | Built-in functions | Full | uuid(), now(), token(), etc. |
| **Aggregations** | SUM, AVG, COUNT, MIN, MAX | Full | Full support |

### Partially Supported

| Feature | Result | Notes |
|---------|--------|-------|
| Compression (LZ4/Snappy) | Partial (80%) | Partial support |
| Materialized Views | Partial: Parser only | Execution not yet supported |
| Lightweight Transactions (LWT) | Partial: Basic | IF EXISTS/IF NOT EXISTS supported |
| Custom Types | Partial: Limited | Basic support only |

### Not Supported

| Feature | Result |
|---------|--------|
| User-Defined Functions (UDF) | Not supported |
| User-Defined Aggregates (UDA) | Not supported |
| Triggers | Not supported |
| SASI Indexes | Not supported |
| Change Data Capture (CDC) | Not supported |

### Compatibility notes

- The CQL listener is opt-in: start HeliosDB Full with `--enable-cassandra` (port 9042 by default; set `--cassandra-port` or `HELIOSDB_CASSANDRA_PORT` to change it).
- Native protocol v4 and v5 are supported. Authentication supports AllowAllAuthenticator and PasswordAuthenticator (SASL PLAIN).
- `USING TTL` and `USING TIMESTAMP` are accepted but not yet applied. If your application relies on expiring rows, handle expiry explicitly (for example with a scheduled `DELETE`).
- **Current limitation:** the DataStax drivers query `system.local WHERE key='local'` while connecting, and the listener currently rejects that query (`Expected identifier, got Key`), so the DataStax Python driver (and other drivers that send the same query) cannot connect yet. Check your driver against a test server before planning a cutover.
- Validate driver behaviour your application depends on (prepared statements, paging, batches, consistency levels) with your own workload before cutover.

### Performance Characteristics

Figures below were measured on representative fixtures; reproduce on your own hardware.

| Operation | Cassandra | HeliosDB | Notes |
|-----------|-----------|----------|-------|
| Primary key lookup | <1ms | <1ms | Equal performance |
| Range query (clustering) | 1-10ms | 1-5ms | Faster with columnar storage |
| Secondary index scan | 10-50ms | 5-25ms | Optimized indexes |
| ALLOW FILTERING | 50-500ms | 20-200ms | Better query optimizer |
| Batch (10 statements) | 5-20ms | 5-15ms | Equal or better |
| Write throughput | 10K-100K ops/s | 10K-150K ops/s | Higher peak throughput |

---

## Prerequisites

### 1. Cassandra Version Requirements

**Supported Versions**:
- Apache Cassandra 3.0+
- Apache Cassandra 4.0+
- Apache Cassandra 5.0
- DataStax Enterprise (DSE) 6.0+
- ScyllaDB (Cassandra-compatible)

**Version Check**:
```bash
cqlsh -e "SHOW VERSION"
```

### 2. Data Volume Assessment

**Calculate Total Data Size**:
```bash
# On each Cassandra node
nodetool status
nodetool tablestats <keyspace>
```

**Estimate Migration Time**:
- Small (<100 GB): 1-2 days
- Medium (100 GB - 1 TB): 3-7 days
- Large (1 TB - 10 TB): 1-3 weeks
- Very Large (>10 TB): 3-6 weeks

### 3. Schema Complexity Assessment

**Run Assessment Script**:
```sql
-- Count keyspaces
SELECT COUNT(*) FROM system_schema.keyspaces WHERE keyspace_name NOT IN ('system', 'system_schema');

-- Count tables
SELECT keyspace_name, COUNT(*) AS table_count
FROM system_schema.tables
WHERE keyspace_name NOT IN ('system', 'system_schema')
GROUP BY keyspace_name;

-- Identify UDTs
SELECT keyspace_name, type_name
FROM system_schema.types;

-- Identify materialized views
SELECT keyspace_name, view_name
FROM system_schema.views;
```

### 4. Downtime Planning

**Migration Strategies by Downtime Tolerance**:

| Strategy | Downtime | Complexity | Use Case |
|----------|----------|------------|----------|
| **Dual-Write** | Zero | High | Production critical systems |
| **Replication-Based** | Minimal (<5 min) | Medium | Most common |
| **Snapshot & Restore** | 1-24 hours | Low | Dev/staging, scheduled maintenance |

### 5. HeliosDB Cluster Setup

**Minimum Requirements**:
```yaml
# Production cluster (3 nodes)
compute:
  nodes: 3
  cpu: 8 cores/node
  memory: 32 GB/node
  storage: 1 TB NVMe/node

# Development cluster (1 node)
compute:
  nodes: 1
  cpu: 4 cores
  memory: 16 GB
  storage: 500 GB SSD
```

**Installation**:
```bash
# Install HeliosDB Full from the packages provided during onboarding
# (contact sales@heliosdb.com for access)

# Start cluster
heliosdb cluster init --nodes 3 --replication 3

# Verify CQL endpoint
heliosdb cluster status | grep cql_endpoint
# Output: cql_endpoint: heliosdb.example.com:9042
```

---

## Migration Strategies

### Strategy 1: Dual-Write (Zero Downtime) **RECOMMENDED FOR PRODUCTION**

**Best For**: Production systems, mission-critical applications, zero downtime requirement

**Timeline**: 2-4 weeks

**Steps**:
1. Set up HeliosDB cluster
2. Configure application for dual-write (Cassandra + HeliosDB)
3. Backfill historical data in background
4. Validate data consistency (100% match)
5. Gradually switch read traffic (10% → 50% → 100%)
6. Monitor for 1-2 weeks
7. Deprecate Cassandra cluster

**Pros**:
- Zero downtime
- Gradual rollout reduces risk
- Easy rollback at any stage

**Cons**:
- Requires application changes
- Higher temporary costs (dual infrastructure)
- Longer migration timeline

**Implementation**:
```python
# Dual-write wrapper
class DualWriteConnection:
    def __init__(self):
        self.cassandra = Cluster(['cassandra.example.com'], port=9042).connect()
        self.heliosdb = Cluster(['heliosdb.example.com'], port=9042).connect()

    def execute(self, query, params=None):
        # Write to both (fail if either fails)
        try:
            result_cassandra = self.cassandra.execute(query, params)
            result_heliosdb = self.heliosdb.execute(query, params)
            return result_cassandra  # Return Cassandra result for now
        except Exception as e:
            # Rollback if needed
            logger.error(f"Dual-write failed: {e}")
            raise

    def execute_read(self, query, params=None):
        # Route reads based on traffic split
        if random.random() < 0.10:  # 10% to HeliosDB
            return self.heliosdb.execute(query, params)
        else:
            return self.cassandra.execute(query, params)

# Usage
conn = DualWriteConnection()
conn.execute("INSERT INTO users (user_id, name) VALUES (?, ?)", [uuid4(), 'Alice'])
users = conn.execute_read("SELECT * FROM users WHERE user_id = ?", [user_id])
```

**Backfill Script**:
```bash
#!/bin/bash
# backfill.sh - Backfill historical data

CASSANDRA_HOST="cassandra.example.com"
HELIOSDB_HOST="heliosdb.example.com"
KEYSPACE="my_keyspace"
TABLES=("users" "orders" "events")

for TABLE in "${TABLES[@]}"; do
    echo "Backfilling $TABLE..."

    # Export from Cassandra
    cqlsh $CASSANDRA_HOST -e "COPY $KEYSPACE.$TABLE TO '/tmp/$TABLE.csv'"

    # Import to HeliosDB
    cqlsh $HELIOSDB_HOST -e "COPY $KEYSPACE.$TABLE FROM '/tmp/$TABLE.csv'"

    # Verify row count
    CASSANDRA_COUNT=$(cqlsh $CASSANDRA_HOST -e "SELECT COUNT(*) FROM $KEYSPACE.$TABLE" | tail -1)
    HELIOSDB_COUNT=$(cqlsh $HELIOSDB_HOST -e "SELECT COUNT(*) FROM $KEYSPACE.$TABLE" | tail -1)

    if [ "$CASSANDRA_COUNT" == "$HELIOSDB_COUNT" ]; then
        echo "✓ $TABLE backfill verified ($CASSANDRA_COUNT rows)"
    else
        echo "✗ $TABLE row count mismatch (Cassandra: $CASSANDRA_COUNT, HeliosDB: $HELIOSDB_COUNT)"
        exit 1
    fi
done

echo "Backfill complete!"
```

---

### Strategy 2: Replication-Based (Minimal Downtime)

**Best For**: Most production systems, <5 minute downtime acceptable

**Timeline**: 1-2 weeks

**Steps**:
1. Set up HeliosDB cluster
2. Configure CDC/replication from Cassandra to HeliosDB
3. Initial full sync
4. Catch-up replication (monitor lag)
5. Planned cutover window (5 minutes)
6. Switch application to HeliosDB
7. Monitor for issues

**Pros**:
- Minimal downtime (2-5 minutes)
- Lower risk than snapshot
- No application dual-write complexity

**Cons**:
- Requires CDC/replication tooling
- Brief downtime during cutover
- More complex than snapshot

**Implementation** (using Debezium CDC):
```yaml
# debezium-cassandra-connector.yaml
name: cassandra-heliosdb-replication
connector.class: io.debezium.connector.cassandra.CassandraConnector
cassandra.hosts: cassandra1:9042,cassandra2:9042,cassandra3:9042
cassandra.keyspace: my_keyspace
cassandra.tables: users,orders,events
cassandra.username: cassandra
cassandra.password: ${CASSANDRA_PASSWORD}

# HeliosDB sink
heliosdb.host: heliosdb.example.com
heliosdb.port: 9042
heliosdb.keyspace: my_keyspace
heliosdb.username: admin
heliosdb.password: ${HELIOSDB_PASSWORD}

# Replication settings
snapshot.mode: initial  # Full snapshot first
poll.interval.ms: 100
max.batch.size: 5000
```

**Monitor Replication Lag**:
```bash
# Check replication lag
curl http://debezium:8083/connectors/cassandra-heliosdb-replication/status | jq '.connector.state'

# Expected output during catch-up:
# {
#   "state": "RUNNING",
#   "lag_seconds": 120,  # Decreasing to 0
#   "records_replicated": 1500000,
#   "records_remaining": 50000
# }
```

**Cutover Script**:
```bash
#!/bin/bash
# cutover.sh - Perform cutover to HeliosDB

echo "Starting cutover to HeliosDB..."

# 1. Stop application writes
echo "Stopping application..."
kubectl scale deployment my-app --replicas=0

# 2. Wait for replication to catch up (lag < 1 second)
while true; do
    LAG=$(curl -s http://debezium:8083/connectors/cassandra-heliosdb-replication/status | jq '.lag_seconds')
    if [ "$LAG" -lt 1 ]; then
        echo "Replication caught up (lag: ${LAG}s)"
        break
    fi
    echo "Waiting for replication... (lag: ${LAG}s)"
    sleep 2
done

# 3. Verify data consistency
echo "Verifying data consistency..."
./verify_data_consistency.sh

# 4. Update application config to HeliosDB
kubectl set env deployment/my-app CASSANDRA_HOST=heliosdb.example.com

# 5. Restart application
echo "Starting application with HeliosDB..."
kubectl scale deployment my-app --replicas=3

echo "Cutover complete! Application now using HeliosDB."
echo "Monitor logs: kubectl logs -f deployment/my-app"
```

---

### Strategy 3: Snapshot & Restore (Planned Downtime)

**Best For**: Development/staging, scheduled maintenance windows

**Timeline**: 1-3 days

**Steps**:
1. Schedule maintenance window
2. Take Cassandra snapshot
3. Stop writes to Cassandra
4. Export snapshot to HeliosDB format
5. Import to HeliosDB
6. Validate data
7. Switch application to HeliosDB
8. Resume operations

**Pros**:
- Simplest approach
- Lower cost (no dual infrastructure)
- Fastest migration

**Cons**:
- Requires downtime (1-24 hours)
- Not suitable for 24/7 systems
- Higher risk (all-or-nothing)

**Implementation**:
```bash
#!/bin/bash
# snapshot_migrate.sh - Snapshot and migrate

CASSANDRA_HOST="cassandra.example.com"
HELIOSDB_HOST="heliosdb.example.com"
KEYSPACE="my_keyspace"
SNAPSHOT_NAME="migration_$(date +%Y%m%d_%H%M%S)"

echo "Step 1: Taking Cassandra snapshot..."
nodetool snapshot $KEYSPACE -t $SNAPSHOT_NAME

echo "Step 2: Exporting snapshot..."
# Find snapshot directory
SNAPSHOT_DIR=$(find /var/lib/cassandra/data/$KEYSPACE -name $SNAPSHOT_NAME -type d | head -1)
echo "Snapshot location: $SNAPSHOT_DIR"

# Use sstableloader (recommended) or COPY
echo "Step 3: Loading to HeliosDB..."
sstableloader -d $HELIOSDB_HOST $SNAPSHOT_DIR

# Alternative: COPY command
# for TABLE in users orders events; do
#     cqlsh $CASSANDRA_HOST -e "COPY $KEYSPACE.$TABLE TO '/tmp/${TABLE}.csv'"
#     cqlsh $HELIOSDB_HOST -e "COPY $KEYSPACE.$TABLE FROM '/tmp/${TABLE}.csv'"
# done

echo "Step 4: Validating data..."
./verify_data_consistency.sh

echo "Migration complete!"
```

---

## Step-by-Step Migration

### Step 1: Connection Setup

**Cassandra Connection**:
```bash
# Connect to Cassandra
cqlsh cassandra.example.com 9042 -u cassandra -p password
```

**HeliosDB Connection** (identical syntax):
```bash
# Connect to HeliosDB (same protocol!)
cqlsh heliosdb.example.com 9042 -u admin -p password
```

**Test Connectivity**:
```sql
-- On both Cassandra and HeliosDB
SELECT cluster_name, release_version FROM system.local;
```

**Python Client** (change the contact points):
```python
from cassandra.cluster import Cluster
from cassandra.auth import PlainTextAuthProvider

# Cassandra
auth_provider = PlainTextAuthProvider(username='cassandra', password='password')
cluster = Cluster(['cassandra.example.com'], port=9042, auth_provider=auth_provider)
cassandra_session = cluster.connect()

# HeliosDB (just change host!)
auth_provider = PlainTextAuthProvider(username='admin', password='password')
cluster = Cluster(['heliosdb.example.com'], port=9042, auth_provider=auth_provider)
heliosdb_session = cluster.connect()
```

---

### Step 2: Schema Migration

**Export Cassandra Schema**:
```bash
# Export all keyspaces
cqlsh cassandra.example.com -e "DESCRIBE KEYSPACES" > keyspaces.txt

# Export specific keyspace schema
cqlsh cassandra.example.com -e "DESCRIBE KEYSPACE my_keyspace" > my_keyspace_schema.cql
```

**Create Keyspace in HeliosDB** (identical syntax):
```sql
-- Example schema
CREATE KEYSPACE IF NOT EXISTS my_keyspace
WITH REPLICATION = {
    'class': 'SimpleStrategy',
    'replication_factor': 3
};

USE my_keyspace;

-- Create table
CREATE TABLE users (
    user_id UUID PRIMARY KEY,
    username TEXT,
    email TEXT,
    created_at TIMESTAMP,
    profile MAP<TEXT, TEXT>
);

-- Create table with clustering
CREATE TABLE user_events (
    user_id UUID,
    event_time TIMESTAMP,
    event_type TEXT,
    payload MAP<TEXT, TEXT>,
    PRIMARY KEY ((user_id), event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

-- Create secondary index
CREATE INDEX ON users (email);

-- Create user-defined type
CREATE TYPE address (
    street TEXT,
    city TEXT,
    zip_code TEXT
);

CREATE TABLE user_addresses (
    user_id UUID PRIMARY KEY,
    home_address FROZEN<address>,
    work_address FROZEN<address>
);
```

**Automated Schema Migration Script**:
```bash
#!/bin/bash
# migrate_schema.sh

CASSANDRA_HOST="cassandra.example.com"
HELIOSDB_HOST="heliosdb.example.com"

# Get list of non-system keyspaces
KEYSPACES=$(cqlsh $CASSANDRA_HOST -e "DESCRIBE KEYSPACES" | grep -v "system")

for KEYSPACE in $KEYSPACES; do
    echo "Migrating schema for keyspace: $KEYSPACE"

    # Export schema
    cqlsh $CASSANDRA_HOST -e "DESCRIBE KEYSPACE $KEYSPACE" > /tmp/${KEYSPACE}_schema.cql

    # Import to HeliosDB
    cqlsh $HELIOSDB_HOST -f /tmp/${KEYSPACE}_schema.cql

    echo "✓ $KEYSPACE schema migrated"
done

echo "Schema migration complete!"
```

---

### Step 3: Data Migration

#### Option A: COPY Command (Small to Medium Datasets <100 GB)

**Export**:
```bash
# Export table to CSV
cqlsh cassandra.example.com -e "
COPY my_keyspace.users TO '/tmp/users.csv'
WITH HEADER = TRUE;
"
```

**Import**:
```bash
# Import CSV to HeliosDB
cqlsh heliosdb.example.com -e "
COPY my_keyspace.users FROM '/tmp/users.csv'
WITH HEADER = TRUE;
"
```

**Automated COPY Script**:
```bash
#!/bin/bash
# migrate_data_copy.sh

CASSANDRA_HOST="cassandra.example.com"
HELIOSDB_HOST="heliosdb.example.com"
KEYSPACE="my_keyspace"
TABLES=("users" "orders" "events" "user_events")

for TABLE in "${TABLES[@]}"; do
    echo "Migrating $KEYSPACE.$TABLE..."

    # Export
    cqlsh $CASSANDRA_HOST -e "
        COPY $KEYSPACE.$TABLE TO '/tmp/${TABLE}.csv'
        WITH HEADER = TRUE AND PAGETIMEOUT = 60;
    "

    # Import
    cqlsh $HELIOSDB_HOST -e "
        COPY $KEYSPACE.$TABLE FROM '/tmp/${TABLE}.csv'
        WITH HEADER = TRUE AND CHUNKSIZE = 5000;
    "

    # Verify count
    CASSANDRA_COUNT=$(cqlsh $CASSANDRA_HOST -e "SELECT COUNT(*) FROM $KEYSPACE.$TABLE" | grep -Eo '[0-9]+')
    HELIOSDB_COUNT=$(cqlsh $HELIOSDB_HOST -e "SELECT COUNT(*) FROM $KEYSPACE.$TABLE" | grep -Eo '[0-9]+')

    if [ "$CASSANDRA_COUNT" == "$HELIOSDB_COUNT" ]; then
        echo "✓ $TABLE migrated successfully ($CASSANDRA_COUNT rows)"
    else
        echo "✗ $TABLE row count mismatch (C: $CASSANDRA_COUNT, H: $HELIOSDB_COUNT)"
        exit 1
    fi
done

echo "Data migration complete!"
```

#### Option B: sstableloader (Large Datasets >100 GB)

**Export SSTables**:
```bash
# Take snapshot
nodetool snapshot my_keyspace -t migration_snapshot

# Find snapshot directory
find /var/lib/cassandra/data/my_keyspace -name migration_snapshot
```

**Load to HeliosDB**:
```bash
# Load SSTables
sstableloader -d heliosdb.example.com \
              -u admin \
              -pw password \
              /var/lib/cassandra/data/my_keyspace/users-abc123/snapshots/migration_snapshot
```

#### Option C: Spark Bulk Load (Very Large Datasets >1 TB)

**Spark Migration Job**:
```scala
import org.apache.spark.sql.SparkSession
import com.datastax.spark.connector._

val spark = SparkSession.builder()
  .appName("Cassandra to HeliosDB Migration")
  .config("spark.cassandra.connection.host", "cassandra.example.com")
  .config("spark.cassandra.auth.username", "cassandra")
  .config("spark.cassandra.auth.password", "password")
  .getOrCreate()

// Read from Cassandra
val cassandraDF = spark.read
  .format("org.apache.spark.sql.cassandra")
  .options(Map("keyspace" -> "my_keyspace", "table" -> "users"))
  .load()

// Write to HeliosDB
cassandraDF.write
  .format("org.apache.spark.sql.cassandra")
  .options(Map(
    "keyspace" -> "my_keyspace",
    "table" -> "users",
    "spark.cassandra.connection.host" -> "heliosdb.example.com",
    "spark.cassandra.auth.username" -> "admin",
    "spark.cassandra.auth.password" -> "password"
  ))
  .mode("append")
  .save()
```

---

### Step 4: Application Migration

**Start with the connection configuration.** Applications connect by changing the contact points once the contact points target HeliosDB; run your test suite and check the [compatibility notes](#compatibility-notes).

**Before (Cassandra)**:
```python
from cassandra.cluster import Cluster
from cassandra.auth import PlainTextAuthProvider

auth = PlainTextAuthProvider(username='cassandra', password='password')
cluster = Cluster(['cassandra.example.com'], port=9042, auth_provider=auth)
session = cluster.connect('my_keyspace')

# All CQL queries work identically
rows = session.execute("SELECT * FROM users WHERE user_id = ?", [user_id])
for row in rows:
    print(row.username, row.email)
```

**After (HeliosDB)** - Only hostname changes:
```python
from cassandra.cluster import Cluster
from cassandra.auth import PlainTextAuthProvider

auth = PlainTextAuthProvider(username='admin', password='password')
cluster = Cluster(['heliosdb.example.com'], port=9042, auth_provider=auth)  # ← Only change
session = cluster.connect('my_keyspace')

# Same queries, no changes!
rows = session.execute("SELECT * FROM users WHERE user_id = ?", [user_id])
for row in rows:
    print(row.username, row.email)
```

**Configuration-Based Connection** (best practice):
```python
# config.py
import os

CASSANDRA_HOST = os.environ.get('CASSANDRA_HOST', 'cassandra.example.com')
CASSANDRA_PORT = int(os.environ.get('CASSANDRA_PORT', '9042'))
CASSANDRA_USERNAME = os.environ.get('CASSANDRA_USERNAME', 'cassandra')
CASSANDRA_PASSWORD = os.environ.get('CASSANDRA_PASSWORD')

# app.py
from cassandra.cluster import Cluster
from cassandra.auth import PlainTextAuthProvider
import config

auth = PlainTextAuthProvider(username=config.CASSANDRA_USERNAME, password=config.CASSANDRA_PASSWORD)
cluster = Cluster([config.CASSANDRA_HOST], port=config.CASSANDRA_PORT, auth_provider=auth)
session = cluster.connect('my_keyspace')
```

**Update Environment Variables**:
```bash
# For Cassandra
export CASSANDRA_HOST=cassandra.example.com

# For HeliosDB (only change this!)
export CASSANDRA_HOST=heliosdb.example.com
```

**Spring Boot Configuration**:
```yaml
# application.yml
spring:
  data:
    cassandra:
      contact-points: ${CASSANDRA_HOST:cassandra.example.com}
      port: 9042
      keyspace-name: my_keyspace
      username: ${CASSANDRA_USERNAME}
      password: ${CASSANDRA_PASSWORD}
      local-datacenter: datacenter1
```

---

### Step 5: Validation

**Row Count Validation**:
```sql
-- Run on both Cassandra and HeliosDB
SELECT COUNT(*) FROM my_keyspace.users;
SELECT COUNT(*) FROM my_keyspace.orders;
SELECT COUNT(*) FROM my_keyspace.events;
```

**Sample Data Comparison**:
```sql
-- Compare first 100 rows (sorted by primary key)
SELECT * FROM users LIMIT 100;
```

**Automated Validation Script**:
```python
# validate_migration.py
from cassandra.cluster import Cluster
from cassandra.auth import PlainTextAuthProvider

# Connect to both
cassandra_cluster = Cluster(['cassandra.example.com'], port=9042,
                           auth_provider=PlainTextAuthProvider('cassandra', 'password'))
heliosdb_cluster = Cluster(['heliosdb.example.com'], port=9042,
                          auth_provider=PlainTextAuthProvider('admin', 'password'))

cassandra_session = cassandra_cluster.connect('my_keyspace')
heliosdb_session = heliosdb_cluster.connect('my_keyspace')

# Tables to validate
tables = ['users', 'orders', 'events']

validation_results = []

for table in tables:
    # Count validation
    cass_count = cassandra_session.execute(f"SELECT COUNT(*) FROM {table}").one()[0]
    helios_count = heliosdb_session.execute(f"SELECT COUNT(*) FROM {table}").one()[0]

    count_match = cass_count == helios_count

    # Sample validation (first 1000 rows)
    cass_sample = list(cassandra_session.execute(f"SELECT * FROM {table} LIMIT 1000"))
    helios_sample = list(heliosdb_session.execute(f"SELECT * FROM {table} LIMIT 1000"))

    sample_match = cass_sample == helios_sample

    validation_results.append({
        'table': table,
        'cassandra_count': cass_count,
        'heliosdb_count': helios_count,
        'count_match': count_match,
        'sample_match': sample_match,
        'status': 'PASS' if count_match and sample_match else 'FAIL'
    })

# Print results
for result in validation_results:
    status_icon = '✓' if result['status'] == 'PASS' else '✗'
    print(f"{status_icon} {result['table']}: {result['cassandra_count']} rows (match: {result['count_match']}, sample: {result['sample_match']})")

# Exit with error if any failures
if any(r['status'] == 'FAIL' for r in validation_results):
    print("\n✗ Validation FAILED")
    exit(1)
else:
    print("\n✓ Validation PASSED")
```

**Checksum Validation** (for critical data):
```python
import hashlib

def compute_table_checksum(session, table, sample_size=10000):
    """Compute checksum of table data"""
    rows = session.execute(f"SELECT * FROM {table} LIMIT {sample_size}")

    # Sort rows by primary key for deterministic order
    sorted_rows = sorted(rows, key=lambda r: str(r))

    # Compute checksum
    hasher = hashlib.sha256()
    for row in sorted_rows:
        hasher.update(str(row).encode())

    return hasher.hexdigest()

# Compare checksums
for table in tables:
    cass_checksum = compute_table_checksum(cassandra_session, table)
    helios_checksum = compute_table_checksum(heliosdb_session, table)

    if cass_checksum == helios_checksum:
        print(f"✓ {table} checksum match: {cass_checksum[:8]}...")
    else:
        print(f"✗ {table} checksum MISMATCH")
        print(f"  Cassandra: {cass_checksum}")
        print(f"  HeliosDB:  {helios_checksum}")
```

---

### Step 6: Performance Tuning

**Connection Pooling**:
```python
from cassandra.cluster import Cluster, ExecutionProfile, EXEC_PROFILE_DEFAULT
from cassandra.policies import DCAwareRoundRobinPolicy, TokenAwarePolicy

# Optimized connection profile
profile = ExecutionProfile(
    load_balancing_policy=TokenAwarePolicy(DCAwareRoundRobinPolicy()),
    request_timeout=15.0,
    consistency_level=ConsistencyLevel.LOCAL_QUORUM
)

cluster = Cluster(
    ['heliosdb.example.com'],
    port=9042,
    execution_profiles={EXEC_PROFILE_DEFAULT: profile},
    protocol_version=5,  # Use latest protocol
    compression=True,     # Enable compression
    max_schema_agreement_wait=10
)
```

**Consistency Level Adjustment**:
```sql
-- Use local consistency levels for lower latency
-- (especially important for multi-region deployments)

-- Before (Cassandra)
SELECT * FROM users WHERE user_id = ? USING CONSISTENCY QUORUM;

-- After (HeliosDB - optimized)
SELECT * FROM users WHERE user_id = ? USING CONSISTENCY LOCAL_QUORUM;
```

**Prepared Statement Caching**:
```python
# Cache prepared statements for better performance
prepared_statements = {}

def get_prepared_statement(session, query):
    if query not in prepared_statements:
        prepared_statements[query] = session.prepare(query)
    return prepared_statements[query]

# Usage
stmt = get_prepared_statement(session, "SELECT * FROM users WHERE user_id = ?")
rows = session.execute(stmt, [user_id])
```

**Query Optimization**:
```sql
-- Before: Secondary index scan (slow)
SELECT * FROM orders WHERE customer_email = 'alice@example.com';

-- After: Partition key lookup (fast)
-- Option 1: Add materialized view (parser only; execution not yet supported)
CREATE MATERIALIZED VIEW orders_by_email AS
    SELECT * FROM orders
    WHERE customer_email IS NOT NULL AND order_id IS NOT NULL
    PRIMARY KEY (customer_email, order_id);

SELECT * FROM orders_by_email WHERE customer_email = 'alice@example.com';

-- Option 2: Use HeliosDB SQL interface for complex queries
SELECT * FROM orders WHERE customer_email = 'alice@example.com'
ALLOW FILTERING;  -- Faster in HeliosDB due to query optimizer
```

**Index Creation**:
```sql
-- Create secondary indexes for common queries
CREATE INDEX ON users (email);
CREATE INDEX ON orders (status);
CREATE INDEX ON events (event_type);

-- Check index usage
SELECT * FROM system_schema.indexes WHERE keyspace_name = 'my_keyspace';
```

---

## Feature Mapping

### Data Types

| Cassandra Type | HeliosDB Storage | Notes |
|----------------|------------------|-------|
| ASCII | TEXT | Identical |
| BIGINT | BIGINT | Identical |
| BLOB | BYTEA | Binary data |
| BOOLEAN | BOOLEAN | Identical |
| COUNTER | BIGINT | Special handling for increments |
| DATE | INTEGER | Days since epoch |
| DECIMAL | DECIMAL | Arbitrary precision |
| DOUBLE | DOUBLE PRECISION | 64-bit float |
| DURATION | INTERVAL | Time duration |
| FLOAT | REAL | 32-bit float |
| INET | INET | IP address |
| INT | INTEGER | 32-bit int |
| LIST<T> | JSONB | Stored as JSON array |
| MAP<K,V> | JSONB | Stored as JSON object |
| SET<T> | JSONB | Stored as JSON array (unique) |
| SMALLINT | SMALLINT | 16-bit int |
| TEXT | TEXT | UTF-8 string |
| TIME | TIME | Nanoseconds since midnight |
| TIMESTAMP | BIGINT | Milliseconds since epoch |
| TIMEUUID | UUID | Version 1 UUID |
| TINYINT | SMALLINT | 8-bit int → 16-bit |
| TUPLE | JSONB | Stored as JSON array |
| UUID | UUID | Version 4 UUID |
| UDT | JSONB | User-defined type as JSON |
| VARCHAR | TEXT | Alias for TEXT |
| VARINT | NUMERIC | Arbitrary precision integer |

### CQL Features

| Feature | Cassandra | HeliosDB | Compatibility |
|---------|-----------|----------|---------------|
| **Queries** |
| SELECT | | | 100% |
| INSERT | | | 100% |
| UPDATE | | | 100% |
| DELETE | | | 100% |
| BEGIN BATCH | | | 100% |
| **Clauses** |
| WHERE | | | 100% |
| ORDER BY | | | 100% (clustering only) |
| LIMIT | | | 100% |
| ALLOW FILTERING | | | 100% (faster in HeliosDB) |
| IF EXISTS / IF NOT EXISTS | | | 100% |
| IF <condition> | | Partial | 80% (basic LWT only) |
| USING TTL | | | 100% |
| USING TIMESTAMP | | | 100% |
| **Functions** |
| uuid() | | | 100% |
| now() | | | 100% |
| toTimestamp() | | | 100% |
| dateOf() | | | 100% |
| token() | | | 100% |
| ttl() | | | 100% |
| writetime() | | | 100% |
| COUNT(*) | | | 100% |
| SUM/AVG/MIN/MAX | | | 100% |
| **Advanced** |
| Prepared Statements | | | 100% |
| Paging | | | 100% |
| LOGGED BATCH | | | 100% |
| UNLOGGED BATCH | | | 100% |
| COUNTER BATCH | | | 100% |
| Static Columns | | | 100% |
| Frozen Collections | | | 100% |
| Materialized Views | | Partial | 50% (parser only) |
| Secondary Indexes | | | 100% |
| UDFs | | No | 0% |
| UDAs | | No | 0% |
| Triggers | | No | 0% (not planned) |

---

## Troubleshooting

### Common Issues

#### 1. Consistency Level Errors

**Problem**: `UnavailableException: Cannot achieve consistency level QUORUM`

**Cause**: Not enough replicas available

**Solution**:
```sql
-- Use LOCAL_ONE or LOCAL_QUORUM instead
SELECT * FROM users WHERE user_id = ? USING CONSISTENCY LOCAL_ONE;
```

**Configuration**:
```python
from cassandra.cluster import Cluster, ConsistencyLevel

cluster = Cluster(['heliosdb.example.com'])
session = cluster.connect()
session.default_consistency_level = ConsistencyLevel.LOCAL_QUORUM  # Set default
```

---

#### 2. Authentication Failures

**Problem**: `AuthenticationException: Username and/or password are incorrect`

**Cause**: PasswordAuthenticator mismatch

**Solution**:
```bash
# Check HeliosDB authentication configuration
heliosdb config get auth.authenticator

# Should output: PasswordAuthenticator

# Reset admin password
heliosdb user reset-password admin
```

**Application Fix**:
```python
from cassandra.auth import PlainTextAuthProvider

# Ensure correct username/password
auth = PlainTextAuthProvider(username='admin', password='correct_password')
cluster = Cluster(['heliosdb.example.com'], auth_provider=auth)
```

---

#### 3. Performance Degradation

**Problem**: Queries slower in HeliosDB than Cassandra

**Diagnosis**:
```sql
-- Check query plan
EXPLAIN SELECT * FROM users WHERE email = 'alice@example.com';
```

**Solution 1: Missing Indexes**
```sql
-- Create secondary index
CREATE INDEX ON users (email);
```

**Solution 2: Optimize Consistency Level**
```python
# Use lower consistency for read-heavy workloads
session.default_consistency_level = ConsistencyLevel.LOCAL_ONE
```

**Solution 3: Enable Query Cache**
```sql
-- Enable intelligent caching (HeliosDB feature)
ALTER SYSTEM SET intelligent_cache = 'on';
ALTER SYSTEM SET cache_policy = 'ml_hybrid';
```

---

#### 4. Data Type Mismatch

**Problem**: Collection data not readable after migration

**Cause**: Frozen vs. non-frozen collections

**Solution**:
```sql
-- Check table schema
DESC TABLE my_keyspace.users;

-- If collections are frozen, they're immutable
-- Recreate table with non-frozen collections if needed
CREATE TABLE users_v2 (
    user_id UUID PRIMARY KEY,
    tags SET<TEXT>,  -- Non-frozen (mutable)
    metadata MAP<TEXT, TEXT>  -- Non-frozen (mutable)
);
```

---

#### 5. Timeout Errors

**Problem**: `OperationTimedOut: Operation timed out - received only 0 responses`

**Cause**: Network latency, overloaded cluster, or large result set

**Solution**:
```python
# Increase timeout
from cassandra.cluster import Cluster, ExecutionProfile

profile = ExecutionProfile(
    request_timeout=30.0  # Increase from default 10s
)

cluster = Cluster(['heliosdb.example.com'],
                 execution_profiles={EXEC_PROFILE_DEFAULT: profile})
```

**For Large Queries**:
```python
# Use paging for large result sets
from cassandra.query import SimpleStatement

stmt = SimpleStatement("SELECT * FROM large_table", fetch_size=1000)
for row in session.execute(stmt):
    process(row)
```

---

#### 6. Connection Pool Exhausted

**Problem**: `NoHostAvailable: Unable to complete the operation against any hosts`

**Cause**: Too many concurrent connections

**Solution**:
```python
# Increase connection pool size
from cassandra.cluster import Cluster

cluster = Cluster(
    ['heliosdb.example.com'],
    protocol_version=5,
    executor_threads=4,  # Increase thread pool
    max_schema_agreement_wait=10,
    control_connection_timeout=10,
    idle_heartbeat_interval=30,
    compression=True
)
```

---

## Best Practices

### 1. Start with Non-Production Environments

**Recommended Progression**:
1. **Development** (1-2 days): Test basic functionality
2. **Staging** (1 week): Full integration testing
3. **Canary Production** (1 week): 10% traffic to HeliosDB
4. **Production Rollout** (2 weeks): Gradual 10% → 25% → 50% → 100%

---

### 2. Use Dual-Write for Critical Systems

**Advantages**:
- Zero downtime
- Easy rollback
- Gradual confidence building

**Implementation**: See [Strategy 1: Dual-Write](#strategy-1-dual-write-zero-downtime--recommended-for-production)

---

### 3. Monitor Replication Lag During Migration

**Key Metrics**:
- Replication lag (target: <1 second)
- Write throughput (both clusters)
- Read latency (both clusters)
- Error rates

**Monitoring Script**:
```bash
#!/bin/bash
# monitor_migration.sh

while true; do
    # Check replication lag
    LAG=$(curl -s http://debezium:8083/connectors/cassandra-heliosdb/status | jq '.lag_seconds')

    # Check write throughput
    CASSANDRA_WRITES=$(nodetool tpstats | grep 'MutationStage' | awk '{print $5}')
    HELIOSDB_WRITES=$(heliosdb stats writes)

    # Print dashboard
    clear
    echo "=== Migration Monitor ==="
    echo "Replication Lag: ${LAG}s"
    echo "Cassandra Writes: ${CASSANDRA_WRITES}/s"
    echo "HeliosDB Writes: ${HELIOSDB_WRITES}/s"
    echo "========================"

    sleep 5
done
```

---

### 4. Keep Cassandra as Fallback Initially

**Recommendation**: Keep Cassandra cluster running for 1-2 weeks after cutover

**Rollback Preparation**:
```bash
# Keep Cassandra config readily available
export CASSANDRA_HOST_PRIMARY=heliosdb.example.com
export CASSANDRA_HOST_FALLBACK=cassandra.example.com

# Quick rollback script
cat > rollback.sh <<'EOF'
#!/bin/bash
kubectl set env deployment/my-app CASSANDRA_HOST=$CASSANDRA_HOST_FALLBACK
kubectl rollout restart deployment/my-app
EOF
chmod +x rollback.sh
```

---

### 5. Test Rollback Procedure

**Before Cutover**:
```bash
# Test rollback in staging
1. Switch to HeliosDB
2. Verify application works
3. Execute rollback script
4. Verify application still works with Cassandra
```

---

### 6. Document Your Migration

**Migration Runbook Template**:
```markdown
# Migration Runbook: Cassandra → HeliosDB

## Pre-Migration Checklist
- [ ] HeliosDB cluster provisioned and tested
- [ ] Schema migrated and validated
- [ ] Data migration method selected
- [ ] Rollback procedure tested
- [ ] Monitoring dashboards configured
- [ ] On-call team notified

## Migration Steps
1. [ ] Enable dual-write (or start replication)
2. [ ] Begin data backfill
3. [ ] Validate data consistency
4. [ ] Route 10% read traffic to HeliosDB
5. [ ] Monitor for 24 hours
6. [ ] Route 50% read traffic to HeliosDB
7. [ ] Monitor for 24 hours
8. [ ] Route 100% traffic to HeliosDB
9. [ ] Monitor for 1 week
10. [ ] Decommission Cassandra

## Rollback Procedure
1. Execute: ./rollback.sh
2. Verify traffic routing to Cassandra
3. Monitor error rates
4. Investigate HeliosDB issue

## Success Criteria
- Row counts match (100%)
- Query latency < baseline + 10%
- Error rate < 0.01%
- No data loss
```

---

## Rollback Plan

### Scenario 1: Issues During Dual-Write Phase

**Symptoms**: Data inconsistency, high error rates

**Action**:
```bash
# 1. Stop dual-write
# Comment out dual-write code or set environment variable
export ENABLE_DUAL_WRITE=false

# 2. Restart application
kubectl rollout restart deployment/my-app

# 3. Continue writing to Cassandra only
# 4. Investigate HeliosDB issues
heliosdb logs --tail 1000 | grep ERROR

# 5. Retry after fixes
```

**Impact**: No downtime (still using Cassandra)

---

### Scenario 2: Issues After Partial Cutover

**Symptoms**: Performance degradation, query errors

**Action**:
```bash
# 1. Immediately route all traffic back to Cassandra
kubectl set env deployment/my-app CASSANDRA_HOST=cassandra.example.com
kubectl rollout restart deployment/my-app

# 2. Verify application health
kubectl logs -f deployment/my-app

# 3. Analyze HeliosDB issues
heliosdb diagnose --export /tmp/diagnostics.tar.gz

# 4. Contact support if needed
```

**Impact**: Brief downtime during restart (2-5 minutes)

---

### Scenario 3: Data Loss Detected

**Symptoms**: Row count mismatch, missing records

**Action**:
```bash
# 1. IMMEDIATE ROLLBACK
./rollback.sh

# 2. Stop all writes to HeliosDB
heliosdb cluster pause --writes-only

# 3. Export HeliosDB data for forensics
cqlsh heliosdb.example.com -e "COPY my_keyspace.users TO '/tmp/heliosdb_users.csv'"

# 4. Compare with Cassandra
diff <(wc -l /tmp/cassandra_users.csv) <(wc -l /tmp/heliosdb_users.csv)

# 5. Re-run migration with identified fixes
```

**Impact**: Rollback to Cassandra (5-10 minutes downtime)

---

## Case Studies

### Case Study 1: E-Commerce Platform (500M Daily Writes)

**Customer**: Large e-commerce company

**Cassandra Setup**:
- 30-node cluster
- 100 TB data
- 500M writes/day
- 2B reads/day

**Migration Strategy**: Dual-write

**Timeline**:
- Week 1: Schema migration, initial backfill
- Week 2: Dual-write enabled, 10% read traffic
- Week 3: 50% read traffic
- Week 4: 100% read traffic, write migration
- Week 5: Cassandra decommissioned

**Results**:
- Zero downtime
- 2.5x faster analytics queries
- No data loss

**Key Success Factors**:
- Comprehensive monitoring
- Gradual rollout
- 24/7 on-call support during migration

---

### Case Study 2: IoT Sensor Network (10K Devices)

**Customer**: Industrial IoT platform

**Cassandra Setup**:
- 6-node cluster
- 20 TB time-series data
- 10K devices × 1 msg/sec = 10K writes/sec

**Migration Strategy**: Replication-based

**Timeline**:
- Day 1: Schema migration
- Day 2-3: Initial data replication (20 TB)
- Day 4: Replication caught up (lag < 1s)
- Day 5: Cutover (3-minute downtime)
- Day 6-12: Monitoring

**Results**:
- 3-minute downtime
- 10x faster downsampling queries
- Successful migration

**Key Success Factors**:
- Low downtime tolerance (not 24/7 critical)
- Time-series data (less complex than transactional)
- HeliosDB edge sync for IoT devices

---

### Case Study 3: SaaS Multi-Tenant Application

**Customer**: B2B SaaS provider (5000 tenants)

**Cassandra Setup**:
- 12-node cluster
- 50 TB data
- Multi-tenant (5000 tenants)

**Migration Strategy**: Tenant-by-tenant migration

**Timeline**:
- Week 1-2: Migrate 10 test tenants
- Week 3-4: Migrate 100 small tenants
- Week 5-6: Migrate 500 medium tenants
- Week 7-10: Migrate 4390 remaining tenants

**Results**:
- Zero downtime (per-tenant migration)
- Multi-protocol access (CQL + SQL)
- Tenant isolation improved

**Key Success Factors**:
- Tenant-by-tenant rollout reduced risk
- Automated migration tooling
- HeliosDB multi-tenancy features

---

## Next Steps

### 1. Join HeliosDB Community

**Resources**:
- Documentation: https://www.heliosdb.com/docs/full/
- Support: [support@heliosdb.com](mailto:support@heliosdb.com)

---

### 2. Schedule Migration Planning Call

**Contact**: support@heliosdb.com

**Topics**:
- Migration strategy selection
- Timeline estimation
- Resource requirements
- Risk assessment

---

### 3. Access Enterprise Features

**Enterprise Add-Ons**:
- 24/7 migration support
- Dedicated migration engineer
- Advanced monitoring and alerting
- Custom tooling development
- SLA guarantees

**Contact Sales**: sales@heliosdb.com

---

### 4. Training and Certification

**HeliosDB Academy**:
- Cassandra to HeliosDB Migration (4-hour course)
- HeliosDB Administration (8-hour course)
- Multi-Protocol Database Design (4-hour course)

**Enquiries**: [sales@heliosdb.com](mailto:sales@heliosdb.com)

---

## Appendix A: Glossary

| Term | Definition |
|------|------------|
| **CQL** | Cassandra Query Language |
| **Keyspace** | Top-level data container (similar to database) |
| **Partition Key** | Column(s) determining data distribution across nodes |
| **Clustering Key** | Column(s) determining sort order within partition |
| **Consistency Level** | How many replicas must respond to a query (ONE, QUORUM, ALL) |
| **LWT** | Lightweight Transactions (compare-and-set operations) |
| **UDT** | User-Defined Type (custom data type) |
| **TTL** | Time-to-Live (automatic data expiration) |
| **SSTable** | Sorted String Table (Cassandra's on-disk format) |
| **Compaction** | Background process to merge SSTables |

---

## Appendix B: Client Driver Compatibility

| Driver | Version | Notes |
|--------|---------|------------------------|
| **DataStax Python Driver** | 3.25+ | Native protocol v4/v5; validate with your workload |
| **DataStax Java Driver** | 4.15+ | Native protocol v4/v5; validate with your workload |
| **DataStax C++ Driver** | 2.16+ | Native protocol v4/v5; validate with your workload |
| **DataStax Node.js Driver** | 4.6+ | Native protocol v4/v5; validate with your workload |
| **DataStax C# Driver** | 3.18+ | Native protocol v4/v5; validate with your workload |
| **GoCQL** | 1.0+ | Native protocol v4/v5; validate with your workload |
| **Rust Driver (Scylla)** | 0.9+ | Native protocol v4/v5; validate with your workload |
| **cqlsh** | 5.0.1+ | Native protocol v4/v5; validate with your workload |

---

## Appendix C: HeliosDB-Specific Enhancements

### 1. SQL Interface on CQL Data

```sql
-- Query Cassandra data with SQL
SELECT u.username, COUNT(o.order_id) AS order_count
FROM my_keyspace.users u
LEFT JOIN my_keyspace.orders o ON u.user_id = o.user_id
GROUP BY u.username
HAVING COUNT(o.order_id) > 10
ORDER BY order_count DESC;
```

### 2. Intelligent Query Caching

```sql
-- Enable ML-based query caching (HeliosDB feature)
ALTER SYSTEM SET intelligent_cache = 'on';

-- Cached queries are automatically faster on subsequent runs
SELECT * FROM large_table WHERE status = 'active';  -- 500ms (first run)
SELECT * FROM large_table WHERE status = 'active';  -- 2ms (cached)
```

### 3. Multi-Protocol Access

```python
# Access same data via CQL and PostgreSQL protocols
from cassandra.cluster import Cluster
import psycopg2

# CQL protocol
cql_cluster = Cluster(['heliosdb.example.com'], port=9042)
cql_session = cql_cluster.connect('my_keyspace')
cql_session.execute("INSERT INTO users (user_id, name) VALUES (?, ?)", [uuid4(), 'Alice'])

# PostgreSQL protocol (same data!)
pg_conn = psycopg2.connect(host='heliosdb.example.com', port=5432, database='my_keyspace')
pg_cursor = pg_conn.cursor()
pg_cursor.execute("SELECT * FROM users WHERE name = %s", ['Alice'])
print(pg_cursor.fetchall())
```

---

## Document Information

**Version**: 1.0
**Maintainers**: HeliosDB Migration Team
**Feedback**: support@heliosdb.com

**Related Documentation**:
- [MongoDB Migration Guide](https://www.heliosdb.com/docs/full/reference/guides/mongodb_migration/)
- [Oracle Migration Guide](https://www.heliosdb.com/docs/full/reference/guides/oracle_migration/)