How to migrate data from bitnami ScyllaDB to scylla in Kubernetes?

ScyllaDB
, ,
1

Installation details
#ScyllaDB version: 6.2.0
#Cluster size: 3 nodes
os (RHEL/CentOS/Ubuntu/AWS AMI): Kubernetes

We had used bitnami ScyllaDB in a project. Now we want to use scylla-operator and Kubernetes.

How can we migrate data from bitnami ScyllaDB to our new cluster?

Regards

2

If you’re currently running Bitnami’s ScyllaDB Helm deployment and plan to migrate to an official Scylla cluster managed by Scylla Operator, the process is straightforward once you view Bitnami as simply “another ScyllaDB cluster.” The operator just changes how the nodes are managed — not the actual data format — so standard Scylla migration tools apply.

1. Understand the setup

Bitnami’s ScyllaDB chart wraps official Scylla images with its own init containers, config defaults, and host volume mounts. The Scylla Operator instead deploys native ScyllaCluster custom resources that manage lifecycle (scaling, rolling upgrades, etc.) automatically. Both store data in compatible SSTable formats, so direct data-level migration is possible.​

2. Preferred migration method: sstableloader

You can migrate from Bitnami to Operator-managed Scylla by exporting SSTables and streaming them into the new cluster:

  1. On each Bitnami Scylla node (Pod), take a snapshot of all keyspaces:

    nodetool snapshot

  2. Copy the snapshot data from /var/lib/scylla/data/ to an intermediate host or storage volume (or mount it via NFS).

  3. On a machine with scylla-tools-core installed (you can use a temporary pod for this in Kubernetes), run:

    sstableloader -d <comma_separated_new_cluster_ips> <path_to_snapshot>

    This will stream the SSTables into your new Scylla Operator cluster while preserving schema and data.​

  4. Verify data consistency with nodetool status and application-level checks.

This method works well for clusters of any size and is version-agnostic between 6.x-compatible builds.

3. Alternate approach: Scylla Manager Migrator

If you already use Scylla Manager, the scylla-manager-migrator tool can handle streaming between two live clusters (Bitnami and Operator-managed) automatically. It uses snapshots and repair-safe streaming internally.​

4. Configuration considerations

  • Ensure both clusters use the same replication settings before loading data.

  • Verify that endpoint_snitch, compaction_strategy, and keyspace definitions match.

  • Deploy the new cluster first via Helm + Scylla Operator chart per Scylla Operator docs before migrating.​

  • If using PersistentVolumeClaims, make sure the volume capacity is sufficient to hold both existing and incoming data.

5. Optional: Full export/import

For smaller datasets, you can use standard cqlsh export/import as a lightweight alternative:

cqlsh -e "DESCRIBE KEYSPACE your_keyspace" > schema.cql cqlsh -e "COPY your_table TO 'data.csv' WITH HEADER=TRUE;"

Then recreate schema and reimport on the new cluster:

cqlsh -f schema.cql COPY your_table FROM 'data.csv' WITH HEADER=TRUE;

This method is slower but simple for non-production migrations.

Summary

Bitnami ScyllaDB → Scylla Operator (Kubernetes) migration can be done cleanly with:

  • nodetool snapshot + sstableloader (recommended for production)

  • or scylla-manager-migrator (automated streaming)

  • or cqlsh COPY (for small dev/test datasets)

The key steps are:

  1. Take snapshots on Bitnami nodes

  2. Deploy new Scylla Operator cluster

  3. Stream data into the target cluster

Once complete, decommission the Bitnami deployment and update your application’s contact points.

cc @mflendrich & @Yehuda_Lebi who could provide any additional insights, if needed

1 Like
3

Thank you very much for the procedure. We will follow it and let you know the results.

Regards.

1 Like
4

its ineed helped thanks!!

1 Like