website/docs/azure/faq.md
Azure Cosmos DB Garnet Cache is a fully managed, high-performance caching service built on the Garnet remote cache-store from Microsoft Research. It provides Redis protocol compatibility with ultra-low latency and enterprise-grade security, scalability, and reliability.
Azure Cosmos DB Garnet Cache is currently in an expanded Private Preview. Please register your subscription to join the preview.
As a fully managed service, Azure Cosmos DB Garnet Cache handles infrastructure provisioning, scaling, patching, and monitoring automatically. Self-hosted Garnet requires you to manage the infrastructure, updates, and operations yourself.
Azure Cosmos DB Garnet Cache works alongside Azure Cosmos DB to reduce latency for frequently accessed data. Your application manages the integration including checking the cache before reading from Azure Cosmos DB, and updating or invalidating cached entries after writing to Azure Cosmos DB. You control when to update or invalidate cached data to maintain consistency.
Yes, Azure Cosmos DB Garnet Cache uses the Redis RESP protocol, making it compatible with existing Redis clients in all major programming languages without code changes.
Azure Cosmos DB Garnet Cache supports the RESP protocol and doesn't have full support for any specific Redis version. Visit the list of supported Redis commands.
Azure Cosmos DB Garnet Cache clusters are billed per instance per hour with no licensing fees. Each node is billed for the chosen SKU. When data persistence is enabled, each node also has an attached disk that is billed separately. Pricing per SKU is set at different rates than the underlying Azure VM and is subject to change between our extended Private Preview and Public Preview.
For information about pricing, see the Azure Cosmos DB Garnet Cache pricing page.
Latency is typically sub-millisecond and is around 3ms at the 99th percentile. Performance and throughput varies by tier, key/ value size, and number of concurrent requests, among other factors.
Yes. You can scale out by adding shards on a running cluster without downtime. You can also scale up by changing the SKU size, which is done by deprovisioning and reprovisioning the cluster.
Garnet doesn't impose a software limit on the number of client connections on any node for any SKU. In practice, the number of concurrent connections a node can handle is bounded by its compute and network resources, which vary by SKU. See the virtual machine limits corresponding to the Azure Cosmos DB Garnet Cache SKU you choose.
All Redis client libraries are supported. Ensure you visit the list of supported commands. Popular libraries by language include:
For local development, you can use the self-hosted Garnet server.
Azure Cosmos DB Garnet Cache is available in many Azure regions. Check our supported regions list.
Azure Cosmos DB Garnet Cache can be configured with availability zones during provisioning in supported Azure regions where there is capacity for your chosen SKU. See the list of Azure regions with availability zone support.
Creating or scaling a Garnet cluster requires Microsoft.DocumentDB/garnetClusters/write and Microsoft.Network/virtualNetworks/subnets/join/action on the cluster's subnet. The built-in Owner and Contributor roles include both permissions; Cosmos DB-specific roles (such as Cosmos DB Operator or DocumentDB Account Contributor) do not. If you use a custom role, ensure it includes both actions. See permissions to create and manage a cluster.
Check these common issues:
Common causes and solutions:
Troubleshooting steps: