Dev and QA
Databases for development, testing, and temporary environments that the team needs only during active work periods.
First serverless PostgreSQL in RussiaInfrastructure in Yandex Cloud
PostgreSQL for dev/test and temporary environments without paying for idle runtime
SPG99 is a managed PostgreSQL platform for test, preview/staging, and internal services with uneven load. When the database is not in use, the active worker stops automatically. On the first request, the database starts on its own and works like regular PostgreSQL.
- Standard PostgreSQL drivers
- Standard connection string
- TLS
- Console and API
Best fit
Best where the database is not needed around the clock
SPG99 is especially valuable where the database is needed only during specific working periods rather than continuously.
Preview / staging
Databases for branches, pull requests, demos, and pre-production that should not stay on all day without use.
Internal services and background jobs
Admin tools, ETL, schedules, and internal services with traffic spikes instead of steady demand.
If the database is busy almost continuously 24/7, the economic effect will be lower.
Impact
What the team and the business get
SPG99 lowers PostgreSQL cost for dev/test, preview, and temporary environments without forcing applications into a separate serverless mode.
Savings without manual shutdowns
Do not pay for nights, weekends, and hours when the database is not needed.
Reliability without one-machine dependency
Database state is stored separately, so stopping or recreating the active worker does not mean data loss.
Fast wake-up after a pause
After a pause, the database typically returns to work in under 2.5 seconds.
New databases without manual preparation
Create a database in the console and get a ready connection string for the application immediately.
SPG99 pilots
What five pilot scenarios already proved
Five teams across fintech, telecom, retail, edtech, and logistics have already modeled their dev/test workloads. In every case, the pilot confirmed the same thing: QA, preview, and staging environments can stay isolated while the monthly bill drops materially.
59-88% lower monthly bill
One environment set, two bills
The same dev/test environment set costs materially less on SPG99 than under a standard 24/7 model. The team keeps separate databases and sees the monthly savings immediately.
Managed PostgreSQL 24/7SPG99 usage-based billing
Fintech4 environmentsIdle 54%
Anti-fraud sandbox and release QA
Managed PostgreSQL 24/7
32,983 ₽/moSPG99 usage-based billing
13,523 ₽/mo19,460 ₽/moSavings 59%
Telecom6 environmentsIdle 61%
Billing, subscriber profile, and integration tests
Managed PostgreSQL 24/7
37,284 ₽/moSPG99 usage-based billing
12,304 ₽/mo24,980 ₽/moSavings 67%
Retail8 environmentsIdle 66%
Checkout, catalog, and promo preview
Managed PostgreSQL 24/7
43,320 ₽/moSPG99 usage-based billing
11,263 ₽/mo32,057 ₽/moSavings 74%
Edtech10 environmentsIdle 72%
Ingestion, reporting, and demo stacks
Managed PostgreSQL 24/7
59,136 ₽/moSPG99 usage-based billing
11,236 ₽/mo47,900 ₽/moSavings 81%
Logistics13 environmentsIdle 79%
Routing, staging, and partner APIs
Managed PostgreSQL 24/7
70,909 ₽/moSPG99 usage-based billing
8,509 ₽/mo62,400 ₽/moSavings 88%
The comparison uses the same number of environments and the same storage footprint. The only thing that changes is compute behavior: always-on in Managed 24/7 versus usage-based billing in SPG99.
What the pilot proves in practice
The pilot gives more than a headline percentage. It shows how many separate dev/test environments you can keep and what the monthly bill looks like without paying for idle compute.
Typical case
74%
8 separate environments for checkout, catalog, and promo preview · 32,057 ₽/mo
Environments in 5 pilots
41
QA, preview, staging, and integration databases
Validated savings
186,797 ₽/mo
per month across all five pilots
We can model your case too
We can build the same model for your environments
We break your dev/test, preview, and temporary databases down by environment, compare the 24/7 bill against usage-based billing, and show exactly where the savings are real. If the model works, we move straight into a free pilot.
Scenarios where the savings are already validated:
Fintech
Anti-fraud sandbox and release QA
The team keeps separate databases for anti-fraud rules, sandbox checks, and pre-release regression. The pilot showed that all 4 environments can stay isolated while billing only for active hours.
Environments
4 environments
Idle
54%
Savings
59%
Cost in SPG99
13.5k ₽
Telecom
Billing, subscriber profile, and integration tests
Most of the load lands in release windows and integration checks. Usage-based billing removes the always-on bill for 6 QA and preview databases between releases without forcing the team back into one shared setup.
Environments
6 environments
Idle
61%
Savings
67%
Cost in SPG99
12.3k ₽
Retail
Checkout, catalog, and promo preview
Checkout, catalog, and promo mechanics all keep their own preview and nightly QA databases. The pilot confirmed that 8 environments can stay separate while the monthly bill drops sharply.
Environments
8 environments
Idle
66%
Savings
74%
Cost in SPG99
11.3k ₽
Edtech
Ingestion, reporting, and demo stacks
These databases are needed in bursts: during business hours, on weekdays, and around content-preparation waves. The no-idle billing model removes nights and long idle windows from the bill across 10 dev/test environments.
Environments
10 environments
Idle
72%
Savings
81%
Cost in SPG99
11.2k ₽
Logistics
Routing, staging, and partner APIs
Routing and partner integrations wake databases up in waves. The pilot showed that 13 separate environments can stay ready to launch without paying for round-the-clock compute.
Environments
13 environments
Idle
79%
Savings
88%
Cost in SPG99
8.5k ₽
How it works
Three steps instead of manual administration
Teams create a database, connect with a normal PostgreSQL DSN, and get auto-start compute without operating every temporary environment by hand.
1. Create a database in the console
The platform prepares the environment and gives you access settings without manual virtual machine setup.
2. Connect with a regular PostgreSQL DSN
Standard connection string, familiar drivers, and TLS. The application does not need a proprietary API rewrite.
3. The database stops without connections and starts on first access
When the database is not needed, the active worker does not burn budget. When it is needed again, the platform starts it automatically.
SPG99 vs Managed PostgreSQL 24/7
Don’t pay for idle time: SPG99 vs Managed PostgreSQL 24/7
If the database follows working-hour windows, running it on Managed PostgreSQL 24/7 is overpayment by default. SPG99 is built specifically for these scenarios.
Managed PostgreSQL 24/7
- You pay for a running instance even when the database is idle.
- Billing runs 24/7, not only during the team’s working hours.
- Nights, weekends, and idle time keep burning budget.
- Each new dev/test or preview environment increases fixed spend.
- Because of the cost, teams cut the number of isolated environments and slow delivery.
SPG99
- You pay for database usage, not for waiting.
- Spend follows real work, not the mere fact that the server is on.
- No activity means no pointless billing for the active instance.
- Dev/test, preview, and temporary databases can be kept at scale without a permanent burn rate.
- A new database is created in the console and is immediately ready to connect.
FAQ
Frequently asked questions
Short answers to the main questions about cold start, standard DSN behavior, data durability, and the scenarios where serverless PostgreSQL fits best.
Do we need to change the application?
No. After startup it is regular PostgreSQL: standard drivers, a standard connection string, and TLS.
What about latency after idle?
The database usually starts in under 2.5 seconds. In rare cases it can take longer, so the application should use retries and a reasonable connect_timeout.
Can data be lost while the database is stopped?
No. Durable database state is stored separately from the active worker, so stopping the worker does not mean losing data.
Where is the data hosted?
In Russia, on Yandex Cloud infrastructure.
Which scenarios fit SPG99 best?
Dev/test, preview/staging, internal services, and other environments with uneven load. If the database is needed almost constantly, the economic effect will be lower.
Is SPG99 suitable for production workloads?
SPG99 is primarily built for dev/test, preview/staging, internal services, and other scenarios with uneven load. If the database runs almost continuously 24/7 and is highly sensitive to the lowest possible delay on the first connection after idle, that scenario should be evaluated separately against your workload.
Reduce dev/test PostgreSQL spend without risk: start with a free pilot
We will show the service, provide a free pilot, and support your team at every stage. We will help you quickly verify whether SPG99 fits your test, preview, or internal environments and calculate the effect on real usage.