How to add a managed Redis or Postgres on Voroa

Voroa runs your app and its databases on the same platform, in India, on one bill — so you do not have to stitch together separate services for hosting and data. You can add a managed Redis-compatible store or managed PostgreSQL in a few clicks and connect it to your service.

Create a database

1. From your dashboard, select New and choose Postgres or Key-Value (Redis).
2. Give it a name — lowercase letters, numbers, and hyphens, 1–30 characters.
3. Choose a region (Mumbai, IN – the only region currently available).
4. Choose an instance type. The card shows its memory and monthly price, and the storage it includes — see storage below.
5. Select Create database.

Your database is provisioned in India and starts within a few moments. While it is coming up, its status shows Starting; once ready it shows Running.

Your connection URL

Open a database and you will usually see one address. Almost every database has a single URL that works everywhere – from an app running on Voroa, from your laptop, from a GUI client, and from a server you run somewhere else. It is the same line in every case, so there is nothing to choose.

A few databases still have two separate addresses: an internal one that only resolves for services running in your workspace, and a public one. Those show An app on Voroa and Outside Voroa to pick between, and if external access is not on yet, that second tab shows you how to turn it on rather than an address that cannot work.

Select the eye beside the URL to show your password and copy the whole line. Select it again to hide it. Every time you show it is recorded.

Databases created before Voroa began keeping passwords have nothing to show, because the password was never stored on our side and cannot be worked out from the running database. Those databases say so on the page. Change the password once and it is readable from then on. This applies to both PostgreSQL and Key-Value.

A paid PostgreSQL database is built once your payment completes, so nothing is shown on the create screen. Wait until it shows Running, then open it and use Get connection details to get your credentials. That button issues a new password rather than looking up the existing one, so the previous password stops working – harmless the first time, but a second reveal will break any service still using the old one until you update it and redeploy. See PostgreSQL connection details for both paths, and for what each part of the URL means.

The URL already contains the username, password, host, and database name your app needs.

The database dashboard

Once your database is created, its detail page has four tabs:

• Connect – Your connection URL (rotate to get a new one) and non-sensitive connection details (host, port, region).
• Performance – RAM, CPU, and connection readings with charts, and below them the slowest queries on the database (Postgres) or live Key-Value stats. When there is nothing to show, the tab says which of three things is true: the database is new and the first readings have not been taken yet, readings are arriving and nothing is slow, or readings are not reaching us at all. For Key-Value, detailed command logs are marked Coming soon.
• Backups – Available on paid database plans. Automatic nightly backups are off by default; turn them on with the switch in this tab, or use Back up now for an on-demand one. The tab states how long backups are kept. A database on the free plan is not backed up.
• Settings – Size, storage, and database-specific configuration. A few individual settings there are marked Coming soon.

Connect it to your service

Add the connection URL to your service as an environment variable:

• Postgres – add it as DATABASE_URL
• Redis – add it as REDIS_URL

Open your service, go to Environment, add the variable, and select Save changes. Your service redeploys to pick it up. See environment variables for the full flow. Your app reads it the standard way – for example process.env.DATABASE_URL in Node. For what the host, port, database name, user, and password each mean, and the two mistakes that most often break a connection, see PostgreSQL connection details.

Where your database runs, and how it is reached

Most databases run alongside your services and are private: they are reachable from your services on Voroa using an internal address, and are not exposed to the public internet.

Some databases run on a separate database machine instead. Voroa chooses this when it is the better place for your database – you do not pick it, and you do not pay differently for it. A database on its own machine is not on the same internal network as your services, so it is reached over an encrypted public endpoint rather than an internal address. The connection URL you are given already points at the right place, so nothing changes in how you connect.

What does change is that the endpoint is reachable from outside Voroa. Two things follow, and both are worth knowing:

• Anyone who can sign in to your workspace with permission to change this database can also show its password, and could already have changed it. Treat workspace access as database access.
• Your password is the only thing standing between the internet and your data, so keep it in a secrets manager and rotate it if it is ever pasted somewhere it should not be.
• You can restrict which addresses may connect at all on the database’s Connect tab, under trusted sources. Until you set one, any address may attempt a connection (it still needs your password). If your application connects from a small, known set of addresses, setting this is the single biggest thing you can do to protect the database.

The Connect tab always shows the address your database is actually using, so you never have to guess which of the two applies to you.

If you have lost your connection URL

The Connect tab shows the non-sensitive details (host, port). You can also rotate your credentials there – this generates a new password and shows the new connection URL once. Update your service’s environment variable after rotating.

Change size

Open the database and go to the Settings tab. The Size section shows what you are on now and offers Change plan or add storage, which opens the plan screen. This is the same for every database, Free or paid.

On the plan screen you pick the instance type, and for Postgres you also choose how much storage you want. If the database is not on a paid plan yet, you are taken through checkout; if it already is, the change is applied to your existing plan.

A size change restarts the database briefly, so do it during a quiet window.

What a paid Postgres type gives you

Each paid Postgres type on the plan screen states three things, and each one is enforced on your database rather than being a guideline.

• Memory. A hard limit. Your database is given this much RAM and cannot use more.
• CPU, with a burst ceiling. The CPU figure is your guaranteed share when the machine is busy – if every database on the machine wants CPU at the same moment, you get at least that much. The burst figure is the ceiling you are allowed to reach when the machine is not busy, so a heavy query or a nightly job can finish faster than your guarantee alone would allow. Burst is a ceiling, not a second guarantee: plan your steady-state workload against the guaranteed figure.
• Connections. The maximum number of simultaneous connections Postgres will accept. If your application opens many short-lived connections, use connection pooling rather than a larger type – a pooler lets far more clients share the same connections.

The Free type is sold on memory only. It has no CPU guarantee and no burst ceiling, and it shares CPU with everything else on the machine.

Storage

Every database has a storage limit. On the Free type that limit is included. On the paid Postgres types you choose the amount of storage yourself and are billed for what you choose, so the size of the instance and the size of the disk are two separate decisions.

Your limit and how much of it you are using are shown under Storage in the Settings tab. As a database approaches its limit you will see a warning there, and once a Postgres database passes about 95% of its limit it is placed in read-only mode until usage comes back down. To raise the limit, open Change plan or add storage in the Settings tab and increase the storage.

Storage changes in both directions. Adding storage raises the limit. Reducing it lowers the limit too, at the end of your billing period – your data is not deleted, but the lower limit is the one that is enforced from then on, so a database holding more than the smaller type allows will go read-only. Check what you are storing before you move down. See managed database storage limits.

Key Value: choose what happens when memory is full (eviction policy)

A Key Value instance holds its data in memory, so at some point it fills up. What happens then is your choice, and there are two answers most people want:

• Keep everything — nothing is removed. When memory is full, new writes are refused instead. Choose this for a queue or a counter, where a rejected write is better than a missing entry. This is the default.
• Drop the oldest — the keys you used least recently are removed to make room, so writes keep working. Choose this for a cache.

You can pick one while creating the instance, and change it later from the instance’s Settings tab. Changing it does not restart the instance.

Six more specific options are available in Settings. Four of them only ever remove keys you gave an expiry time to, which is useful when part of your data must never be dropped — with one catch: if no key has an expiry time, there is nothing those options are allowed to remove, so writes are refused just as “Keep everything” would refuse them.

If you are moving from another provider, these are the standard Redis eviction policies under Voroa’s names:

If this choice does not appear on your instance, it is not available there yet. The page will tell you rather than leave you looking for it.

Postgres: enable extensions

Standard Postgres extensions such as UUID generation, trigram search, and cryptographic functions can be enabled from the Settings tab under Extensions. No restart needed.

See How to enable PostgreSQL extensions for the full list and instructions.

Delete a database

Open the database, go to the Settings tab, scroll to Danger zone, and select Delete database. This removes the database and its data straight away, and it cannot be undone - you will not be able to reach it again. Backup copies taken before the deletion are removed within 30 days. Remove the connection URL from any service that still references it.

Related

• Voroa MySQL: a managed MySQL 8 database
• Databases from your repo: Postgres and Key Value, auto-linked