Your connection is ready
Bind the database to an app. DATABASE_URL is added to its environment automatically.
MANAGED POSTGRESQL
Write your app.We'll run the database.
PostgreSQL next to your application. Automatic connection, scheduled backups and monitoring — without installing and maintaining the database yourself.
PostgreSQL is the managed engine. Other databases run in containers on App Servers.
HOW IT FITS TOGETHER
Backups you can take with you
Choose an hourly or daily schedule and 7, 14 or 30 days of retention. Download copies from the console.
Room to grow
Change instance resources without moving data manually. Your app keeps the same connection string.
GET STARTED
Ready for your first query.
- 01
Create PostgreSQL
Choose a project, instance size and disk space. The database runs on the platform's infrastructure in Russia.
- 02
Set up backups
Select a schedule and retention period at creation time. Copies are stored separately, in object storage.
- 03
Connect your application
Select the database in your app settings. DATABASE_URL arrives automatically; connections and resource usage are visible in the console.
You own the data. We handle operations.
Backups, schema restore, monitoring and access in the same project as your app.
Restore by schema
You can restore a single schema, not only the whole instance — which is what you actually need when a bad migration hit one part of the data while everything else keeps serving.
Performance monitoring
Connection, query and load metrics in real time, in the same panel as the application. There is no exporter or dashboard to set up, and history is kept alongside the service metrics.
Secure access
The database is reachable by the app over the internal network rather than a public address. Access follows project roles, connections are encrypted, and the password never has to be passed around between developers by hand.
Before you migrate
One engine: PostgreSQL
MySQL, MongoDB, ClickHouse and Redis are not available as managed resources. They run as containers on your own server and are handled from the same console, but then backups and upgrades are on your side.
No superuser
You get ownership of your own database: schemas, tables, roles, extensions from the supported list. Cluster-level operations that would break the neighbours or the instance itself are closed.
Public access is a deliberate act
By default the database only listens on the project's internal network. Connecting from a laptop client without enabling external access will not work, and that is on purpose.
Restore is not instant
A copy is pulled back from object storage, and on a large database that takes time. Restoring a single schema is usually faster than the whole instance, but it is not instant either.
No read replicas yet
There is one instance. Scaling is vertical — resources change in place with no data migration. If you need geographically distributed replication, that case belongs on your own server.
Database FAQ
Which databases are available as managed?
The managed engine is PostgreSQL. It's created next to your application and the DATABASE_URL connection string is injected into the service automatically. MySQL and Redis run on your own server (App Server), not as a managed resource.
Do I have to build the connection string by hand?
No. When you create the database you bind it to an application, and DATABASE_URL shows up in the service's environment variables on its own — no DSN to assemble manually.
Are there backups?
Yes. Backups are enabled when you create the database: you pick a schedule (hourly or daily) and a retention window — 7, 14 or 30 days.
Can I resize the database without a migration?
Yes. Instance resources change without manual data migration — the app keeps using the same connection string.
More questions
Can I download a backup?
Yes. Backups are written to object storage and the panel issues a temporary download link. The copy stays with you even if the instance is later deleted.
What if a bad migration broke a single schema?
Restore works per schema, not only for the whole instance. That is exactly what schema-level restore is for: the rest of the data keeps serving while the damaged part is restored.
Is the database reachable from the internet?
Not by default: the app talks to it over the project's internal network. Public access is a deliberate decision, not the default state.
What about 152-FZ?
Instances run on servers in Russia, so the primary processing of Russian users' personal data happens inside the country. That is usually the reason teams move off foreign managed databases.