For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/es/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/es/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/es/guides/public-cloud/databases/valkey-capabilities.md.

Capabilities and Limitations of Public Cloud Databases for Valkey

Ver como Markdown

Discover the capabilities and limitations of Public Cloud Databases for Valkey

Objective

This page provides the technical capabilities and limitations of the Public Cloud Databases for Valkey offer.

We continuously improve our offers. You can follow and submit ideas to add to our roadmap at https://github.com/orgs/ovh/projects/16/views/5.

Capabilities and limitations

Supported regions and multi-AZ

The Public Cloud Databases offer is available in all Public Cloud 1-AZ and 3-AZ regions.

Database nodes have to be in the same region.

Valkey versions

The Public Cloud Databases offer uses the following Valkey versions:

  • Valkey 8.1
  • Valkey 9.1

Please refer to the DBMS lifecycle policy guide for recommendations on version upgrades and end of life announcements of major versions. Additionally, you can follow the Valkey release cycle on the official page: https://valkey.io/topics/releases/.

Valkey clients

You can use any of the Valkey clients to access your service, as long as it supports TLS.

Plans

Two plans are available:

  • Discovery: 1 node
  • Production: 2 nodes (a primary node and a replica node)

Your choice of plan affects the number of nodes your cluster can run, the SLA, and a few other features such as backup retention.

License type

Valkey is provided under BSD 3-Clause License.

More information on https://valkey.io/topics/license/.

Hardware resources

For information on node types and pricing, please refer to the price page.

Features

Network

The host and port of your service are displayed in the Connection information section of the Dashboard tab of your service in the Control Panel.

Public as well as private networking (vRack) can be used for all the offers.

Ingress and Egress traffic are included in the service plans and unmetered.

The database service's IP address is subject to change periodically. Thus, it is advised not to rely on these IPs for any configuration, such as connection or egress policy. Instead, utilize the provided DNS record and implement CIDR-based egress policies for more robust and flexible network management.

Private network considerations

Here are some considerations to take into account when using private network:

  • Network ports are created in the private network of your choice. Thus, further operations on that network might be restricted - e.g. you won’t be able to delete the network if you didn’t stop the Public Cloud Databases services first.
  • When connecting from an outside subnet, the Openstack IP gateway must be enabled in the subnet used for the Database service. The customer is responsible for any other custom network setup.
  • Subnet sizing should include considerations for service nodes, other co-located services within the same subnet, and an allocation of additional available IP addresses for maintenance purposes. Failure to adequately size subnets could result in operational challenges and the malfunctioning of services.
  • OpenStack subnets routes announcement will not be applied to your services.
  • You can only create private network services if you are the original owner of the network. You can not create private network services on a shared network.
Authorised IPs

Once your service is up and running, you will be able to specify IP addresses (or CIDR blocks) to authorise incoming traffic. Until then, your service will be unreachable.

TLS encryption

TLS is mandatory: plaintext connections are refused. Use a connection URI of the form valkeys://<username>:<password>@<host>:<port>.

The server certificate is signed by a public certification authority, so you do not need to download a CA certificate. Keep certificate verification enabled in your client.

See the Connect using the CLI guide for an example.

Maximum simultaneous connections

The number of simultaneous connections in Public Cloud Databases for Valkey depends on the total memory available on the server. We allow 4 connections per megabyte of RAM (4096 connections per GB of RAM), with a minimum of 10000 connections, even on the smallest servers.

So for example on a server with 8 GB memory, you will get up to 8 * 4096 = 32768 simultaneous connections.

Memory and eviction

When the memory of your service is full, its behaviour depends on the valkey_maxmemory_policy advanced parameter. With the default value, noeviction, Valkey does not delete any key and rejects write commands until memory is freed. The other values (allkeys-lru, allkeys-lfu, allkeys-random, volatile-lru, volatile-lfu, volatile-random, volatile-ttl) evict keys to make room for new data, which is usually what you want for a cache.

See the Advanced parameters references documentation to change this policy.

Persistence

Persistence is controlled by the valkey_persistence advanced parameter:

  • rdb: Valkey writes RDB snapshots to disk, which are used for backups.
  • off: no RDB snapshot is written. Backups and forks are unavailable, and all data is lost if the service restarts or is powered off.

AOF (Append Only File) persistence is not available.

Advanced parameters

You can further customise your service by using advanced parameters. See the Advanced parameters references documentation for more information on the supported parameters.

Please note that changing some advanced parameters may restart the service.

Backups

Discovery plan clusters are automatically backed up every 12 hours. Backup retention is 1 day.

Production plan clusters are automatically backed up every 12 hours. Backup retention is 3 days.

Backup copies are stored in two regions.

See the Automated Backups guide for more information.

Logs and metrics

Logs and metrics are available through the Control Panel, API and can be forwarded to Logs Data Platform. For setup instructions, see the Public Cloud Databases - How to setup logs forwarding guide.

  • Logs retention: 1000 lines of logs
  • Metrics retention: 1 calendar month

Please note that if the database instance is deleted, logs and metrics are also automatically deleted.

Users and roles

Users can be created, edited, deleted and have their password reset via the Control Panel and API. ACL changes apply immediately, without reconnecting.

For each user you can specify:

  • Username
  • Keys (such as cache:*)
  • Categories (such as +@read)
  • Commands (such as +get -flushall)
  • Channels (such as news:*)

See the Users and ACLs guide for more information.

You can follow the official Valkey documentation about commands: https://valkey.io/commands/.

Here is the list of unsupported commands:

  • bgrewriteaof
  • cluster
  • command
  • debug
  • failover
  • migrate
  • slaveof
  • acl
  • bgsave
  • config
  • replicaof
  • lastsave
  • save
  • shutdown
  • monitor

Lua scripts (EVAL, EVALSHA, SCRIPT) and functions (FUNCTION, FCALL) are supported.

Other limitations

  • Cluster mode (sharding) is not supported.
  • AOF persistence is not available (see Persistence).
  • The CONFIG command is not available: use advanced parameters instead.
  • Logical databases are supported with SELECT <n>. Their number is set by the valkey_number_of_databases advanced parameter (up to 128).

We want your feedback!

We would love to help answer questions and appreciate any feedback you may have.

For training or technical assistance implementing our solutions, contact your sales representative or visit our Professional Services page to request a quote and have your project analysed by our experts.

Are you on Discord? Connect to our channel at https://discord.gg/ovhcloud and interact directly with the team that builds our databases service!

¿Le ha resultado útil esta página?