In-Memory DB

What Is It?

In-Memory DB is a managed, Redis-compatible (legacy Redis OSS 7.2) data structure store that provides sub-millisecond latency for caching, real-time analytics, message brokering, and streaming applications. Data lives primarily in RAM with optional on-disk persistence (RDB snapshots, AOF logs, or both). The service runs on dedicated infrastructure with SSD storage, supports both horizontal and vertical scaling, and offers high availability through single-node or multi-node cluster configurations with automatic failover. The v2 API (2.0.0, Cluster resource) is now GA and recommended for all new and production workloads; the v1 API (1.0.0, ReplicaSet resource) remains active but has been announced for deprecation, and customers must migrate existing v1 clusters to v2 themselves (migration is customer-initiated, not automatic).

Quick Facts

Resource Limits

Storage Requirements by Persistence Mode

Storage is automatically calculated from RAM size and persistence mode. Minimum 10 GB per node applies to all configurations. Storage cannot be set manually.

What You Can Do

In-Memory Data Structures

Store and manipulate data using strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams. Execute Lua scripts server-side for complex operations.

Vertical Scaling

Increase CPU cores, RAM, and storage capacity while the instance is running. No application downtime required for vertical scaling operations.

Horizontal Scaling

Add or remove nodes to adjust fault tolerance and capacity. Adding nodes does not cause disruption. Removing nodes may trigger a switchover if the primary is removed.

High Availability Clustering

Deploy multi-node clusters with one primary and up to four passive nodes. Built-in asynchronous replication copies data to passive nodes automatically. Use Semi-Synchronous replication via the WAIT command for stronger consistency guarantees.

Note: Redis Sentinel is not supported. Failover is handled directly by the DBaaS service. Single-node instances automatically fail over to a temporary second node during failures.

Data Persistence

Configure on-disk persistence to survive restarts and failures. RDB mode creates periodic snapshots. AOF mode logs every write operation and rewrites the log in the background. Combine both modes (RDB_AOF) for fastest recovery and comprehensive backup coverage. IONOS strongly recommends enabling at least one persistence mechanism for production workloads.

Key Eviction Policy

Control how keys are removed when the maxmemory limit is reached. Choose from 8 policies: noeviction, allkeys-lru, allkeys-lfu, allkeys-random, volatile-lru, volatile-lfu, volatile-random, or volatile-ttl. Default is allkeys-lru.

Backup and Restore

Automatic daily full backups are retained for 7 days. Backups require a persistence mode to be configured. Restore individual cluster snapshots via API or UI. The v2 API adds inline snapshot restore via the restoreFromSnapshot.sourceSnapshotId field and dedicated /snapshots and /snapshotLocations endpoints.

v2 API (Cluster Resource)

The v2 API (2.0.0) introduces the Cluster resource (replacing ReplicaSet), hashed-password credentials, the idempotent "Ensure" pattern (PUT creates-or-updates), built-in observability controls, and dedicated Versions and SnapshotLocations endpoints. Migrate by replacing /replicasets paths with /clusters, renaming displayName to name, and moving persistenceMode to persistence.mode.

Note: The v1 API (1.0.0, ReplicaSet) is active but deprecation has been announced. A specific deprecation date has not been confirmed in the documentation; consult the official migration guide for the current timeline.

Security and Network Isolation

Access instances only from private LANs within your Virtual Data Center. Enable TLS encryption for client-to-database communication. Role-based user management with password-protected credentials.

Note: Username and password can only be set during instance creation and cannot be changed afterward.

Best For

Consider Alternatives If

Key Considerations

Billing & Costs

• Main billing: Per hour based on CPU cores, RAM, and storage provisioned
• When stopped: Billing continues when the instance is stopped (resources remain reserved)
• Additional costs: Storage costs scale with persistence mode (RDB_AOF at 8x RAM consumes significantly more storage than None at 1x RAM)

Limitations

• Maximum 16 CPU cores and 32 GB RAM per instance (subject to account quota)
• Maximum 2 TB storage per instance; storage cannot be reduced after creation, only increased
• Maximum 5 nodes per cluster; maximum 50 clusters per contract
• Up to 10,000 client connections per cluster (the default of the underlying Valkey engine, not a published IONOS limit)
• Automatic backups retained for 7 days only; backups require a persistence mode
• Redis Sentinel is not supported; failover is managed by the DBaaS service
• Only one network connection is allowed per cluster (private LAN)
• Forbidden private IP ranges: 10.208.0.0/12, 10.233.0.0/18, 192.168.230.0/24, 10.233.64.0/18
• Credentials (username and password) can only be set at cluster creation; password changes are not supported
• Dangerous commands INFO, KEYS, and SORT are permitted but should be used with caution in production
• Maintenance runs in a customer-defined weekly 4-hour window (start time plus 4 hours); actual work duration varies and is usually brief
• v1 API (ReplicaSet) is announced for deprecation; deprecation date not yet confirmed in documentation

Management Options

• Database Manager (web UI) for cluster creation, monitoring, and cost estimation
• REST API (v2 recommended: /clusters endpoints; v1 /replicasets endpoints active but deprecated)
• Go SDK
• Terraform provider
• Ansible