Open Telekom Cloud for Business Customers


GaussDB (for Cassandra) is a cloud-native NoSQL database compatible with Cassandra. It supports Cassandra Query Language (CQL), which gives you SQL-like syntax. GaussDB (for Cassandra) is secure, reliable, scalable, and easy to manage. GaussDB NoSQL provides outstanding read/write performance and supports Cassandra 3.11 DB engine.

A woman and a man in front of a screen, the woman points to a monitor

Reasons for GaussDB NoSQL in the Open Telekom Cloud

Blue shield in front of gray server icon.

High security and reliability

A multi-layer security system, including VPC, subnet, security group, SSL, and fine-grained permission control ensures database security and user privacy.
You can deploy an instance across three Availability Zones (AZs) and quickly back up or restore data to improve data reliability.
The distributed architecture provides superlative fault tolerance (N-1 reliability).

Icon with diagram and speedometer

Outstanding read/write performance

GaussDB (for Cassandra) gives you 3 times the performance of the open-source version. Data can be written to this high availability database 24/7, and with automated load balancing and elastic scaling you always have all the performance you need.

Icon with gear and arrows in each direction

Flexible scaling

Decoupled compute and storage allow you to add compute nodes in minutes and scale up storage capacity in seconds without service interruptions.
The compute clusters consist of multiple homogeneous nodes, and data is stored in a distributed, shared storage pool. Compute and storage resources are decoupled from each other so they can be flexibly scaled in or out without having to migrate any data.


GaussDB NoSQL is a distributed database with decoupled storage and compute architecture. One compute cluster may consist of multiple homogeneous nodes, and data is stored in a distributed, shared storage pool. It allows you to scale compute and storage resources flexibly without having to migrate any data.

Graphic Architecture GaussDB NoSQL

Key Features of GaussDB NoSQL

Hands on a keyboard symbolizing the data backup.

Data backup

Backups are stored in Object Storage Service (OBS) buckets, which provides disaster recovery capabilities and save space. When you create a DB instance, the automated backup policy is enabled by default. After the creation is complete, an automated full backup is triggered instantly. The backup retention period is 7 days by default. You can set the backup retention period and modify the backup policy. In addition, you can initiate backup at any time according to your service requirements. Manual backups are saved until you manually delete them.

Icon Network

Network isolation

GaussDB NoSQL uses Virtual Private Clouds (VPCs) and network security groups to keep DB instances isolated. VPCs allow you to define which IP addresses are allowed to access a given database. Running a DB instance in a VPC improves security. To further enhance database security, you can configure subnets and security groups to control access to DB instances.

Icon with lock

Access control

VPC security groups can be configured with rules to control traffic to and from DB instances.

Icon with key


GaussDB NoSQL uses Secure Sockets Layer (SSL) to encrypt transmitted data. You can download the root CA certificate from the management console and upload it for authentication when connecting to a database.

Icon with gear

Security system

GaussDB NoSQL supports multi-layer network protection. The security system consists of VPCs, subnets, security groups, Anti-DDoS, and SSL, which collectively can defend against a wide range of attacks and keep your data secure.

  • VPCs isolate resources and control access.
  • SSL connections ensure data security and integrity.
  • Security group rules control traffic to and from specific IP addresses and ports, protecting connections between GaussDB NoSQL and other services.
Icon diagram

Performance monitoring

GaussDB NoSQL monitors instance performance, reducing 60% of O&M activities. It provides real-time monitoring information about CPU utilization, disk usage, IOPS, and number of active connections, allowing you to check instance status at any time.

icon with a hook

Immediately ready for use

You can create a DB instance on the management console and access the database using private network IP addresses to reduce latency and avoid the cost of using a public network.


Gauss DB (for Cassandra) instance specifications



Memory (GB)

Max. storage space (GB)






















Compatible APIs and versions

Compatible API

Instance type






Related Services

Elastic Cloud Server (ECS)

Object Storage Service (OBS)

Virtual Private Cloud (VPC)

Cloud Eye


Application Scenarios


Industrial data collection



Performance ratio of GaussDB (for Cassandra) to open-source Cassandra (ECS with Data disk type: Ultra-high I/O)

Selected Hardware (flavors)

Concurrent client threads

Data used

95% read and 5% update

50% read and 50% update

65% read, 25% update and 10% insert

90% insert and 10% read

8 vCPUs 32 GB


100 GB





16 vCPUs 64 GB


200 GB





32 vCPUs 128 GB


400 GB






Test Conclusion

The GaussDB (for Cassandra) performs ten times better than the open-source Cassandra cluster in read latency.

The GaussDB (for Cassandra) cluster gives you nearly identical write performance as the open-source cluster.

Adding nodes slightly affects both the GaussDB (for Cassandra) and open-source clusters. 

  • The scale-out process of GaussDB (for Cassandra) is fast and affects services for a short period of time (10s). You do not need to change parameters, and the scale-out process lasts for 10 minutes.
  • For an open-source Cassandra cluster, the duration for adding nodes depends on the data volume and parameter settings, and the impact on performance varies. In a test scenario, the scaling took more than 30 minutes when the preset data size is 50 GB.

Best practices to choose the best flavor

  • In a multiple-node instance with 4 vCPUs per node there should be no more than 250 GB on each node, and the transactions per second (TPS) on each node are limited to 1000.
  • In a multiple-node instance with 8 vCPUs per node there should be no more than 250 GB on each node, and the transactions per second (TPS) on each node are limited to 2500.
  • In a multiple-node instance with 16 vCPUs per node there should be no more than 500 GB on each node, and the transactions per second (TPS) on each node are limited to 5000.
  • In a multiple-node instance with 32 vCPUs per node there should be no more than 500 GB on each node, and the transactions per second (TPS) on each node are limited to 10000.


Best Practice: Design Rules



Best Practices: Design Suggestions


Neue Features

New GaussDB (for Cassandra) Service is now available in EU-DE regionView Details

Find out more


  • Communities

    The Open Telekom Cloud Community

    This is where users, developers and product owners meet to help each other, share knowledge and discuss.

    Discover now

  • Telefon

    Free expert hotline

    Our certified cloud experts provide you with personal service free of charge.

     0800 3304477 (from Germany)

    +800 33044770 (from abroad)

    24 hours a day, seven days a week

  • E-Mail

    Our customer service is available free of charge via E-Mail

    Write an E-Mail

  • AI Chat


    Our AI-powered search helps with your cloud needs.

    Register now in advance and test the new Open Telekom Cloud AI chatbot soon.

    Experience the future