Voroa Key Value: a managed in-memory store
Create a managed key-value instance on Voroa: plans from 256 MB to 10 GB, internal and TLS external connections, nightly snapshots, password rotation.
What this covers
A key-value store keeps small pieces of data in memory, which makes reads and writes very fast. That suits a specific set of jobs well: login sessions, cached results of an expensive query, a simple job queue, rate-limit counters, and locks that stop two processes doing the same work at once. Running one yourself means patching it, watching its memory and restarting it when it fills; a managed instance moves that work to the platform.
Plans
Every Voroa Key Value instance is its own container with its own password and its own memory. The free plan gives you 128 MB to build against. Paid plans run from 256 MB to 10 GB of RAM, each with a connection ceiling that grows with the plan; 20 GB and 40 GB sizes are listed but not yet open. Current prices are always on the create page in the dashboard - they are set platform-side, and this page does not repeat them so it can never disagree with what you are actually charged.
Upgrading a plan rebuilds the instance with the new memory, which is a brief restart. Your data, address and password do not change.
Connecting
- From your Voroa services (internal): every instance has an internal address on your private network. Copy the connection URL shown once at create time (or after a password rotation) into an environment variable on your service.
- From outside Voroa (external): enable external access on the database page. You get a TLS
endpoint (
rediss://) on a dedicated port, protected by your instance password. A per-source IP allow list is not available for Key Value yet - the endpoint accepts any source that has the password, over TLS only. If you need source restrictions today, keep external access off and connect through your Voroa services instead.
Durability, honestly
An in-memory store is a poor place for anything you cannot afford to lose. Voroa writes your instance’s data to disk and takes a nightly backup, so a restart does not start from empty - but between writes a crash can lose the most recent moments of data. Treat it as fast working memory next to a database, not as the database.
Browse your keys
The Data tab on the database page lets you look inside the instance without a client. It is read-only: nothing you do there can change or delete a key.
- Find keys by pattern (for example
user:*) and load more page by page. - Click a key to see its type, its expiry and its value. Long values are cut at 4 KB; lists, sets, hashes and sorted sets show their first 100 items and streams their first 50 entries, with the full size shown when there is more.
- Run one read command at a time:
SCAN,TYPE,TTL,PTTL,EXISTS,STRLEN,GETRANGE,LRANGE,ZRANGE,XRANGE(withCOUNT),HSCAN,SSCAN,ZSCAN, and the size commandsDBSIZE,HLEN,SCARD,LLEN,ZCARD,XLEN. Every read is bounded - at most 1,000 items, or 4 KB of a value - so a browse stays small. Keep ranges short on very large values. Commands likeKEYS,GET,HGETALLorINFOare not available here; useSCANandGETRANGEinstead.
When memory is full
Each size has a memory limit. What happens when your data reaches it depends on the setting When memory is full, on the create page and on the database’s Settings tab:
- Keep everything (the default). Nothing is removed. When memory runs out, new writes are refused and your app gets an error for each one. Choose this when every key matters.
- Drop the oldest (and the other drop options). Keys are removed to make room, so new writes keep working. Choose this when you use the database as a cache.
Changing the setting applies right away. Your database does not restart. If it cannot be applied to the running instance at that moment, the page says so, and it applies the next time the instance is rebuilt.
We email the account that owns the database when a Key Value database is close to full or has started refusing writes: when it is set to Keep everything and reaches 90 percent of its memory, or when it refuses writes because it has no memory left. You get one email per episode, not one every few minutes. To fix it, move to a larger size, or switch the setting above if the database is a cache.
What you can also do
- Rotate the instance password from the database page (the new URL is shown once).
- Import an existing dataset: How to import an existing database.
Related guides
- How to add a managed Redis or Postgres on Voroa
- How to add environment variables on Voroa
- Managed Redis on Voroa - what a key value store includes, and what each size costs.