Features
Three things decide what a cluster can do: the deployment model you pick, how you let applications reach it, and the engine you pick. None of them is easy to change afterwards, so read all three before you provision, and see Product Introduction for the engine catalog itself.
Engine and feature availability changes as the service develops. Treat this page as the documented state and the Console Portal as the current one.
Deployment models
Before the per-feature detail, the choice that shapes most of it. Every cluster is deployed in one of two models, picked at provisioning time based on what you need from availability, performance, and cost.
| Single Node | High Availability (HA / Cluster) | |
|---|---|---|
| Nodes | One database instance, no standby | A primary plus one or more standby or replica nodes |
| Placement | Single node | Same or different Availability Zones |
| Failover | None | Automatic. The database is monitored continuously and fails over to a standby when the primary fails |
| Downtime | Expected during node failure and maintenance | Minimized by failover |
| Suited to | Development and test, low to medium load, and cases where a simpler and cheaper architecture matters more | Production and business-critical systems |
A Single Node cluster gets the full compute allocation, meaning vCPU, RAM, and storage, on that one node. Backups still run on whatever schedule the service is configured with, so the model is not unprotected. What it lacks is a standby, so availability tracks the health of that single node.
High Availability buys three things beyond reduced downtime: better reliability and recoverability, read scaling through replicas when you configure it, and the option to put Database proxy in front for connection routing.
Which model you can choose, and what HA actually delivers, both vary by engine. The tables below carry the specifics.
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 above.
| Deployment model | The endpoint points to |
|---|---|
| Single Node | The database instance |
| High availability | A 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 model | What it means | Use it for |
|---|---|---|
| Private access | The cluster is reachable only inside the private network (VPC) | Production, and anywhere exposure has to stay minimal |
| Public access | The cluster exposes a public endpoint reachable from the Internet, with additional security controls | External 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.
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
| Feature | Available on | What to know |
|---|---|---|
| Upgrade database version | MariaDB | One path only, MariaDB to MariaDB 10.9. Other engines show no upgrade control. An upgrade cannot be rolled back. For every other engine, moving between major versions is a manual data migration under the version policy. |
| Database proxy | MySQL, PostgreSQL, MariaDB | High Availability clusters only. The DB Proxy tab stays hidden unless both conditions hold. |
| Kafka users and ACLs | Kafka | SASL authentication for producers, consumers, and Kafka Connect. |
| Point-in-time recovery | PostgreSQL, MySQL, MariaDB | Protection starts only after the next full backup completes, not when you enable it. |
| Differential backup jobs, in Configure backup schedule | PostgreSQL, MySQL, MariaDB, SQL Server | Relational engines only. Full backup jobs are not restricted this way. |
| Push backup data to S3 | PostgreSQL, MySQL, MariaDB, SQL Server, Redis, MongoDB, TimescaleDB | |
| High Availability, in Create a database | Every engine except Cassandra | Cassandra sets node count through Number Of Nodes instead. On ClickHouse, read the replication note below before relying on it. |
Provisioning fields that only some engines show
The create-cluster form changes shape with the engine you pick, so a field described in the guide may not appear for you.
| Field | Shown for |
|---|---|
| Edition, meaning Enterprise, Standard, or Web | SQL Server only |
| Database Name | Every engine except Redis and Kafka |
| VHost Name | RabbitMQ only |
| Number Of Nodes | Cassandra only |
| High Availability | Every engine except Cassandra |
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.
| Engine | What differs |
|---|---|
| PostgreSQL, OpenSearch, ClickHouse | A vCPU or RAM change does not take effect until you restart the cluster yourself. Until you do, it keeps running the old configuration and shows a warning icon in the cluster list. Applies to both resource changes and auto scaling. |
| PostgreSQL HA clusters created before March 13, 2026 | Enabling PITR restarts the cluster automatically and briefly interrupts service. Enable it off-peak. |
| Kafka | Running a backup can interrupt service, so schedule Kafka backups for low-traffic periods. Creating or updating a user with SASL/PLAIN restarts the cluster. |
| ClickHouse with High Availability | Replicas 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. |
| Cassandra | No High Availability toggle. Size the cluster with Number Of Nodes at provisioning time. |
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:
- Create a database, view the database list, and view database detail
- Stop, start & restart database
- Manage Backup service and full backup jobs
- Restore from backup, which works on every supported engine
- Change database resource configuration and database parameters
- Change maintenance window, where notifications are email only
- Monitor database with FMON, action logs, and reporting
Next steps
- Database Engine Versions for which versions of your engine are available and when support ends
- Product Introduction for the engine catalog and the shared responsibility split
- Create your first database to provision your first cluster
- Create a database for the full form reference