# Databases

One page with every database of your organisation: how long it was really up, how often it woke, how far it scaled, its size and what it cost.


Open **Databases** in the sidebar of the console. It lists every database Brewless manages for your organisation, whichever environments use it, and shows for a period of your choice (24 hours, 7 days, 30 days, 90 days or 12 months):

| Figure | What it is |
| --- | --- |
| Up | How long the database was up, and which share of the period that is |
| Scaled to zero | How long a serverless database slept |
| Woke up | How often it went from zero to up |
| Scaled up to | The most vCPUs it was given; for a managed database, its node type |
| Storage | How large it is |
| Cost | Compute and storage together over the period, at the list price |

Next to the name it says where the database stands right now: up (with the vCPUs it has this moment), scaled to zero, or running for a managed database.

## One database

Click a database for its own page. It has:

- **The last 24 hours**, whatever period you look at: how long it was up, which share of the day that was, how often it woke and what the day cost.
- **The figures of the period**, including the average vCPU while it was up and what the compute alone cost.
- **Four charts** with a bar per hour (24 hours and 7 days) or per day (longer periods): up time, how far it scaled, storage and cost. Point at a bar, or give the chart focus and use the arrow keys, to read it.

## Download as CSV

On the page of one database, **Download the hours as CSV** gives a file with a line for every hour recorded in the period you chose. The columns are fixed, so a spreadsheet keeps reading them:

| Column | What it is |
| --- | --- |
| `hour_start`, `hour_end` | The hour, in UTC |
| `up_seconds`, `zero_seconds` | How long it was up and scaled to zero |
| `vcpu_seconds` | The vCPUs it was given, summed over every second it was up |
| `max_vcpu` | The most vCPUs it had in the hour |
| `wake_ups` | How often it went from zero to up |
| `storage_bytes` | Its largest size in the hour |
| `cost_cents` | What the hour cost, in euro cents, at the list price |

## Where the figures come from

**Serverless SQL Database.** Scaleway reports, minute by minute, how many vCPUs it gives a serverless database, and reports nothing for a minute in which the database is scaled to zero. That is also what it bills compute for. Once an hour Brewless counts, for every whole hour since the last count, how long the database was up, how long it slept, the vCPU time, the highest vCPU, how often it woke and its largest size, and keeps those totals. It never keeps the samples themselves.

Scaleway keeps its own figures for about a month. The first count therefore reaches back 30 days, and the totals Brewless keeps let you look back a year. The count runs at five past every hour; the hour that is still running is counted in the next one. Until the first count, a database shows where it stands right now and no figures.

Nothing is asked of the database to make these figures, so looking at this page never wakes it.

**Managed Database.** A managed node runs all the time and is billed for every hour, used or not. Its up time is the whole period since Brewless knew of it and its cost is the price of its node. Its size is counted once an hour too, as what is used of its volume, so its storage chart shows how it grew; the size shown next to its name is read live.

## Costs

The costs are estimates from Scaleway's list prices, before tax:

- compute: the vCPU time, at the price of a vCPU hour of Serverless SQL;
- storage: the size of every hour, at the price of a GB hour;
- a managed database: its node for every hour of the period, and its storage.

Your bill can differ by Scaleway's own metering and rounding. To compare a serverless database with a managed one, see [Database costs](/running/database-costs).

## A database that never sleeps

When a serverless database was up 90% or more of the last 24 hours, and at least 12 of those hours were recorded, the page says so above its figures. It gives what the database costs a month at that pace, and what the smallest Managed PostgreSQL node would cost with the same storage.

Usually a scheduler or a queue worker that runs every minute wakes it: a serverless database falls asleep only after five minutes without a query. Let it run less often, so the database can sleep, or move to a managed database. Brewless only says so; it changes nothing by itself.

## A standby copy in another zone

A Managed Database can have a standby copy: a read replica in another zone of the same region, kept up to date by Scaleway. Ask for one in `brewless.yml`:

```yaml brewless.yml
environments:
  production:
    database:
      name: shop-main
      standby: true
```

The next deploy asks Scaleway for the copy, on the database's Private Network when it is on one, and goes live without waiting for it; Scaleway makes it in a few minutes. `brewless plan` says what it costs: Scaleway bills the copy like a second database node, all the time. It is off unless you ask. A Serverless SQL Database has no standby copy: Scaleway keeps it available itself.

> [!NOTE]
> The high availability option of a Managed Database keeps its standby node in the same data center, on another rack. A standby copy from Brewless lives in another zone.

The page of the database shows the copy of each environment and whether Scaleway has it ready. When the database or its zone fails, switch to the copy there with **Switch to standby**, or with `brewless db:failover <environment>`. The console asks first and then follows the switch until it is done. Brewless never does this by itself. The switch:

1. makes the copy a database of its own (Scaleway names it `promoted - <name>`), with the same users and passwords;
2. points `DB_HOST` and `DB_PORT` at it, in a new revision of the variables;
3. lets the database before it go from the environment;
4. puts the live image live again with the new variables, as a new release.

Scaleway keeps the copy up to date a few seconds behind: what was written in the last seconds before the switch can be missing. The copy cannot be turned back into a copy. The database before it keeps running, and costing, at Scaleway until you remove it there; nothing is removed by the switch. Ask for a new standby copy of the new database in `brewless.yml` when you want one again. A switch needs the variables of the environment to be kept through Brewless.

`standby: false` lets the copy go from the environment; it keeps running at Scaleway until you remove it there.

## Maintenance

Scaleway restarts a Serverless SQL Database now and then for maintenance: by default on Tuesdays between 14:30 and 14:45 (Paris time), and it disconnects the clients for at most a minute. Larger operations are announced a week to a month ahead. With `brewless/laravel` 0.12 or later, a query whose connection went away is tried again for up to a minute, with growing pauses, so the requests and jobs of that minute wait instead of failing. A query inside a transaction is not tried again: what ran before it went with the connection. `BREWLESS_DB_RETRY_SECONDS` sets how long (`0` keeps Laravel's single try). Avoid that window for a release.

## Environments and sharing

The page of a database lists the environments that use it, and how each signs in: host, port, database and user, read live from the environment's variables. The password is never shown here; it is in the environment's variables in your own Secret Manager, and `brewless env:pull` shows it.

An owner or admin can **link** another environment to the database, also one of another application, as long as it runs in the same region. A database that no environment uses says so; it stays as it is until you link one or remove it at Scaleway.

Linking never lets one environment sign in as another. The environment gets a login of its own:

- **Managed Database.** A logical database and a user named after the application and the environment, such as `blog_staging`, with every right on that database and none on the others. The password is made once and kept in your Secret Manager; linking again gives the user that same password.
- **Serverless SQL Database.** An identity of its own (an IAM application) that may use the databases of the project the database is in. A Serverless SQL Database holds one database, so environments that share one also share its tables. This needs Brewless's Scaleway key to manage identities (`IAMManager`); without that right, linking says so and changes nothing.

Then `DB_CONNECTION`, `DB_HOST`, `DB_PORT`, `DB_DATABASE`, `DB_USERNAME` and `DB_PASSWORD` (and `DB_SSLMODE` for Serverless SQL) go into a new revision of the environment's variables. Its containers use them from the next deploy. Linking is written to the audit trail with the names of the variables, never their values.

**Unlinking** ends the link in Brewless only. Nothing at Scaleway is removed: the database, its data, the environment's login and its variables all stay.