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
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