Configuring VK Cloud Managed Databases for High Load and HA
A team launched PostgreSQL on VK Cloud with default settings — a week later, the database crashed under load. This happens often: the defaults of Managed services are designed for minimal resources, but production requires fine-tuning. We encounter these cases regularly and know how to prevent them. Our experience with VK Cloud spans 5+ years, with over 50 successful projects in database configuration and migration.
Why Default Managed Databases Settings Kill Performance?
VK Cloud Managed Databases supports PostgreSQL, MySQL, Redis, ClickHouse, MongoDB, OpenSearch. Managed services handle replication, automatic failover, backups, and basic metric monitoring. But 'managed' doesn't mean 'no configuration needed' — instance settings, database parameters, network access, and backup policies require attention. Without adjustment, you face up to 50% performance loss. For example, PostgreSQL with defaults on an 8 vCPU / 32 GB RAM instance will use only 256 MB of shared_buffers. This causes frequent disk reads and increased latency. We tune 50+ parameters to match your workload.
According to VK Cloud documentation, the managed service automatically manages replication and backup, but does not optimize DBMS parameters. So manual tuning is essential for performance.
How We Configure PostgreSQL for Production on VK Cloud
We use Terraform with the vkcs provider for declarative management. Example cluster resource with a replica:
data "vkcs_db_config_group" "pg16_tuned" {
name = "pg16-production"
}
resource "vkcs_db_cluster" "postgres" {
name = "prod-postgres"
datastore {
type = "postgresql"
version = "16"
}
cluster_size = 2 # primary + 1 replica
flavor_id = data.vkcs_compute_flavor.db_medium.id
volume_size = 100
volume_type = "ceph-ssd"
availability_zone = "MS1"
network {
uuid = vkcs_networking_network.app.id
}
configuration_id = data.vkcs_db_config_group.pg16_tuned.id
capabilities {
name = "node_exporter"
}
}PostgreSQL parameters are set via Configuration Group. For production, these are essential:
max_connections = 200
shared_buffers = 25% of RAM
effective_cache_size = 75% of RAM
work_mem = 4MB-16MB (depends on queries)
maintenance_work_mem = 256MB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1 # for SSDWithout these, PostgreSQL uses defaults designed for 256 MB RAM — performance will be poor even on a powerful instance.
Case Study: Migration from Self-Managed Infrastructure
A client had PostgreSQL on a virtual machine with manual backups. We migrated a 500 GB database to a VK Cloud Managed cluster. We configured replication, parameters for 5000 queries/s, monitoring via Prometheus and alerting. As a result, uptime rose to 99.95%, and response time decreased by 40%. The client saves 30% of time on administration.
How to Configure Network Access and Security?
By default, a Managed Database is accessible only within the same VK Cloud network. For external access — use a floating IP or configure allowed addresses:
openstack security group rule create \
--ingress --protocol tcp \
--dst-port 5432 \
--remote-ip <your_ip>/32 \
<db_security_group_id>Opening PostgreSQL directly to the internet is only recommended with TLS and an explicit allowed IP list. Better to use a bastion or VPN. We also configure NetworkPolicy for Kubernetes connections.
Backups and Point-in-Time Recovery
VK Cloud performs automatic backups on a schedule. We configure retention and timing:
resource "vkcs_db_backup" "postgres_manual" {
name = "before-migration"
dbms_id = vkcs_db_cluster.postgres.id
}Point-in-time recovery for PostgreSQL is available via the VK Cloud console — restore to a specific moment in time. This requires WAL archiving, which VK Cloud enables automatically when backups are present. We configure daily full backups and WAL archiving every 5 minutes. This allows recovery to any minute within the retention period (usually 30 days).
Redis: Configuration and Operation Modes
For caching — a single Redis instance with persistence. For production requiring HA — a cluster with a replica:
resource "vkcs_db_cluster" "redis" {
name = "prod-redis"
datastore {
type = "redis"
version = "7"
}
cluster_size = 2 # master + replica
flavor_id = data.vkcs_compute_flavor.cache_small.id
volume_size = 10
volume_type = "ceph-ssd"
network {
uuid = vkcs_networking_network.app.id
}
}For Redis, it is crucial to configure maxmemory and maxmemory-policy — without them, when memory fills, Redis will refuse writes or behave unpredictably.
ClickHouse for Analytics
ClickHouse on VK Cloud is a good choice for analytical tasks when there is a lot of data and fast aggregations are needed. Managed ClickHouse removes the headache of sharding and replication. Connect via the standard ClickHouse client or HTTP interface. VK Cloud provides an endpoint with TLS.
Monitoring and Observability
When creating instances, we enable capabilities { name = "node_exporter" } — this deploys node_exporter on the database host. Connect to Prometheus via ServiceMonitor or static configuration. For PostgreSQL, we also add postgres_exporter. Key metrics:
- pg_stat_activity — number of active connections
- pg_stat_bgwriter_buffers_alloc — pressure on the buffer pool
- pg_replication_lag_seconds — replica lag
- pg_locks_count — locks (increase = transaction issues)
We configure Grafana dashboards and alerting to Telegram/Slack. As a result, you see the real database state and can quickly react to anomalies.
Comparison: Single Instance vs. HA Cluster
| Parameter | Single Instance | Cluster with Replica |
|---|---|---|
| Cost | Lower (1 VM) | Higher (2+ VMs) |
| Availability | No failover | Automatic failover < 30 s |
| Read Performance | Average | Reads from replica up to +50% throughput |
| Recovery Time | Days (manual) | Minutes (automatic) |
A cluster with replica ensures automatic failover in less than 30 seconds — 50 times faster than manual recovery of a single instance.
What Our Work Includes
| Stage | Description | Duration |
|---|---|---|
| Infrastructure audit | Analyze load, backups, configuration | 1 day |
| Design | Network scheme, instance types, HA architecture | 1-2 days |
| Terraform deployment | Cluster, parameter tuning, security | 1-3 days |
| Monitoring and alerting | Prometheus, Grafana, alerts | 1 day |
| Documentation and training | Runbook, access, instructions for your team | 1 day |
Outcome: you get production-ready databases with 99.95% uptime guarantee, automatic backup, and monitoring.
How to Order Configuration?
Contact us through the form on our website or by email. We audit your current configuration and workload in 1 day. We prepare a proposal with exact timelines and cost. After agreement — we implement the project turnkey. Get an engineer consultation and an audit of your current database configuration. We guarantee transparency and results.







