Managed database storage limits

Every managed database on Voroa comes with a storage limit. The limit is part of the size you chose for that database, in the same way its memory is — a larger size includes more storage. The limit covers everything the database keeps on disk: your tables and rows, indexes, and its own internal files.

Storage is per database. Each database has its own limit, and one database filling up does not affect another.

See how much you are using

Open the database from your dashboard and go to the Settings tab. The Storage section shows how much of your limit is in use, as a percentage and as an amount, along with your total capacity.

Usage is measured periodically rather than instantly, so the figure can be a few minutes behind what you have just written. On a database that was created moments ago, usage may not have been measured yet — the page says so rather than showing a misleading zero.

What happens as storage fills up

Nearly full. Once usage passes 80% of the limit, the Storage section shows a warning. This is the point to act: the database is still fully writable, so you can delete data you no longer need, or move to a larger size.

At the limit. A Postgres database that reaches its storage limit is placed in read-only mode, and the database page shows a read-only notice. Read-only is a deliberate stop rather than a failure: it protects the data you already have instead of letting the database run out of room mid-write.

Key-Value databases are not placed in read-only mode. They are bounded by the memory of their size, and what happens when they are full is governed by the eviction policy you choose. See how to add a managed Redis or Postgres for how to set one.

What read-only means for your app

In read-only mode:

• Reads keep working. Queries that only read data return results as normal, so parts of your app that just display data keep working.
• Writes are rejected. Inserts, updates, and deletes fail, and your app sees an error from the database. Depending on how your code handles it, this may surface as a failed request or a visible error to your users.
• Your data is intact. Nothing is deleted and nothing is lost. The database is paused for writes, not damaged.

Your service itself keeps running — only writes to this database are affected.

Restore writes

Writes are restored once the database is back under its storage limit. The check runs periodically, so it can take a few minutes for the change to take effect after you act. You do not need to restart anything.

Move to a larger size. This is the direct way out of read-only mode: a larger size includes more storage, so the same data is comfortably under the new limit and writes resume. Open the database, go to the Settings tab, and choose a larger size under Size. Applying a new size restarts the database briefly.

Reduce what you store. Once writes are available again, keeping usage down is the way to stay out of read-only mode. What usually helps:

• Delete rows and tables you no longer need, and reclaim the space afterwards.
• Drop indexes that are not used.
• Move large files — images, uploads, documents — out of the database and store them in object storage, keeping only a reference in the database.
• Trim tables that grow without bound, such as logs, events, and audit trails, by deleting rows older than the window you actually query.

Plan ahead

• Check the Storage section from time to time, especially after a change that writes a lot of data.
• Give yourself headroom. Sizing so that you sit near the limit leaves no room for a spike.
• Keep bulk data out of the database where you can. Object storage is a better home for large files than a database row.

Next steps

• How to add a managed Redis or Postgres
• Import an existing database
• Usage and billing