Managed Databases

Frostmoln runs managed PostgreSQL and MySQL instances for you — the platform provisions the virtual machine, attaches persistent storage, configures the engine, and gives you a ready-to-use connection. You manage your data; we manage the infrastructure underneath.

Choosing an engine and version

Pick PostgreSQL or MySQL at create time. Each engine offers several versions, and the create dropdown is the source of truth for what you can launch right now — currently around PostgreSQL 14–17 and MySQL 8.0 / 8.4.

Every version carries a lifecycle status:

Status	Launchable?	Meaning
current	Yes	Newest fully-supported release
supported	Yes	Fully supported
deprecated	Yes (marked)	Still launchable, shown with a (deprecated) marker — plan to move off it
eol	No	End of life — hidden from the create dropdown

The recommended version for each engine is marked (Recommended). End-of-life and preview versions are not offered for new instances.

Sizing

Instance sizes use the db.gp1.<size> flavor family (general-purpose):

Flavor	vCPU	RAM
db.gp1.micro	1	1 GB
db.gp1.small	2	4 GB
db.gp1.medium	4	8 GB
db.gp1.large	8	16 GB
db.gp1.xlarge	16	32 GB

You choose storage separately (20–1000 GB). The create dialog shows the estimated cost before you confirm.

Create an instance

In the portal, go to Databases → Instances → Create and choose the engine, version, flavor, storage size, and the VPC + subnet the instance attaches to. Optionally enable High Availability (see below).

From the CLI

Lifecycle commands are engine-specific (fm database postgres … / fm database mysql …); the cross-engine fm database … group lists across engines.

fm database postgres instance create \
  --name app-db \
  --version 16 \
  --flavor db.gp1.medium \
  --storage 100 \
  --vpc my-vpc \
  --subnet my-subnet

# MySQL is symmetric:
fm database mysql instance create --name app-db --version 8.4 --flavor db.gp1.small --storage 40 --vpc my-vpc --subnet my-subnet

# Cross-engine views:
fm database instance list
fm database version list

With Terraform

resource "frostmoln_postgres_instance" "app" {
  name             = "app-db"
  version          = "16"
  flavor_id        = "db.gp1.medium"
  storage_gb       = 100
  vpc_id           = frostmoln_vpc.main.id
  subnet_id        = frostmoln_subnet.main.id
  ha_enabled       = true
}

Connect

After provisioning, the instance detail page reveals the connection details behind a Show Credentials button:

• Host — the instance's private address
• Port — 5432 (PostgreSQL) or 3306 (MySQL)
• Username — pgadmin (PostgreSQL) or mysqladmin (MySQL)
• Password — generated for you (rotatable)
• a ready-to-use connection URI

Databases are reachable from instances on the same VPC; the create flow opens the engine port in the instance's security group. Connect like any standard client:

psql "host=<host> port=5432 user=pgadmin dbname=postgres"

TIP

Treat the admin credentials like any secret — store them in Secrets or your application's secret store, not in source control.

High availability

Enable High Availability at create time (the HA option in the portal, --ha on the CLI, or ha_enabled = true in Terraform). The platform provisions a standby alongside the primary so the instance can fail over. HA is selected at create time.

Backups and restore

PostgreSQL and MySQL instances support scheduled and on-demand backups. They are opt-in: the portal's create form ticks Enable Automated Backups for you, but on the CLI you pass --backup and in Terraform you set backup_enabled = true — otherwise the instance is created without them. The schedule is a cron expression (0 2 * * * by default). Each backup is encrypted with your tenant's own backup key before it leaves the instance.

Retention is minimum 35 days, maximum 90. Backups are written to immutable, object-locked storage that holds every object for 35 days, so a shorter retention could not delete anything sooner — the API rejects it. Deleting a backup yourself takes effect for you immediately; the stored object is purged once its immutability window has passed.

In the portal, use the Backups tab on the instance. A backup can only be taken while the instance is running. Revoking your tenant's backup key (fm database backup-key revoke) disables backups and restores for every managed database in the tenant until you re-enable it.

Instances created before backups launched

The in-guest backup agent ships inside the instance image, so an instance created before managed backups went live does not carry it: a backup on such an instance stays in creating and never completes. Create a new instance to get backups.

fm database postgres backup list <instance-id>
fm database postgres backup create <instance-id> --name pre-migration
fm database postgres backup delete <instance-id> <backup-id>

resource "frostmoln_postgres_instance" "app" {
  # … create arguments as above …
  backup_enabled        = true
  backup_schedule       = "0 2 * * *"
  backup_retention_days = 35
}

Restore

Restoring is non-destructive: it provisions a new instance from the backup and leaves the source untouched. Restore is backup-based — point-in-time restore is not yet available.

fm database postgres restore <instance-id> --backup <backup-id> --target-name app-db-restored

Deleting an instance is permanent

Deleting an instance removes it and its storage volume. Take a backup first if you may need the data — and keep an independent logical dump somewhere durable such as object storage if you want a copy outside the platform:

pg_dump   "host=<host> user=pgadmin dbname=app"  > app.sql   # PostgreSQL
mysqldump -h <host> -u mysqladmin app            > app.sql   # MySQL

Lifecycle and limits

• Versions are fixed for the life of an instance — in-place upgrades are not yet available. To move to a newer major version, create a new instance on that version and migrate your data (e.g. with pg_dump / mysqldump).
• Deletion is permanent and removes the storage volume (see above).
• An instance lives in one VPC/subnet (one region).

Related

• Network: VPCs · Security Groups
• Object Storage (somewhere to keep your dumps)
• Caches · Billing