New ScyllaDB Enterprise Release: Up to 50% Higher Throughput, 33% Lower Latency

Performance improvements, encryption at rest, Repair Based Node Operations, consistent schema management using Raft & more 

ScyllaDB Enterprise 2024.1.0 LTS, a production-ready ScyllaDB Enterprise Long Term Support Major Release, is now available! It introduces significant performance improvements: up to 50% higher throughput, 35% greater efficiency, and 33% lower latency. It introduces encryption at rest, Repair Based Node Operations (RBNO) for all operations, and numerous improvements and bug fixes. Additionally, consistent schema management using Raft will be enabled automatically upon upgrade (see below for more details). The new release is based on ScyllaDB Open Source 5.4.

In this blog, we’ll highlight the new capabilities that our users have been asking about most frequently. For the complete details, read the release notes.

• Read the detailed release notes on our forum
• Learn more about ScyllaDB Enterprise
• Get ScyllaDB Enterprise 2024.1 (customers only, or 30-day evaluation)
• Upgrade from ScyllaDB Enterprise 2023.1.x to 2024.1.y
• Upgrade from ScyllaDB Enterprise 2022.2.x to 2024.1.y
• Upgrade from ScyllaDB Open Source 5.4 to ScyllaDB Enterprise 2024.1.x

ScyllaDB Enterprise customers are encouraged to upgrade to ScyllaDB Enterprise 2023.1, and are welcome to contact our Support Team with questions.

Read the detailed release notes

Performance Improvements

2024.1 includes many runtime and build performance improvements that translate to:

• Higher throughput per vCPU and server
• Lower mean and P99 latency

ScyllaDB 2024.1 vs ScyllaDB 2023.1

Throughput tests

2024.1 has up to 50% higher throughput than 2023.1. In some cases, this can translate to a 35% reduction in the number of vCPUs required to support a similar load. This enables a similar reduction in vCPU cost.

Latency tests

Latency tests were performed at 50% of the maximum throughput tested.
As demonstrated below, the latency (both mean and P99) is 33% lower, even with the higher throughput.

Test Setup

Amazon EC2
instance_type_db: i3.2xlarge (8 cores)
instance_type_loader: c4.2xlarge

Test profiles:
cassandra-stress [mixed|read|write] no-warmup cl=QUORUM duration=50m -schema ‘replication(factor=3)’ -mode cql3 native -rate threads=100 -pop ‘dist=gauss(1..30000000,15000000,1500000)’

Note that these results are for tests performed on a small i3 server (i3.2xlarge). ScyllaDB scales linearly with the number of cores and achieves much better results for the i4i instance type.

ScyllaDB Enterprise 2024.1 vs ScyllaDB Open Source 5.4

ScyllaDB Enterprise 2024.1 is based on ScyllaDB Open Source 5.4, but includes enterprise-only performance improvement optimizations. As shown below, the throughput gain is significant and latency is lower.

These tests use the same setup and parameters detailed above.

Encryption at Rest (EaR) Enhancements

This new release includes enhancements to Encryption at Rest (EaR), including new Amazon KMS integration, and extended cluster-level encryption at rest. Together, these improvements allow you to easily use your own key for cluster-wide EaR.

ScyllaDB Enterprise has supported Encryption at Rest (EaR) for some time. Until now, users could store the keys for EaR locally, in an encrypted table, or in an external KMIP server. This release adds the ability to:

• Use Amazon KMS to store and manage keys.
• Set default EaR parameters (including the new KMS) for *all* cluster tables.

These are both detailed below.

Amazon KMS Integration for Encryption at Rest

ScyllaDB can now use a Customer Managed Key (CMK), stored in KMS, to create, encrypt, and decrypt Data Keys (DEK), which are then used to encrypt and decrypt the data in storage (such as SSTables, Commit logs, Batches, and hints logs).

KMS creates DEK from CMK:

DEK (plain text version) is used to encrypt the data at rest:

Diagrams are from: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#data-keys

Before using KMS, you need to set KMS as a key provider and validate that ScyllaDB nodes have permission to access and use the CMK you created in KMS. Once you do that, you can use the CMK in the CREATE and ALTER TABLE commands with KmsKeyProviderFactory, as follows

CREATE TABLE myks.mytable (......) WITH
  scylla_encryption_options = {
  'cipher_algorithm' :  'AES/CBC/PKCS5Padding',
  'secret_key_strength' : 128,
  'key_provider': 'KmsKeyProviderFactory',
  'kms_host': 'my_endpoint'
}<>CODE>

Where “my_key” points to a section in scylla.yaml

kms_hosts:
  my_endpoint:
    aws_use_ec2_credentials: true
    aws_use_ec2_region: true
    master_key: alias/MyScyllaKey

You can also use the KMS provider to encrypt system-level data. See more examples and info here.

Transparent Data Encryption

Transparent Data Encryption (TDE) adds a way to define Encryption at Rest parameters per cluster, not only per table.
This allows the system administrator to enforce encryption of *all* tables using the same master key (e.g., from KMS) without specifying the encryption parameter per table. For example, with the following in scylla.yaml, all tables will be encrypted using encryption parameters of my-kms1:

user_info_encryption:
  enabled: true
  key_provider: KmsKeyProviderFactory,
  kms_host: my_kms1

See more examples and info here.

Repair Based Node Operations (RBNO)

RBNO provides a more robust, reliable, and safer data streaming for node operations like node-replace and node-add/remove. In particular, a failed node operation can resume from the point it stopped – without sending data that has already been synced. In addition, with RBNO enabled, you don’t need to repair before or after node operations, such as replace or removenode.

In this release, RBNO is enabled by default for all operations: remove node, rebuild, bootstrap, and decommission. The replace node operation was already enabled by default.

For details, see the Repair Based Node Operations (RBNO) docs and the blog, Faster, Safer Node Operations with Repair vs Streaming.

Node-Aggregated Table Level Metrics

Most ScyllaDB metrics are per-shard, per-node, but not for a specific table. We now export some per-table metrics. These are exported once per node, not per shard, to reduce the number of metrics.

Guardrails

Guardrails is a framework to protect ScyllaDB users and admins from common mistakes and pitfalls. In this release, ScyllaDB includes a new guardrail on the replication factor. It is now possible to specify the minimum replication factor for new keyspaces via a new configuration item.

Security

In addition to the EaR enhancements above, the following security features were introduced in 2024.1:

Encryption at transit, TLS certificates

It is now possible to use TLS certificates to authenticate and authorize a user to ScyllaDB. The system can be configured to derive the user role from the client certificate and derive the permissions the user has from that role. #10099
Learn more in the certificate-authentication docs.

FIPS Tolerant

ScyllaDB Enterprise can now run on FIPS enabled Ubuntu, using libraries that were compiled with FIPS enabled, such as OpenSSL, GnuTLS, and more.

Strongly Consistent Schema Management with Raft

Strongly Consistent Schema Management with Raft became the default for new clusters in ScyllaDB Enterprise 2023.1.In this release, it is enabled by default when upgrading existing clusters. Learn more in the blog, ScyllaDB’s Path to Strong Consistency: A New Milestone.

Read the detailed release notes