Datastores are currently supported on AWS only. GCP and Azure datastore support is on the roadmap.
AWS Architecture
Datastores are provisioned in a VPC that is separate from the VPC of your clusters. Porter automatically:- Peers the datastore VPC to your cluster VPC
- Configures subnets, routing tables, and security groups
- Ensures traffic flows exclusively through private subnets
Setup
Create a datastore
Navigate to Add-ons in your Porter dashboard and select the datastore type you want to create (Postgres or Redis).
Configure settings
Configure your datastore settings including instance size, storage, and high availability options.
Connect to your application
Porter creates an environment group with the connection details. Inject this environment group into your applications.
Connecting from your laptop
To connect to a datastore from your local machine, use the Porter CLI:If your cluster control plane access is set to private, using this command requires Tailscale VPN to be configured for your cluster.
Postgres
Postgres datastores can be deployed in different configurations depending on your needs:| Configuration | Use Case | Recommended For |
|---|---|---|
| In-cluster | Quick setup for development | Dev/staging environments |
| Single RDS instance (Multi-AZ) | Standard managed database | Production workloads |
| Aurora cluster (Multi-AZ) | Auto-scaling storage and enhanced failover | Production workloads with stringent high-availability requirements |
In-cluster Postgres
Deploys Postgres as a container within your cluster. This is the fastest way to get started but is not recommended for production data.RDS Instance
Provisions a standard Amazon RDS instance with Multi-AZ deployment for automatic failover. This is the recommended option for most production workloads.Aurora Cluster
Aurora provides:- Automatic storage autoscaling
- Enhanced failover capabilities
- High availability settings
Read Replicas
To enable a read replica, select the HA toggle when creating the datastore. With read replicas:- The dashboard displays connection details for both primary and replica
- Modifications automatically failover the primary and promote the replica
- This ensures minimum downtime during operations
Configuration
The following table outlines the configurable fields and behaviors for each datastore type during creation and updates:| Configuration | In-cluster | Standard RDS | Aurora |
|---|---|---|---|
| Connected cluster | Local (via K8s Service) | External (via VPC Peering) | External (via VPC Peering) |
| Region | Matches connected cluster | Matches connected cluster | Matches connected cluster |
| Database name | - | User-defined | User-defined |
| Master username | - | User-defined | User-defined |
| Postgres version | - | Postgres 12-18 | Postgres 12-18 |
| Instance type | CPU/RAM Limits | All RDS compatible instances | All Aurora compatible classes, excepts serverless |
| Allocated storage | Fixed (Cannot be modified) | Modifiable (Increase only) | Managed (Auto-scales) |
| Snapshot restore | - | From RDS snapshot | From Aurora snapshot |
| Cloning | - | - | Fast Database Cloning |
Redis
Redis datastores can be provisioned in different configurations:| Configuration | Use Case | Recommended For |
|---|---|---|
| In-cluster | Quick setup for development | Dev/staging environments |
| Elasticache replication group | Managed cache with automatic failover | Production workloads |
In-cluster Redis
Deploys Redis as a container within your cluster. This is the fastest way to get started but is not recommended for production data.Elasticache Replication Group
Provisions an Amazon Elasticache replication group with:- Primary and reader replica by default
- Automatic failover if the primary fails
- Minimal downtime during modifications
Managing resources after creation
Open a datastore from the dashboard and use the Resources and Settings tabs to adjust capacity and engine version in place. Changes are previewed before they are applied, and you must acknowledge the diff before Porter submits the update.Resources tab
The Resources tab lets you resize an existing RDS or Aurora datastore without recreating it.- Instance type — Pick a new RDS or Aurora-compatible instance class. Porter shows the current selection and only enables the update button when the form is dirty.
- Allocated storage (RDS only) — Increase the disk size in GB. The usage bar shows currently used storage, currently available headroom, and the additional headroom you are about to provision. Decreases are not supported by RDS and are blocked in the form. Aurora storage continues to autoscale and does not expose a disk size control.
In-cluster Postgres and Redis datastores have fixed CPU/RAM limits and a fixed disk size. The Resources tab is only available for managed RDS, Aurora, and Elasticache datastores.
Upgrading PostgreSQL versions
RDS and Aurora datastores expose a PostgreSQL version selector in the Settings tab. Use it to perform an in-place engine upgrade.Pick a target version
The selector lists the versions AWS currently offers for your engine in the datastore’s region. Only versions greater than or equal to the current version are shown — downgrades are not supported.
Review the dry-run diff
Porter runs a dry run and opens a confirmation modal showing exactly what will change on the datastore contract.
The version selector is only shown for managed RDS and Aurora Postgres datastores. In-cluster Postgres uses a pinned image and is not upgradeable from this UI. Viewers cannot submit version updates.
Monitoring
You can monitor the performance of your database from the Porter dashboard. Metrics are available in the “Metrics” tab when opening a datastore. The metrics that are currently displayed are:- CPU utilization
- RAM utilization
- Storage capacity
Disaster Recovery
Porter supports some options for disaster recovery of RDS datastores.Restoring from a snapshot
You can restore a snapshot to a new datastore, and the datastore will be accessible from the applications running in your cluster. This can significantly reduce the time to recovery during an emergency.Enable
Create a new datastore in the dashboard. In the creation form, click on “Enable snapshot restore”
Confirm
Select one of the available snapshots to restore or enter the id manually. Only snapshots in the same region as the database are listed.
Cloning an Aurora cluster
Aurora clusters support cloning an existing cluster using fast-cloning. This process is faster than restoring from a snapshot, and can be used to recover from an emergency, or to quickly create copies of your database for experiments.Enable
Create a new datastore in the dashboard. In the creation form, click on “Enable database cloning”
Confirm
Select one of the existing Aurora clusters or enter the identifier manually. Only clusters in the same region as the selected one are listed.
Compliance
If the compliance feature is enabled for your project, Porter automatically configures monitoring alarms for RDS and Aurora datastores:- CPU utilization alarms
- Memory utilization alarms
- Storage capacity alarms
Roadmap
The following features are not yet supported natively in Porter, but reach out to the support team for help setting them up.- Connection pooling
- External access to datastores