Boost a Serverless SQL database before a ticket sale

A ticket shop is quiet for days and then gets everyone at once, the minute a sale opens. On a Scaleway Serverless SQL Database that is exactly the moment the database is least ready for: it scales up as the load grows, but from a low minimum that takes longer than the first rush lasts.

This post explains why, how a planned capacity boost in Brewless warms the database up before the sale and gives the capacity back after it, what we measured at Scaleway while building it, and what it costs.

Why is a serverless database slow at the start of a sale?#

Because it starts from its minimum. A Serverless SQL Database scales between 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 for compute while nobody asks it anything. When the sale opens, it first wakes, then grows step by step with the load, and the first minutes run on too little.

Keeping the minimum high all the time solves that, but a minimum of 1 vCPU or more keeps the database awake all month, and Scaleway bills that minimum for every hour.

What does a capacity boost do?#

A boost raises both bounds for a window and gives them back afterwards:

For a sale at 10:00 until 12:00, a boost of 4 to 15 vCPU warms up from 09:45 and gives the capacity back at 12:30. A boost only raises: below the normal bounds, the normal bounds hold. Two boosts at the same time give the highest of each.

Brewless works on the minute of each moment, from its own queue, so nothing has to stay awake to wait for 09:45. The boost is ready once Scaleway reports the minimum for the database, read from Scaleway's API and never from a query on the database itself.

What did we measure at Scaleway?#

We changed the bounds of a Serverless SQL Database through the API, with and without an open connection that ran a query every half second:

• A sleeping database woke up when its minimum went above 0, without any query: up within four seconds, at its new minimum within six.
• From 0 or 1 to 4 vCPU took about five seconds; the open connection and its queries went on as normal.
• From 4 to 8 and from 6 to 15 vCPU, Scaleway moved the database: the connection was closed, the status was error for a while, and it was out of reach for 96 to 110 seconds.
• Going down never restarted it.

Warning

A large raise can restart the database. That is why a boost warms up before the window: the restart happens at 09:45, not at 10:00.

In our end-to-end test the boost was planned for 15:13 with 15 minutes to warm up. The bounds changed at 14:58:01, the database had its minimum at 14:58:16, and it went back to normal at 15:28:01, then fell asleep.

How does a Laravel app plan its own boost?#

With the capacity key of its environment, switched on by an owner or admin in the console, and the CapacityClient of the brewless/laravel package. A shop plans a boost when an event with a sale is saved:

use Brewless\Laravel\Capacity\CapacityApi;
use Brewless\Laravel\Capacity\CapacityException;

public function saved(Event $event): void
{
    try {
        resolve(CapacityApi::class)->schedule(
            "event-{$event->id}-sale",
            $event->sale_starts_at,
            $event->sale_starts_at->addHours(2),
            min: 4,
            max: 15,
            prewarm: 15,
            cooldown: 30,
        );
    } catch (CapacityException $exception) {
        report($exception);
    }
}

The key makes the call safe to send again. When the sale moves, the same key with new times changes the boost; when the event is cancelled, cancel() calls it off. The application never gets a Scaleway key, reaches only its own environment's databases, and keeps to limits the owner sets, such as boost hours a month. See Capacity API.

Treat a boost as a help: when Brewless cannot be reached, catch the exception and go on. The database keeps scaling between its normal bounds as always.

What does a boost cost?#

Scaleway bills a Serverless SQL Database at least its minimum for as long as it holds it. Before you plan a boost, the console, the command line and the API show two amounts for the whole time it holds capacity, warming up and cooling down included: at least its minimum, at most its maximum.

Those are Scaleway's list prices, before tax; the real amount depends on the load. A minimum of 1 vCPU kept all month costs about € 100 at the same price. See Database costs.

Where else can you start a boost?#

In the console, on the page of the database: Boost now for a mailing that goes out in a minute, or Plan a boost for a window. From a terminal or a pipeline, brewless db:boost production --min=4 --max=15 --for=2h does the same, and a pipeline token keeps to the limits of the environment's capacity key. Boosts come with the Business plan and up. See Database capacity.