Database capacity

A Serverless SQL Database scales between two bounds: a minimum and a maximum number of vCPUs. Brewless makes it with a minimum of 0 and a maximum of 4, so it sleeps and costs nothing while nobody asks it anything.

Scaleway scales it up as the load grows, but from a low minimum that takes longer than a peak of a few minutes lasts: a ticket sale that opens at 10:00, a mailing, a large import. A boost raises the bounds for a while, and gives them back afterwards:

• Now: from this moment, for a number of minutes.
• Planned: for a window, such as 10:00 to 12:00. It starts warming up before the window (15 minutes unless you say otherwise), so the database has its minimum when the window opens, and cools down after it (30 minutes unless you say otherwise) before it goes back to normal.

A database works without a boost too. A boost only raises: below the normal bounds, the normal bounds hold.

In the console#

Open Databases, then the database. A Serverless SQL Database has a Capacity card:

While Scaleway is still on its way to a new minimum, the card says so: "4 vCPU asked, 2 given so far". These figures come from Scaleway's API. Brewless never sends a query to the database to measure it; that would keep it awake.

Owners and admins can:

• Boost now, with a minimum, a maximum and a number of minutes;
• Plan a boost, with a start, an end, and the minutes to warm up and cool down;
• Change a planned boost until it starts warming up, Extend a running one to a later end, and Cancel either;
• Configure capacity: the normal bounds.

Before a boost is sent, the dialog shows what it costs at Scaleway (see Costs). Each change is a run of its own; the card follows it until it is done. Members see the card but cannot change anything.

When a boost is ready#

A boost is ready once Scaleway gives the database at least the boost's minimum. Brewless reads that from Scaleway, every few seconds while it waits, and notes the moment.

The minimum has to be there by the start of the window. A boost that starts now, or has less than five minutes to warm up, has five minutes from the moment its window opens. When the minimum is not there in time, the boost is Minimum not reached in time. It still holds: Brewless keeps asking Scaleway for it, looks again at each of its moments and every hour, and the boost becomes Running as soon as the minimum is there.

The phases of a boost:

On time, while Brewless sleeps#

Brewless works on the minute of each moment of a boost: the start of warming up, the start, the end and the end of cooling down. Once an hour it puts the moments of the next 75 minutes on its queue, each delayed to its own minute, and a boost made or changed less than 75 minutes ahead has its moments put there at once. A moment is usually handled within a minute. Warming up is there to take up that minute, and the time Scaleway needs.

A moment that was missed, because a worker was down, is taken in at the next hourly look.

Overlapping boosts#

Two boosts at the same time give the database the highest minimum and the highest maximum of the two. The end of one lowers nothing while the other still runs. What the database should have is worked out from the boosts every time, so boosts can never put each other back.

A shared database#

A database that several environments use has one set of boosts. A boost holds for every environment that uses it; the card says so.

Who may boost#

Boosts come with the Business plan and up. On every plan, owners and admins can set the normal bounds. On Solo and without a plan the card shows the capacity, with the buttons for boosts switched off.

When an organisation changes to a plan without boosts, a boost that is running or planned runs its course and can be cancelled. A new boost, a change or an extension is refused.

What Scaleway does when the capacity changes#

Brewless only changes the two bounds at Scaleway. It never restarts the database itself, never makes a new one, and leaves open connections alone. What Scaleway then does, as Brewless measured it:

• A sleeping database wakes up when its minimum goes above 0, without a query: it was up within four seconds and had its new minimum within six.
• A small raise (from 0 or 1 to 4 vCPU, or within what it ran on before) took five to seven seconds, and open connections and queries went on as normal.
• A large raise can restart the database. Going from 4 to 8 vCPU, and from 6 to 15, Scaleway moved the database: open connections were closed (Database took more than 1m0s to start, please retry later), its status was error for a while, and it was out of reach for 96 to 110 seconds before it had its new capacity.
• Going down never restarted it. Open connections stayed, and an idle database at 0 fell asleep right away.

So plan a boost before a peak, with time to warm up: a restart then happens before the peak, not during it. Queries can be slower while the database scales. Brewless does not promise a change without downtime.

Changed at Scaleway outside Brewless#

When the bounds of the database are changed in the Scaleway console:

• During a boost, Brewless puts the boost back and notes it in the audit trail.
• Going back to normal, Brewless leaves the bounds as they are. The boost ends, the environment shows a drift notice, and the card offers two choices: Keep it as the normal capacity, or Put back to the normal capacity.

When going back to normal fails#

A database that keeps a boost keeps costing it. When Scaleway refuses or cannot be reached, Brewless tries five times over a few minutes. If that does not get through:

• the card says so, with what Scaleway said;
• the owners and admins get a mail;
• Brewless tries again every hour, and mails at most once a day while the database stays up.

Detaching and ending#

Before an environment is detached, the boosts it asked for end. A database only that environment uses gets its normal bounds back first; when Scaleway cannot be reached for that, the detach is refused and nothing is let go. A database it shares keeps the boosts of the other environments.

When an organisation ends, every database Brewless boosted gets its normal bounds back before Brewless lets go of the keys.

The command line#

brewless db:capacity, db:boost, db:boost:extend and db:boost:cancel do the same from a terminal or a pipeline. A pipeline token may boost the databases of its own application only, within the limits of the environment's capacity key, boost hours a month included: a token that leaks cannot raise the bill further than the application itself could. See Commands.

In brewless.yml#

The normal bounds can be in brewless.yml instead of the console:

environments:
  production:
    database:
      name: shop-main
      min_vcpu: 0
      max_vcpu: 8

A deploy sets them. A boost that runs stays on top of them, so a deploy never ends a boost. While the file sets them, the console does not; leave them out of the file to set them in the console again. brewless plan shows the change, and what a minimum of 1 or more costs a month. See brewless.yml.

The application itself#

An application can plan its own boosts, before a sale it knows of, with the capacity key of its environment. See Capacity API.

Limits#

Costs#

Scaleway bills a Serverless SQL Database at least its minimum while it holds it. A boost of 4 to 15 vCPU from 10:00 to 12:00, with 15 minutes to warm up and 30 to cool down, holds capacity for 165 minutes: at least 4 vCPU and at most 15 for that time. The console and the API show that as two amounts before you send it. See Database costs.

A normal minimum of 1 vCPU or more keeps the database awake all month; the console says what that costs when you set it.