Skip to main content

Managed Databases

Overview​

Managed Databases provides a Database-as-a-Service (DBaaS) platform. Deploy fully managed MySQL, MariaDB, or PostgreSQL databases with automated provisioning, health monitoring, metrics collection, read replicas, and hourly billing -- all without managing the underlying infrastructure.

Key capabilities:

  • Multiple engines -- MySQL, MariaDB, and PostgreSQL with configurable engine versions
  • VPC and public networking -- Deploy databases on a VPC subnet (private or public) or as a standalone public instance
  • Read replicas -- Create read-only replicas with automated replication, lag monitoring, promotion, and resync
  • Health monitoring -- Automated checks every 2 minutes with auto-recovery from transient errors
  • Metrics dashboard -- Real-time CPU, memory, disk, network, and engine-specific metrics
  • Parameter groups -- Custom configuration profiles that can be applied to any compatible database
  • Backup policies -- Automated backups with S3 storage and point-in-time recovery support
  • Hourly billing -- Credit-based billing with optional per-GB bandwidth charges
  • Per-user limits -- Configurable maximum number of managed databases per user (default: 5)

Admin Setup​

Prerequisites​

Before users can deploy managed databases, an administrator must:

  1. Prepare database images -- Upload OS images pre-configured with the database engine under Media > Images. Set the image purpose to Managed Database. The image name should match the engine (e.g., "MySQL") and version should match the engine version (e.g., "8.0").
  2. Create database plans -- Define resource plans (CPU, RAM, storage, bandwidth, pricing) under Databases > Database Plans.
  3. Create a plan group -- Organize plans into a plan group under Databases > Plan Groups and assign plans to it.
  4. Enable Managed Databases on a hypervisor group -- Link the plan group and configure pricing.
  5. (Optional) Configure metrics -- Set a metrics endpoint on the hypervisor group for metrics collection.
Multiple Engine Images

Multiple images can exist for different engine/version combinations. The system selects the most recently created matching image.

Enabling Managed Databases on a Hypervisor Group​

  1. Navigate to the Hypervisor Group settings page
  2. Enable the Managed Databases toggle
  3. Configure pricing:
    • Bandwidth Rate -- Per-GB traffic cost in credits
  4. Configure metrics in the shared Monitoring / Metrics card (shared between managed databases and load balancers):
    • Metrics Endpoint -- URL for collecting database and load balancer metrics
    • Metrics Auth Type -- Choose Bearer Token (single token) or Basic Auth (username and password)
    • Metrics Auth Credentials -- The token or username/password for authenticating with the metrics endpoint
  5. Link a DB Plan Group containing at least one enabled plan
  6. Save
Setting Up Metrics Collection with VictoriaMetrics

To display database metrics (CPU, memory, connections, QPS, etc.) on the dashboard, you need a metrics backend for each location. Here is the recommended setup using VictoriaMetrics and vmauth:

  1. Install VictoriaMetrics on a server accessible from the hypervisor group's network:

    • Download the latest single-node VictoriaMetrics binary from the official releases
    • Start VictoriaMetrics with: ./victoria-metrics-prod -storageDataPath=/var/lib/victoria-metrics -retentionPeriod=30d -httpListenAddr=:8428
    • VictoriaMetrics will accept writes on /api/v1/write and queries on /api/v1/query and /api/v1/query_range

  2. Install vmauth (VictoriaMetrics auth proxy) to secure access:

    • Download vmauth from the same releases page
    • Create a config file (/etc/vmauth/config.yml): 
      users:
        - bearer_token: "your-secure-token-here"
          url_prefix: "http://127.0.0.1:8428"
    • Start vmauth: ./vmauth -auth.config=/etc/vmauth/config.yml -httpListenAddr=:8427

  3. Configure the hypervisor group in the control panel:

    • Set Metrics Endpoint to http://<vmauth-host>:8427 (or use HTTPS with a reverse proxy)
    • Set Metrics Auth Type to Bearer Token and enter the token configured in vmauth (or use Basic Auth if your metrics proxy requires username/password authentication)

  4. Repeat per location -- Each hypervisor group (location) should have its own VictoriaMetrics + vmauth instance for optimal performance and data isolation.

Database Plans​

Plans define the resources allocated to each database and the billing parameters.

Key plan settings:

  • Name -- Display name
  • Engines -- Supported engines (e.g., MySQL, MariaDB, PostgreSQL)
  • CPU Cores, RAM, Storage -- Resource allocation
  • Bandwidth -- Monthly bandwidth in GB (0 = unlimited)
  • Credit Value -- Monthly base cost in credits
  • Bandwidth Rate -- Per-GB bandwidth cost in credits
  • Max Replicas -- Maximum number of read replicas (default: 2)
  • Bandwidth Accounting -- Which direction(s) to meter (uploads, downloads, or both)
  • Bandwidth Overage -- Overage policy (none, charge overage, or suspend network)

Plans also include advanced settings for CPU topology, storage I/O limits, and network rate limits.

User Limits​

The maximum number of managed databases per user is configured on the user profile:

  1. Navigate to Users > [User] > Edit
  2. Set Max Managed Databases (default: 5, set to 0 for unlimited)

User Guide​

Creating a Managed Database​

  1. Navigate to Databases in the sidebar
  2. Click Create Database
  3. Select a Database Engine (MySQL, MariaDB, or PostgreSQL)
  4. Select an Engine Version
  5. Select a Location (hypervisor group with managed databases enabled)
  6. Select a VPC and VPC Subnet (optional -- omit for a standalone public database)
  7. Select a Plan (determines CPU, RAM, storage, bandwidth, and pricing)
  8. Optionally set a Name (auto-generated if left blank)
  9. Click Create

The database enters Deploying status while it is being provisioned. Once initialization completes, the database transitions to Active. This typically takes 2--4 minutes.

VPC Mode for Replicas

If you plan to use read replicas, you must deploy the primary database in a VPC. Standalone public databases cannot have replicas.

Database Details​

Once deployed, the database detail page displays:

FieldDescription
NameUser-defined or auto-generated database name
StatusDeploying, Configuring, Active, Error, Suspended, or Destroying
EngineDatabase engine type and version (e.g., MySQL 8.0)
RolePrimary or Replica
HostVPC IP address and/or public IP address for connecting
PortDatabase listening port (3306 for MySQL/MariaDB, 5432 for PostgreSQL)
Admin UserDatabase admin username
Admin PasswordDatabase admin password (click to reveal, click to copy)
VPCAssociated VPC network (if deployed in VPC mode)
PlanCurrent database plan with resource details
Parameter GroupCurrently applied parameter group (if any)
Bandwidth UsedCurrent billing cycle bandwidth consumption
Replication StatusFor replicas: Syncing, Active, Error, or Stopped (tracks replication state independently of database status)
Replication LagFor replicas: seconds behind primary
Status vs. Replication Status

The database Status reflects whether the database service is running and healthy (e.g., Active, Error). The Replication Status independently tracks the state of replication between a replica and its primary (e.g., Syncing, Active). A replica can have an Active database status while its replication status is still Syncing during the initial data transfer.

Managing Databases​

Restart Database Service​

Restarts the database engine process without rebooting the server. Use this after applying parameter group changes or to recover from a stuck state.

Reset Admin Password​

Generates a new random password for the admin user and applies it to the running database. The new password is displayed once and stored securely.

Resize (Change Plan)​

Change the database to a different plan to adjust CPU, RAM, and storage resources.

Storage Downgrades Not Permitted

The new plan's storage must be equal to or greater than the current plan's storage. Storage downgrades are not supported.

Resizing updates the resource allocation and automatically adjusts engine tuning parameters (buffer pool size, shared buffers, etc.) to match the new resources.

Upgrade Engine Version​

Upgrade to a newer version of the same database engine (e.g., MySQL 8.0 to MySQL 8.4).

The upgrade process:

  1. Creates a pre-upgrade backup automatically
  2. Performs the in-place version upgrade
  3. Updates the engine version record on completion
Version Constraints

The target version must be higher than the current version, and a valid database image must exist for the target version.

Suspend and Resume​

Admins can suspend a database, which stops the service. Resuming restarts it and restores the database to Active status. Suspended databases do not incur hourly charges.

info

Users cannot suspend databases directly -- suspension happens through admin action or automated billing enforcement (negative credit balance).

Error Acknowledgement​

When a background operation fails (deploy, resync, backup, etc.), the error message is displayed as an alert banner. Users and admins can acknowledge the error to dismiss the banner. Errors are automatically cleared when the next operation succeeds.

Read Replicas​

Read replicas provide horizontal read scaling and data redundancy. Each replica replicates data from its primary database using native engine replication (MySQL/MariaDB binary log replication or PostgreSQL streaming replication).

Creating a Replica​

Requirements:

  • The primary database must be in Active status
  • The primary must be deployed in a VPC (replicas communicate over VPC networking)
  • The primary's plan defines a maximum replica limit (default: 2)
  • The replica plan's storage must be equal to or greater than the primary plan's storage

Steps (user or admin panel):

  1. On the primary database's detail page, locate the Replicas section
  2. Click Create Replica
  3. Select a VPC Subnet (must be in the same VPC as the primary)
  4. Select a Plan for the replica
  5. Optionally set a Name
  6. Click Create

The replica status progresses: Deploying -> Active (with replication status: Syncing -> Active).

tip

Replica deployment is two-phase: Phase 1 provisions the VM and initializes the database engine -- once this completes, the database status transitions to Active. Phase 2 configures replication from the primary, during which the replication status shows Syncing until the initial data transfer finishes. This separation means the database is reachable as soon as provisioning completes, while replication progress is tracked independently.

Replication Status​

StatusDescription
SyncingInitial data sync or resync in progress
ActiveReplication is running and healthy
ErrorReplication is broken -- check the error message
StoppedReplication was stopped (e.g., after promotion of another replica)

Replication Lag Monitoring​

Health checks run every 2 minutes and measure replication lag for each replica:

  • Under 5 minutes -- Normal operation
  • Over 5 minutes -- A warning badge appears on the index and detail pages
  • Replication broken -- Status transitions to Error with the failure detail
Auto-Recovery

Health checks automatically recover replicas whose replication status was not properly updated. If a health check confirms that a replica's replication is working correctly but the status has not yet transitioned, the system automatically updates it to Active.

Resyncing Replicas​

If a replica's replication breaks, use the resync action to re-establish replication from the primary.

  • Resync a single replica -- Click the Resync button on the specific replica row
  • Resync all replicas -- On the primary database's detail page, click Resync All Replicas
Smart Resync

When resyncing, the system avoids disrupting other replicas that are already actively replicating. Resync is available for any replica that is not currently deploying or syncing.

Post-Resync Health Check

After a successful resync, an automatic health check runs within 10 seconds to update the replication lag immediately, rather than waiting for the next scheduled 2-minute check.

Promoting a Replica​

Promotion converts a replica into a standalone primary. This is useful for planned failover or when the original primary needs to be decommissioned.

Steps:

  1. On the replica's detail page, click Promote to Primary
  2. Confirm the action

What happens:

  1. Replication is stopped on the replica and it is reconfigured as a standalone primary
  2. All other replicas of the original primary are re-pointed to the new primary with replication stopped
  3. The original primary is demoted to a replica of the new primary with replication stopped

After promotion, use Resync All Replicas on the new primary to re-establish replication for the re-pointed replicas.

Promotion Constraints

The replica must be in Active status with active replication. Replicas with stopped replication cannot be promoted -- resync first.

Parameter Groups​

Parameter groups are named collections of engine configuration overrides (e.g., MySQL/MariaDB my.cnf settings or PostgreSQL postgresql.conf settings).

Creating a Parameter Group​

User Panel​

  1. Navigate to Databases > Parameter Groups
  2. Click Create Parameter Group
  3. Enter a Name and select the Engine (MySQL, MariaDB, or PostgreSQL)
  4. Configure parameters using the provided catalog (parameters are filtered by engine and version)
  5. Click Create

Admin Panel​

Admins can manage parameter groups for any user under Databases > Parameter Groups.

Applying a Parameter Group​

  1. On the database detail page, select a parameter group from the dropdown
  2. Click Apply
  3. The configuration is applied to the database
  4. The engine is restarted with the new configuration
Engine Matching

The parameter group's engine must match the database's engine. Parameters are formatted with the appropriate units before being applied.

Backups and Point-in-Time Recovery​

Manual Backups​

Click Create Backup on the database detail page to trigger an on-demand backup.

Backup Policies​

Backup policies define automated backup schedules with S3-compatible storage. See the Database Backup Policies guide for full details on creating policies, scheduling, retention, and PITR configuration.

Point-in-Time Recovery (PITR)​

When PITR is enabled on a backup policy, the system continuously archives transaction logs to S3. This enables restoring a database to any point in time within the retention window.

Restoring to a point in time:

  1. On the database detail page, click Restore PITR
  2. Select the target date and time
  3. Click Restore
Data Overwrite

Point-in-time recovery overwrites the current database state. Any data written after the selected timestamp will be lost. Consider creating a manual backup before restoring.

Metrics​

The metrics dashboard is accessible from the database detail page and displays real-time performance data.

Common Metrics (All Engines)​

MetricDescription
CPU UsagePercentage of CPU utilization
Memory UsagePercentage of RAM utilization
Disk UsagePercentage of storage space used
Disk Read/Write IOPSDisk I/O operations per second
Network RX/TXNetwork throughput in KB/s

MySQL / MariaDB Metrics​

MetricDescription
ConnectionsActive client connections
Threads RunningThreads actively executing queries
Queries per SecondRate of all queries
Slow QueriesRate of queries exceeding the slow query threshold
Command BreakdownRate of SELECT, INSERT, UPDATE, DELETE operations
InnoDB Buffer Pool Hit RatePercentage of reads served from buffer pool
InnoDB Buffer Pool UsagePercentage of buffer pool pages containing data
InnoDB Row OperationsCombined rate of row reads, inserts, updates, deletes
InnoDB Data Read/WrittenData throughput in KB/s
Replication LagSeconds behind primary (replicas only)
Aborted ConnectionsRate of failed connection attempts
Table Locks WaitedRate of table lock waits

PostgreSQL Metrics​

MetricDescription
ConnectionsActive database connections
Transactions Committed/Rolled BackRate of committed and rolled back transactions
Queries per SecondCombined rate of all tuple operations
Tuple OperationsIndividual rates for returned, fetched, inserted, updated, deleted tuples
Cache Hit RatioPercentage of reads served from shared buffers
Database SizeTotal database size in MB
Live/Dead TuplesRow counts for vacuum monitoring
Temp Bytes WrittenTemporary file I/O rate
CheckpointsCheckpoint frequency and backend buffer writes
Deadlocks & ConflictsRate of deadlocks and replication conflicts
Replication LagBytes behind primary (replicas only)

Time Ranges​

The metrics page supports selectable time ranges: 1 minute, 5 minutes, 10 minutes, 30 minutes, 1 hour, 6 hours, 12 hours, 1 day, 3 days, 7 days, and 30 days.

Billing​

Managed databases use the Cloud Service hourly billing system, identical to other managed services (NAT gateways, load balancers, VPN gateways).

Hourly Cost​

The hourly base cost is derived from the database plan's credit value divided by the number of hours in the month. Credits are deducted automatically each billing cycle.

Bandwidth​

Bandwidth is tracked per database and billed per GB based on the plan settings.

SettingOptionsDescription
Bandwidth AccountingUploads, Downloads, BothWhich direction(s) count toward bandwidth usage
Bandwidth OverageNone, Charge Overage, Suspend NetworkWhat happens when bandwidth limit is exceeded
  • None -- No bandwidth limit; no overage charges
  • Charge Overage -- Charge per-GB for bandwidth above the plan limit
  • Suspend Network -- Suspend the database's network when bandwidth is exceeded; auto-resume when bandwidth resets

Deletion Billing​

When a database is deleted, any remaining unbilled hours for the current period are charged before the database is removed.

Usage Reports​

Managed database usage appears in the Cloud Service > Usage Report under a dedicated Managed Databases section, showing database name, engine, hours active, base credit charges, and bandwidth charges.

Retry Failed Deployments​

If a database deployment fails (status shows Error), a Retry Deploy button appears on both the detail page and the index list. Retrying rebuilds the database from scratch using the same plan, engine, and configuration -- preserving the database name and credentials.

info

For replicas, the replication setup is automatically re-triggered after initialization.

Deleting a Managed Database​

To delete a database, click Delete on the detail page or use the delete action on the index list.

Deleting a database:

  1. Bills any remaining hours for the current billing period
  2. Releases all associated resources (public IP, storage)
  3. Removes the database record
Deleting a Primary with Replicas

A primary database with active replicas cannot be deleted. You must destroy all replicas first, or promote a replica to primary before deleting the original.

Troubleshooting​

Database stuck in "Deploying"​

  1. Check the task status on the admin dashboard for error details
  2. Verify the hypervisor has sufficient resources (RAM, storage, public IPs)
  3. Verify a managed database image exists and is enabled for the selected engine and version
  4. Use the Retry Deploy button to rebuild from scratch if the database is stuck

Replica stuck in "Syncing"​

  1. Verify the primary database is in Active status
  2. Ensure the VPC subnets allow traffic between primary and replica
  3. Use the Resync button on the replica to retry

Replication lag is high​

  1. Check the primary database's resource utilization (CPU, disk I/O) -- it may be overloaded
  2. Verify network connectivity between primary and replica
  3. Consider upgrading the replica to a higher plan with more CPU and RAM

Cannot create replica: "Primary database must be in a VPC"​

Replicas require VPC networking for private communication. If the primary was deployed as a standalone public database, it cannot have replicas. Recreate the primary in a VPC to enable replica support.

Cannot delete primary: "Cannot destroy a primary database that has replicas"​

All replicas must be deleted before the primary can be destroyed. Alternatively, promote a replica to primary first, then delete the demoted original.

Metrics not showing​

  1. Verify the hypervisor group has a metrics endpoint configured
  2. Verify the metrics endpoint is reachable from the hypervisor group's network
  3. Contact your administrator if the issue persists

Parameter group changes not taking effect​

  1. Verify the parameter group's engine matches the database's engine
  2. Some parameters require a database restart to take effect -- use the Restart action after applying