SPG99 webinar announcement about serverless PostgreSQL for dev/test, preview, and internal services — The webinar shows serverless PostgreSQL in live operation: from the first psql connection to auto-stop and a controlled writer-profile handoff.

Why this webinar matters now

Serverless PostgreSQL is still a new model for the Russian market, and almost every discussion about it runs into the same practical questions:

does the application need to change;
what happens to the database after an idle period;
is any data lost when compute stops;
can teams really reduce spend on temporary environments without turning operations into a manual ritual.

This first SPG99 webinar is designed to answer those questions without abstractions. The goal is simple: show what the model looks like in real operations for dev/test, preview / staging, and internal services where a significant share of time is pure idle.

Date: April 15 at 11:00

Webinar format

This is not a theoretical cloud discussion and not an interface tour for its own sake. The center of the session is the real user path and the actual lifecycle behavior of the database.

What we will cover without magic

The webinar will walk through what serverless PostgreSQL means in practical rather than marketing terms:

the application still sees a regular PostgreSQL DSN;
auto-start happens on the first connection;
auto-stop happens after idle;
durable state lives outside compute, so stopping the worker is not the same as losing data;
in practice the application usually needs standard PostgreSQL drivers, TLS, a sensible connect_timeout, retry on the first post-idle connection, and sane pooling rules.

A dedicated part of the session will explain why wake-up should be treated as a normal operational phase rather than as a surprise. If the application already follows normal engineering discipline, wake-up becomes part of the database lifecycle instead of a special proprietary mode.

Core principle

Stopping compute does not mean losing state. In serverless PostgreSQL, that separation between worker lifecycle and data durability is foundational.

Live demo: from Console to idle and stop

Live during the webinar, SPG99 will show the full user path without skipping steps:

create a tenant and a new database in Console;
get a ready-to-use DSN;
connect through psql;
observe the stopped -> booting -> ready path;
inspect metrics, logs, and action history;
then let the database return to idle and stop automatically.

This part will also explain why dev/test, preview environments for branches and pull requests, demo environments, ETL jobs, admin tools, and internal services with bursty traffic almost always overpay for 24/7 compute when real activity only exists during work hours, release windows, or isolated spikes.

The path that will be shown live

Console -> create tenant -> create database -> get DSN -> psql connect
-> stopped -> booting -> ready -> workload
-> idle timeout -> idle -> stopped

Live autoscaler demo: controlled writer handoff

A separate block will focus on the new autoscaler, runtime-level fields, and a safe handoff between writer profiles. Using the transition between L1 and L2, SPG99 will show how the platform prepares a new writer generation and why it avoids the risky idea of hot live-resizing an already running pod.

The webinar will also explain how to read the runtime fields in real operation:

Runtime fields covered on the demo

current_profile
target_profile
candidate_profile
scale_state
freeze_new_checkouts

Why this matters

Writer scaling in SPG99 is built as a safe generation switch with a controlled handoff, not as an attempt to stretch a live pod under production load.

Where the model pays off most, and where it needs separate validation

The practical focus of the webinar will stay on the scenarios where a serverless model most often makes economic sense:

dev/test environments;
preview / staging for branches and pull requests;
demo environments;
ETL jobs with explicit activity windows;
admin tools and internal services with bursty traffic.

The session will also draw the applicability boundary honestly. If a database behaves as a true 24/7 workload and is highly sensitive to the latency of the first request after a pause, that scenario should not be justified by the simple promise of “not paying for idle”. It needs a dedicated validation against the actual workload profile, first-request latency, and warm-state expectations.

Applicability boundary

A serverless model is not automatically universal for every PostgreSQL workload. The webinar will show where it brings the strongest upside and where a pilot plus workload-based validation should come first.

Who should join and what participants will take away

This webinar is especially relevant for:

CTOs;
platform / DevOps / SRE teams;
backend engineers;
QA leads;
product teams that operate several temporary PostgreSQL environments with a visible share of idle time.

The final block will show how to validate a specific case through a pilot, what to count in the economics of temporary environments, and which questions should be clarified before the first launch.

After the webinar, participants should leave with two practical answers:

whether a serverless model fits their case at all;
what that model looks like in real SPG99 operations rather than in a marketing promise.

Serverless PostgreSQL for dev/test and preview: where the model pays off most

Temporary databases rarely need round-the-clock compute, yet traditional managed PostgreSQL keeps billing as if demand were constant. A serverless model wins when teams want to keep a normal DSN while removing idle-hours spend.

6 min readOpen →

Operations and scenariosMarch 18, 2026

Database lifecycle in SPG99: active, idle, wake-up

To make a serverless model operationally friendly, teams need to understand not only the savings but also the states themselves. In SPG99, it is usually enough to think in three modes: active, idle, and wake-up.

5 min readOpen →

SPG99 webinar: PostgreSQL without paying for idle in dev/test, preview, and internal services