What Is Amazon RDS? Managed Postgres on AWS Explained

Amazon Relational Database Service (RDS) is a common way to run PostgreSQL on AWS: you pick an engine, an instance class and storage, and AWS handles the host, storage, backups, patching and failover. RDS supports several engines, and this guide focuses on RDS for PostgreSQL, the default choice for new backends.

An RDS instance lives in your VPC, is reached through a DNS endpoint with any standard PostgreSQL driver, and is billed by instance class, storage and backup usage. This guide covers what RDS manages and what it leaves to you, how Multi-AZ, backups, read replicas and RDS Proxy work, how RDS compares to Aurora, and how to get an RDS database from application code with Encore (infrastructure from code).

Amazon RDS at a glance

How RDS works

An RDS instance is a database server running on a managed host with EBS storage, placed in a DB subnet group, a set of subnets in your VPC across at least two Availability Zones. The RDS user guide lists engines and instance classes. You connect with a normal PostgreSQL driver to the instance endpoint, and engine settings such as max_connections or shared_preload_libraries live in a DB parameter group.

With a Multi-AZ deployment, RDS keeps a synchronous standby in a second Availability Zone and fails over to it by flipping the DNS name of the endpoint, typically within a minute or two. The standby is for availability only and does not serve reads. Read replicas are separate instances fed by asynchronous replication, used to offload read traffic, each with its own endpoint.

Automated backups take a daily snapshot and keep transaction logs, so you can restore to any second within the retention period, up to 35 days. A restore always creates a new instance, which means the application has to be pointed at a new endpoint. Serverless functions and other workloads that open many short-lived connections usually put RDS Proxy in front of the instance to pool connections.

RDS vs Aurora

Aurora PostgreSQL keeps the PostgreSQL wire protocol and SQL, and replaces the storage layer with a distributed volume replicated six ways across three Availability Zones. It grows storage on its own, supports up to 15 readers with low replica lag, and offers Aurora Serverless v2, which scales capacity in fine steps. RDS for PostgreSQL is plain PostgreSQL on EBS, simpler to reason about and usually cheaper for small and steady workloads. A common path is to start on RDS and move a database to Aurora when read scaling or failover time becomes the constraint.

How RDS is billed

RDS for PostgreSQL charges for the instance class by the hour while the instance runs, for allocated storage and any provisioned IOPS, for backup storage beyond the free allowance, and for data transferred out. The RDS for PostgreSQL pricing page notes that backup storage up to 100% of the total database storage in a Region has no additional charge. A Multi-AZ deployment runs a second instance as the standby, so it roughly doubles the instance cost, and each read replica is billed as its own instance.

Stopping an instance pauses the instance charge but not storage, and AWS starts a stopped instance again after seven days, so stopping is a way to save on idle development databases rather than a long-term setting. Reserved instances lower the hourly rate for databases that run all the time.

How Encore provisions RDS

Encore is infrastructure from code for TypeScript and Go, with a platform that provisions and deploys into your own AWS or GCP account. You declare a database in code, and on AWS Encore creates an RDS for PostgreSQL instance by default, or an Aurora PostgreSQL cluster, an imported existing database, or a Neon database if you pick those for the environment, as listed in the AWS infrastructure docs.

A new RDS instance defaults to db.m5.large with Multi-AZ and 7-day backup retention, is encrypted at rest and sits in a private subnet, and each setting can be changed per environment in the dashboard.

Set up the app

A database is a package-level variable next to the code that uses it:

// user/user.go
package user

import (
	"context"

	"encore.dev/storage/sqldb"
)

// RDS for PostgreSQL on AWS, a local Postgres under encore run.
var db = sqldb.NewDatabase("users", sqldb.DatabaseConfig{
	Migrations: "./migrations",
})

type User struct {
	ID    int64  `json:"id"`
	Email string `json:"email"`
}

//encore:api public method=GET path=/users/:id
func Get(ctx context.Context, id int64) (*User, error) {
	u := &User{ID: id}
	err := db.QueryRow(ctx, `SELECT email FROM users WHERE id = $1`, id).Scan(&u.Email)
	if err != nil {
		return nil, err
	}
	return u, nil
}

encore run starts Postgres locally and applies the SQL files in migrations, and encore db shell users opens a psql session against it. On deploy, Encore creates the RDS instance, applies migrations through a proxy running in your environment so the database never has to be exposed to the internet, and injects the credentials at runtime, so no connection string is committed or copied into CI. The query API is covered in the Go database docs. An existing instance can be attached instead with import an existing RDS database.

Good to know

• Major version upgrades are not automatic on RDS, and a PostgreSQL version can be upgraded but never downgraded. In Encore, changing the version reboots the instance.
• Plan connection counts per service, since each Fargate task holds its own pool.
• Test a point-in-time restore before you need one, since it produces a new instance.

Related guides

• Deploy a database to AWS without Terraform
• Add a database to a Go API
• Terraform on AWS
• Migrate Supabase to AWS
• Go ORMs compared