FAQ

IONOS CLOUD DBaaS for In-Memory DB is a fully managed, in-memory data structure store compatible with the Redis® OSS API. In-Memory DB v2 is based on Valkey. It combines an in-memory data store with a dynamic, real-time database, and can be used as a dedicated in-memory data store, a real-time database service, a dedicated in-memory data store, a message broker, or a streaming engine. For more information, see the Overview.

No. You can order and manage an In-Memory DB cluster through the Data Center Designer (DCD), the API, or automation tools such as Ansible and Terraform. To connect to your instance, use redis-cli or a Redis®-compatible client driver, optionally over a TLS-secured connection.

In-Memory DB v2 clusters support Valkey versions 9, 8.1, and 8. In-Memory DB v1 instances default to Redis version 7.2.

In-Memory DB runs exclusively on Dedicated Core infrastructure; the CPU type cannot be changed.

IONOS CLOUD handles database management through the DCD or the DBaaS API, regular patches and upgrades during maintenance windows, automated snapshots or backups (depending on your cluster version) for disaster recovery, and service monitoring for both the cluster and the underlying infrastructure.

Tasks related to the optimal health of your In-Memory DB cluster remain your responsibility, including optimization, organizing data, and updating statistics. For more information, see Platform tasks.

You cannot change the password through the DCD. Using the In-Memory DB v2 API, you can update a user's password by including it in the credentials property of a PUT /clusters/{clusterId} request; the password is updated if the user already exists. For more information, see How are credentials and passwords managed in the In-Memory DB v2 API?.

You have access to all command categories; however, within the "dangerous" category, permissions are limited to the INFO, KEYS, and SORT commands only. For more information, refer to the In-Memory DB documentation.

According to the In-Memory DB documentation, stack features that display their logo are not supported.

Unfortunately, IONOS CLOUD does not use or provide support for an In-Memory DB Sentinel. However, we offer monitoring and automatic failover features.

The provisioned Block Storage in an In-Memory DB cluster depends on the amount of RAM configured and the data persistence mode selected. As a result, you cannot select the amount of Block Storage for your cluster; instead, they are calculated automatically following a pre-determined ratio. For more information, see Determine Provisioned Block Storage in an In-Memory DB Cluster.

A cluster can have between 1 and 5 instances. A value of 1 creates a standalone instance; values 2–5 create a replicated setup with one primary and n-1 passive secondaries.

Replication between the primary and secondary instances is always asynchronous. The replication mode is not configurable.

Migration is not automatic. The v1 clusters must be migrated manually through the API before v1 is decommissioned. For step-by-step guidance, see Migrate from In-Memory DB v1 to v2.

No. In the DCD, restoring from a snapshot is only available while creating a new cluster, through the Restore configuration section. For more information, see Restore an In-Memory DB Cluster. To restore an existing cluster's data in place, use the v2 API's restoreFromSnapshot property in a PUT /clusters/{clusterId} request.

The In-Memory DB v2 API is a fully managed, high-performance REST API for provisioning and managing In-Memory DB clusters, supporting caching, real-time analytics, and message brokering workloads. It renames the primary resource from ReplicaSet to Cluster, introduces dedicated Versions and SnapshotLocations endpoints, adds inline snapshot restore, hashed password credentials, and built-in observability controls. For more information, see In-Memory DB v2 Cloud API.

The v2 API requires API token authentication (tokenAuth). You must include a valid token in the Authorization header of every request. For information on generating tokens, see the Authentication API.

The v2 API uses PUT /clusters/{clusterId} as an idempotent "Ensure" operation — it creates the cluster if it does not exist, or updates it to match the provided payload if it does. Fields omitted from the request are filled with defaults rather than inheriting their previous values.

Credentials are managed through the credentials property on the cluster resource. When included in a PUT request, the specified user is created if they do not exist, or their password is updated if they do. Omitting credentials leaves them unchanged. Passwords must be submitted as a pre-hashed SHA-256 value — a 64-character lowercase hexadecimal string. Base64-encoded SHA-256 hashes are not accepted.

Snapshot behaviour is configured through the snapshot property on the cluster resource. You can set the Object Storage location where snapshots are stored, a retentionDays value (1–365 days, defaulting to 7), and a snapshotHours array specifying the UTC hours at which scheduled snapshots are taken. An empty snapshotHours array disables scheduled snapshots. Use GET /snapshot-locations to retrieve the list of valid storage locations.

Restore is performed inline — there is no separate Restore endpoint in v2. Include the restoreFromSnapshot field with the sourceSnapshotId UUID in the POST /clusters body to initialize a new cluster from a snapshot, or in a PUT /clusters/{clusterId} body to overwrite an existing cluster's data in place. Only snapshots from clusters in the same region are eligible. For in-place restores, the cluster may experience a brief period of downtime.

Yes. All listing endpoints support pagination through offset and limit parameters (maximum 1000 per page). The GET /clusters endpoint supports filter.name (case-insensitive substring match) and filter.state filters. The GET /snapshots endpoint supports filter.clusterId to scope results to a specific cluster.

In Create Cluster or Ensure Cluster, set logsEnabled to true to enable log collection and metricsEnabled to true to enable metrics collection. If the Observability service is not activated on your contract, the setting is accepted but has no effect until the service is activated.