Running your application
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.
On this page
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.
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.
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. 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.