Skip to main content

Features

Two things decide what a cluster can do: how you let applications reach it, and the engine you pick. Neither is easy to change afterwards, so read both before you provision, and see Product Introduction for the engine catalog itself.

note

Engine and feature availability changes as the service develops. Treat this page as the documented state and the Console Portal as the current one.

Network connectivity​

Applications never address a node directly. They connect through a database endpoint, and what sits behind that endpoint follows from the deployment model you chose at provisioning time.

Deployment modelThe endpoint points to
Single NodeThe database instance
High availabilityA DB Proxy representing the cluster

Going through an endpoint decouples application logic from cluster architecture, so a topology change or a failover does not force you to change connection settings.

Private and public access​

Two access models are available, and the choice is a security decision as much as a networking one.

Access modelWhat it meansUse it for
Private accessThe cluster is reachable only inside the private network (VPC)Production, and anywhere exposure has to stay minimal
Public accessThe cluster exposes a public endpoint reachable from the Internet, with additional security controlsExternal systems, temporary administrative access, testing and integration

Security Group and Floating IP​

These two controls are what make public access safe enough to use, and they are meant to be used together rather than separately.

A Security Group is a set of stateful firewall rules that allow or deny inbound and outbound traffic by IP address or CIDR, port, and protocol. It is how you enforce least privilege, permitting access only from authorized sources such as applications in the same VPC or an approved bastion host. Rule changes take effect immediately and never require a cluster restart.

A Floating IP is a public IP address you can attach to or detach from a database instance on demand, which is what turns on Internet reachability. Pair it with a Security Group that restricts the allowed source ranges and exposes only the database port you actually need, such as 3306, 5432, or 1433.

warning

Enable a Floating IP only while you need it, and prefer private access for production. A Floating IP with a permissive Security Group puts the database on the public Internet.

The procedure for both is in Connect to database with Floating IP.

Features limited to specific engines​

FeatureAvailable onWhat to know
Upgrade database versionPostgreSQL, MySQL, MariaDB, Redis, KafkaOne target version per engine, in a single hop, at present: PostgreSQL 16.2 → 16.11, MySQL 8.0.25 / 8.0.30 / 8.0.31 → 8.0.42, MariaDB 10.5 / 10.6 / 10.9 → 10.11, Redis 7.2.1 → 7.2.13, Kafka 3.4.0 → 3.8.0. Paths change over time, so check the dialog on your own cluster. Other engines show no upgrade control, and an upgrade cannot be rolled back. For every other engine, moving between versions is a manual data migration under the version policy.
Database proxyMySQL, PostgreSQL, MariaDBHigh Availability clusters only. The DB Proxy tab stays hidden unless both conditions hold.
Kafka users and ACLsKafkaSASL authentication for producers, consumers, and Kafka Connect.
Backup & restoreEvery engine except Kafka and RabbitMQBackup was removed from Kafka and RabbitMQ on 15 September 2026, together with the files that existed on those clusters. The Backup tab no longer appears for them.
Point-in-time recoveryPostgreSQL, MySQL, MariaDBProtection starts only after the next full backup completes, not when you enable it.
Differential backup jobs, in Configure backup schedulePostgreSQL, MySQL, MariaDB, SQL ServerRelational engines only. Full backup jobs are not restricted this way.
Push backup data to S3PostgreSQL, MySQL, MariaDB, SQL Server, Redis, MongoDB, TimescaleDB
High Availability, in Create a databaseEvery engine except CassandraCassandra sets node count through Number Of Nodes instead. On ClickHouse, read the replication note below before relying on it.

Behavior that differs by engine​

These are the cases where the same feature behaves differently depending on what you are running. Each one has caused a surprise worth planning around.

EngineWhat differs
PostgreSQL, OpenSearch, ClickHouseIncreasing the flavor or adjusting storage leaves some parameters unapplied until you restart the cluster yourself. The new vCPU and RAM take effect without the restart, but the cluster list shows a warning icon until you perform it. Applies to both resource changes and auto scaling.
PostgreSQL HA clusters created before March 13, 2026Enabling PITR restarts the cluster automatically and briefly interrupts service. Enable it off-peak.
KafkaBackup was removed on 15 September 2026, along with the backup files that existed on Kafka clusters. Creating or updating a user with SASL/PLAIN restarts the cluster; SASL/SCRAM-SHA-256 and SASL/SCRAM-SHA-512 do not.
RabbitMQBackup was removed on 15 September 2026, along with the backup files that existed on RabbitMQ clusters.
ClickHouse with High AvailabilityReplicas are created per shard, but a table replicates only if you create it with a replicated engine from the MergeTree family. A plain MergeTree table stays on the node that received the write. See the ClickHouse - High Availability FAQ.
CassandraNo High Availability toggle. Size the cluster with Number Of Nodes at provisioning time.
warning

Enabling High Availability on ClickHouse is not enough on its own. Check the table engine on every table you rely on, because an unreplicated MergeTree table loses its data if the node holding it fails.

Features that work the same on every engine​

Configured identically whichever engine you run, aside from the engine-specific behavior above:

Next steps​