RDS MySQL / PostgreSQL
What does zop.dev create for RDS MySQL / PostgreSQL?
zop.dev provisions an RDS instance for MySQL 8.0 or PostgreSQL 16.1 with gp3 autoscaling storage, and creates 4 Secrets Manager entries plus Kubernetes init jobs that build the schemas and a read-only role. Deletion protection is on by default, so teardown requires disabling it first.
| Field | Value |
|---|---|
| Cloud | aws |
Amazon RDS is AWS’s managed relational database service for MySQL and PostgreSQL. zop.dev provisions the instance and everything around it (networking, credentials, schemas, and access roles) so an application can connect securely the moment provisioning finishes.
An instance with schemas, roles, and secret entries
DB instance plus optional read replica, subnet and parameter groups, security group, database-init Kubernetes jobs that create schemas and a read-only role, and four Secrets Manager entries (master, app user, editor, read-only).
Engine choice, gp3 autoscaling, deletion protection
rds_type mysql|postgresql; MySQL 8.0 / PostgreSQL 16.1 engine versions; gp3 storage with autoscaling (allocated_storage to max_allocated_storage); multi_az; read_replica with its own multi-AZ flag; deletion_protection on by default; monitoring_interval 0/1/5/10/15/30/60; enable_ssl; multi_ds and databases[] for multiple schemas; app defaults db.t3.small with 20 GB gp3 and max 100+disk; 178 instance classes cataloged (m5 through x2g, t3/t4g families).Outputs wired to downstream consumers
Outputs include admin user, password, port, URL, read-replica URL, and instance metadata for downstream wiring.
The part that is not just an instance
Provisioning RDS by hand leaves you with an empty database and a master password. What this adds is everything between that and an application that can connect:
- Four Secrets Manager entries: master, app user, editor and read-only. Four credentials with different privilege levels, rather than one password shared everywhere.
- Database-init Kubernetes jobs that create the schemas listed in
databases[]and provision a read-only role against them. - Subnet group, parameter group and security group wired to the VPC.
The read-only role is the useful default. It is the credential you hand to a BI tool or an analytics job, and creating it at provisioning time means nobody reaches for the master password because a read credential did not exist yet.
Defaults worth knowing
db.t3.small with 20 GB gp3 and autoscaling to 100 GB plus disk. Deletion protection on,
which means teardown requires disabling it first, deliberately.
monitoring_interval defaults to 0, so Enhanced Monitoring is off. Turning it on has a
per-instance cost and is worth doing on anything production-facing.
178 instance classes are catalogued, m5 through x2g and the t3/t4g families.
Multi-AZ is per-instance and per-replica
multi_az applies to the primary, and a read replica carries its own independent flag. A
Multi-AZ primary with a single-AZ replica is a valid and easily-missed configuration. The
replica becomes the weak point in exactly the failure it was meant to cover.
Cost shape
Multi-AZ roughly doubles the instance cost. A read replica adds another full instance. Storage
autoscaling grows and never shrinks, so max_allocated_storage is a ceiling you will eventually
pay for, not a target.