The fast layer, without the operations.
Fully managed Redis for caching, sessions, queues, and rate limiting. Each database is isolated and TLS-only, with optional automatic failover and durability you choose per workload.
- 2 plan families
- 6 persistence modes
- TLS required
- ~2 min to provision
# TLS is not optional$ redis-cli -u rediss://my-cache:6379$ SET session:8f2c … EX 3600OK$ INFO keyspacedb0:keys=48211,expires=48211
- PlanRedis · 1 GB
- PersistenceAOF_EVERY_1_SECOND
- Replicationoff
FAMILIES
2
In-memory, or RAM plus SSD
DURABILITY
6modes
Included in the plan price
AVAILABILITY
Failover
Optional full replica
ACCESS
TLS only
Isolated instance per database
Three choices, then a connection string
Sized for the workload, not the default
Redis is used for very different jobs, and a cache and a queue do not want the same guarantees. The three decisions below are the ones that actually differ between them.
- 01
Pick a family and a size
Redis keeps the whole dataset in memory. Redis Flex holds hot keys in memory and moves colder ones to SSD, for several times the capacity at the same price.
- 02
Choose durability and a region
Turn on high availability, pick one of six persistence modes, and see the prorated charge before the database is created.
- 03
Connect over TLS
Provisioning usually finishes within a couple of minutes. You get a host, a port, and a password — connect with a rediss:// URL from any Redis client.
What a database includes
Managed, and still yours to tune
Cosmoner runs the instance and the failover. Capacity, durability, and where it lives stay decisions you make per database.
Two plan families
Redis for the lowest and most predictable latency, or Redis Flex when the dataset matters more than cold-read speed. Both are fully managed instances.
In-memory · RAM + SSD
Isolated and TLS-only
Each database is its own instance, reachable only over TLS. The password for the default user is returned when you read the database, never in a list response.
rediss://
Optional high availability
A full replica of the dataset takes over automatically if the primary fails. Half the plan's memory is dedicated to replication, and it bills as two units of the plan.
Automatic failover
Six persistence modes
From nothing on disk to every write persisted before it is acknowledged, with one-second flushes and hourly snapshots in between. Persistence is included in the plan price.
AOF · SNAPSHOT · NONE
A throughput ceiling you can read
Every tier publishes its memory and its operations-per-second ceiling, so sizing is a comparison rather than a guess. Flex trades throughput for capacity.
Published per tier
Rolled back if it fails
A database starts as creating and becomes active once provisioning finishes. If provisioning fails, the charge is rolled back — you are never billed for a database that did not come up.
CREATING → ACTIVE
Persistence
Decide what a restart is allowed to cost
Persistence is what survives a restart, and it is included in the plan price rather than sold as an add-on. The modes range from nothing on disk to every write persisted before it is acknowledged.
- A pure cache in front of a database can safely keep nothing on disk.
- A queue or session store usually wants one-second flushes, losing at most a second.
- Snapshots every 1, 6, or 12 hours suit data you could rebuild but would rather not.
- Redis Flex persists to SSD by design and supports the snapshot modes only.
{ "name": "my-cache", "planSlug": "redis-ram-1gb", "region": "eu-north-1", "replication": false, "dataPersistence": "AOF_EVERY_1_SECOND"}
# active in a couple of minutesrediss://…cloud.redislabs.com:12345
The trade-off, spelled out
Four points on the durability scale
Stronger durability asks more of every write. Weaker durability asks you to be able to rebuild. Pick per database, not per project.
Every write, before the ack
Nothing is acknowledged until it is on disk. The strongest durability on offer, and the right choice when losing a write is not acceptable.
AOF_EVERY_WRITE
Flushed once a second
At most one second of writes is lost. The usual middle ground for a queue or a session store you would rather not rebuild.
AOF_EVERY_1_SECOND
Hourly point-in-time copy
Also available every 6 or 12 hours. Enough for a cache you can warm again, where the copy is a convenience rather than a guarantee.
SNAPSHOT_EVERY_1_HOUR
Nothing on disk
Everything is lost on restart, which is exactly right for a pure cache in front of a database that already holds the truth.
NONE
High availability
A replica costs half the memory, on purpose
High availability is not a checkbox with no consequence. The replica is a full mirror of the dataset, which is what lets it take over instantly — and what makes it take up room.
- 50% of the plan's memory is dedicated to replication, so a 1 GB plan holds 512 MB of your data.
- It bills as two units of the plan price rather than as a separate add-on.
- The replica takes over automatically if the primary fails — there is nothing to trigger.
- So size on the dataset you need to hold, then double it if you want the failover.
# a 1 GB plan, without a replica?planSlug=redis-ram-1gb&replication=falseusable dataset 1024 MBbilled quantity 1×# the same plan, with one?planSlug=redis-ram-1gb&replication=trueusable dataset 512 MBbilled quantity 2×
Where it runs
Close to the app that reads it
A cache only helps if the round trip is short, so pick the region your workload runs in. Redis Flex is sold in fewer regions than Redis — the regions endpoint reports which families each one offers.
- eu-north-1Stockholm
- eu-west-1Ireland
- eu-central-1Frankfurt
- us-east-1N. Virginia
- us-east-2Ohio
The regions endpoint is the source of truth, and reports the plan families available in each region.
One project
What it plugs into
A Redis database is billed on the project's subscription alongside the apps that read from it, behind the same roles and the same API keys.
Questions worth answering up front
Plans, persistence modes, and every endpoint are covered in the Redis API reference.
- Redis or Redis Flex?
- Redis when latency has to be low and predictable across the whole keyspace. Flex when the dataset is large and access is skewed — hot keys stay in memory, and only the cold ones pay the SSD penalty. Flex also has a lower throughput ceiling, so it suits capacity-bound workloads rather than operation-bound ones.
- How much data fits with high availability on?
- Half the plan. The replica is a full mirror, so 50% of the plan's memory is dedicated to replication — a 1 GB plan with HA enabled holds 512 MB of your data. HA also bills as two units of the plan price, so size for the dataset you actually need to hold.
- Which persistence mode should I choose?
- Match it to what losing the data costs. A cache in front of a database can run with nothing on disk. A queue or a session store usually wants one-second flushes. Only pick every-write when a lost write is a real problem, since it is the mode that asks the most of each acknowledgement.
- Does Flex support the same durability options?
- Flex persists to SSD by design and supports the snapshot modes only. The plan list reports what each tier supports, including which of the smallest tiers offer neither replication nor persistence.
- What does it cost?
- Each database is billed monthly on the plan you choose, and the plan list carries the current price for every tier. Before creating one you can preview the prorated amount that will be added to the project's subscription.
- What happens when I delete a database?
- It and everything stored in it are permanently deleted, and the recurring charge stops. This cannot be undone, so take a copy first if the contents matter.