Skip to main content

Frequently Asked Questions

General Questions​

What is Azure Cosmos DB Garnet Cache?​

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.

How can I access the Preview?​

Azure Cosmos DB Garnet Cache is currently in an expanded Private Preview. Please register your subscription to join the preview.

How is it different from self-hosted Garnet?​

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.

How does it work with Azure Cosmos DB?​

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.

Is it compatible with Redis clients?​

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.

What Redis version is supported?​

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.

How is Azure Cosmos DB Garnet Cache priced?​

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.

Performance and Scalability​

What performance can I expect?​

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.

Can I scale my cache?​

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.

How many connections are supported?​

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.

Development and Integration​

Which client libraries are supported?​

All Redis client libraries are supported. Ensure you visit the list of supported commands. Popular libraries by language include:

Can I test it locally?​

For local development, you can use the self-hosted Garnet server.

Regional Availability​

Which regions is it available in?​

Azure Cosmos DB Garnet Cache is available in many Azure regions. Check our supported regions list.

Which regions support Availability Zones?​

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.

Troubleshooting​

Cluster creation or scaling fails with an authorization error​

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.

My application can't connect to the cache​

Check these common issues:

  1. VNet configuration: Verify your client application is in the same virtual network as your cache.
  2. Authentication: Verify you've configured role based access control, which is required for data plane access. Role assignments can take several minutes to propagate after being created or modified.
  3. SSL/TLS: Ensure your client supports TLS.

Cache performance is slower than expected​

Common causes and solutions:

  1. Connection pooling: Ensure proper connection pool configuration.
  2. Hot keys: Check for key access patterns causing bottlenecks.
  3. Memory pressure: Monitor memory usage and consider scaling up.
  4. Network latency: Test from the same region as your cache.

I'm getting timeout errors​

Troubleshooting steps:

  1. Check timeout settings: Verify client timeout configuration.
  2. Monitor CPU/memory: High resource usage can cause timeouts.
  3. Network issues: Test network connectivity between client and cache.

Getting Help​

Where can I get technical support?​

  • Documentation: For conceptual guidance and tutorials
  • Azure Support: Create support tickets for technical issues
  • Community: Stack Overflow and Azure forums

How do I report bugs or request features?​

  • Azure Support for bugs and critical issues
  • Feedback Form for feature requests or suggestions

Next Steps​