Solanica vs AWS RDS
AWS RDS runs PostgreSQL and MySQL for you inside AWS. Solanica, built on the open source OpenEverest project, runs them on your own Kubernetes clusters, on any cloud or in your own data center.
Both take away the work of hand-managing database servers. The difference is what you are tied to. On RDS, backups are in an AWS-specific format, extensions come from a list AWS curates, and moving out takes real effort. With Solanica, the databases follow your infrastructure wherever it goes.
AWS RDS
A managed service that runs only on AWS.
- Databases run exclusively on AWS infrastructure
- Snapshots are AWS-specific; leaving requires an export
- No superuser, no OS access, and a curated extension list
- Aurora adds a proprietary storage engine underneath
Solanica + OpenEverest
Self-hosted and Kubernetes-native, with an open source core.
- Runs on any Kubernetes: AWS, GCP, Azure, or on-prem
- Backups in open formats that restore anywhere
- Full superuser access and complete configuration control
- Control plane licensed under Apache 2.0
Side by side
| Solanica + OpenEverest | AWS RDS | |
|---|---|---|
| Portability | ||
| Cloud portability | Any Kubernetes: EKS, GKE, AKS, RKE2, K3s, or bare metal. Move between clouds without re-architecting | AWS only. No GCP, Azure, on-prem, or edge option |
| Backup format and migration | Open standard backups (pgBackRest, PBM, XtraBackup) that restore anywhere without proprietary tooling | Snapshots are AWS-specific. Moving out means RDS Export to S3 (Parquet) or a logical dump with pg_dump or mysqldump, which is slow for large datasets |
| On-prem and bare metal | Supported in your data center, a colocation facility, or edge clusters | RDS on Outposts, which requires buying Outposts hardware and a constant connection to AWS |
| Air-gapped environments | Supported. The control plane and operators run entirely inside your network with no external endpoints | Not supported. RDS needs a persistent connection to AWS |
| Multi-cloud and hybrid | The same control plane and operators across AWS, GCP, Azure, and on-prem at the same time | AWS only. Other clouds need separate tooling with different APIs and operating models |
| Pricing | ||
| Pricing model | The Kubernetes compute you already own or provision, plus a predictable Solanica platform fee rather than a markup on every resource | Instance hours, Multi-AZ surcharge (2x), storage (gp3 or io1), provisioned IOPS, backup storage, data transfer, and optional RDS Proxy |
| High availability cost | Built into the operators (synchronous replication, automated failover) with no surcharge | Multi-AZ doubles the instance cost. Single-AZ has no automated failover |
| Storage and I/O | Standard Kubernetes volumes (gp3, local NVMe, or your SAN), with no I/O charges beyond the storage itself | gp3 includes baseline IOPS and more costs extra. Aurora I/O-Optimized lowers per-I/O cost but raises the base price |
| Cost at 20+ instances | Typically 50–70% lower total cost: no per-instance licensing, Multi-AZ surcharges, or RDS Proxy fees | Competitive for small fleets. Costs add up at scale once Multi-AZ, Proxy, and provisioned IOPS are involved |
| Data sovereignty and security | ||
| Data residency | Data stays in your cluster: your network, your hardware, your jurisdiction. Solanica's control plane never touches it | Data is in your AWS account and VPC, but on AWS-managed hardware, where AWS has hypervisor-level access as part of the service |
| Bring your own key | Vault, AWS KMS, or Kubernetes Secrets, on every tier at no extra cost | KMS customer-managed keys at additional KMS cost. Keys stay inside the AWS trust boundary |
| Compliance scope | Audit scope stays within your infrastructure: your SIEM, your audit logs, your DPA, with no third-party SaaS in the shared responsibility | AWS holds SOC 2, ISO 27001, FedRAMP, and a HIPAA BAA. Audits include AWS as a shared-responsibility provider |
| Database access | ||
| Superuser access | Full superuser access, plus kubectl exec into any pod for diagnostics | No true superuser. RDS grants a privileged user but restricts system-level operations such as pg_reload_conf, log_fdw, and some pg_catalog changes |
| PostgreSQL extensions | Any extension, including community or custom builds that AWS doesn't list | Curated list only. Extensions AWS hasn't approved can't be installed, including recent versions of PostGIS, TimescaleDB, and others |
| Version upgrades | In-place and blue-green upgrades through the operator, on your schedule | Major upgrades need a maintenance window, and some versions are deprecated on AWS's timeline |
| Configuration (postgresql.conf, my.cnf) | The full parameter set through the UI, API, or CRD spec, with nothing restricted | Parameter Groups expose a subset. Some parameters, such as wal_level and archive_mode, are managed by AWS |
| Platform and operations | ||
| Licensing | OpenEverest and its bundled operators are Apache 2.0. The whole data path is open source, with no proprietary storage engine | The PostgreSQL and MySQL engines are open source. The RDS automation layer and Aurora's storage engine are proprietary |
| GitOps and infrastructure as code | Databases are Kubernetes resources, managed with Helm, Argo CD, Flux, or any GitOps tool | Terraform, CloudFormation, and CDK. Not Kubernetes-native, so separate from your application deployments |
| Operational effort | Low. The operator handles provisioning, HA, backups, upgrades, and monitoring, but your team needs Kubernetes skills | Very low. AWS manages hardware, OS, patching, and storage. The best managed option if you don't run Kubernetes |
A highlighted cell marks the clearly stronger option for that row. AWS details come from public AWS documentation as of April 2026.
Leaving RDS
RDS adds AWS-specific layers on top of PostgreSQL and MySQL. Each one you adopt makes moving away a bigger job.
- RDS snapshots are stored in an AWS-specific format. To migrate out, you export to S3 as Parquet (PostgreSQL) or take logical dumps. For a database of several terabytes, that can take days and cost a lot in data transfer.
- Aurora uses a proprietary distributed storage engine. Moving from Aurora to standard PostgreSQL or MySQL takes a full logical dump and restore, and Aurora snapshots can't be restored outside AWS.
- RDS Proxy, Parameter Groups, and IAM authentication tie applications more closely to AWS APIs. Applications that connect through RDS Proxy or use IAM tokens need changes before they can connect to a database anywhere else.
- When AWS ends support for a PostgreSQL or MySQL major version, you upgrade on AWS's timeline. Engine parameter defaults can also change between RDS versions.
OpenEverest uses standard open source backup tools: pgBackRest for PostgreSQL, Percona XtraBackup for MySQL, and Percona Backup for MongoDB. Backups are written in open formats to your own S3 bucket or object store, and they restore to any PostgreSQL, MySQL, or MongoDB instance without AWS tooling or migration fees.
What an RDS bill includes
The RDS price calculator starts with instance type times hours. A production deployment adds several more lines, and they grow with scale.
RDS: production PostgreSQL cluster
- DB instance (db.r6g.2xlarge)
- 2x for Multi-AZ, needed for production HA
- gp3 storage, plus provisioned IOPS if needed
- Backup storage beyond 1x instance storage
- RDS Proxy, billed hourly per vCPU
- Data transfer out of RDS to your app tier
Total: roughly 2.5–3.5x the instance cost
Solanica: the same workload on EKS
- Kubernetes node compute, on the same or a smaller EC2 instance
- HA through operator replication, with no compute surcharge
- EBS gp3 storage at standard EBS prices
- Backups to your own S3 at S3 prices
- pgBouncer connection pooling included in the operator
- No egress inside the cluster when the app and database share a VPC
Total: EKS node cost plus the Solanica platform fee
Solanica usually becomes cheaper than RDS at around 5 to 8 database instances, once Multi-AZ, RDS Proxy, and provisioned IOPS are counted. At 20 or more instances, savings are typically 50–70%.
Your VPC is not your infrastructure
Running RDS in your VPC is sometimes taken to mean running it on your own infrastructure. The VPC sets your network boundary, but AWS manages the physical servers, hypervisor, and storage. In some regulated settings, that difference matters:
- AWS has hypervisor-level access to the hosts that run RDS instances. Workloads that require strict infrastructure isolation, such as US government IL4/IL5 or some financial services rules, may not accept that shared responsibility for data at rest.
- Some GDPR residency and localisation requirements call for data to stay in a specific jurisdiction on infrastructure under your direct legal control. RDS stays on AWS-managed hardware whichever region you pick.
- RDS Enhanced Monitoring and Performance Insights send telemetry to AWS services. In air-gapped or classified environments, any outbound data flow, including operational metrics, may need controls that RDS can't provide.
Solanica's control plane talks only to your Kubernetes API server. It never connects to database pods directly or moves your data. Metrics, logs, and telemetry stay in your own observability stack, such as Prometheus, Grafana, or Loki. Your hardware, your network, and your audit trail form one clear boundary.
Access and configuration
RDS trades operational access for convenience. For many workloads that is a good trade. Teams with demanding performance tuning, custom extensions, or deep diagnostics tend to run into its limits.
| Operation | Solanica | AWS RDS |
|---|---|---|
| Diagnostics | Full database access via kubectl port-forward or the service endpoint, with kubectl exec as a break-glass option | Endpoint access only. No shell, no process inspection, no OS-level diagnostics |
| Custom PostgreSQL extensions | Any extension, including community or custom builds not on AWS's list | Only extensions AWS has approved. AGE, Citus, and custom FDWs may be unavailable |
| WAL archiving to your own target | Set the archive target per cluster: S3, GCS, Azure Blob, MinIO, or NFS | Managed by AWS. You can't send WAL to your own archive |
| Read replica topology | Synchronous or asynchronous replicas in any topology, across clusters, regions, or clouds | Read replicas within AWS regions. Cross-cloud replication needs logical replication set up outside RDS |
| Upgrade timing | In-place, blue-green, or rolling upgrades on your schedule, from a CRD or the UI | Maintenance windows required. AWS may force upgrades when a version reaches end of life |
| Non-AWS infrastructure | The same control plane and operators on GKE, AKS, on-prem, bare metal, or at the edge | Not available |
When RDS is the better choice
You are fully on AWS with no plans for other clouds
If your compute, networking, security tooling, and IAM all live on AWS and that won't change, RDS's integration with IAM, VPC, CloudWatch, Secrets Manager, and AWS Backup is a real advantage. Your team already knows these services.
You don't run Kubernetes
Solanica needs a Kubernetes cluster. If your team doesn't run one and doesn't plan to, RDS is the easier path. It's still worth estimating what lock-in will cost you later, but Solanica isn't the right choice for you yet.
You have a small fleet and need to move fast
For teams with fewer than 5 RDS instances and no compliance constraints, the convenience is worth the premium. Look again at 10 or more instances, when the cost gap starts to matter.
You rely on Aurora or other AWS-only features
Aurora Serverless v2, Aurora Global Database, and Aurora's integration with AppSync, Lambda, and Bedrock have no direct open source equivalent today. If your architecture depends on them, Aurora is the right tool. Just account for the lock-in.
When Solanica is the better choice
You can't afford to depend on one cloud
Teams that may change clouds because of pricing negotiations, an acquisition, regulation, or customer requirements need a database layer that can move with them. Solanica runs the same way on EKS, GKE, AKS, and on-prem.
Your data must stay on infrastructure you control
Healthcare (HIPAA), financial services (FCA, MAS TRM, OCC), government (FedRAMP High, IL4/IL5), and regulated SaaS often need more than a VPC. They need you, not AWS, to be the infrastructure operator. Solanica was designed for that from the start.
RDS costs are growing with scale
Teams usually move from RDS to Solanica once the monthly bill, driven up by Multi-AZ, RDS Proxy, provisioned IOPS, and backup storage, becomes a significant line item. If you spend more than $50k a month on RDS, a cost comparison will very likely show significant savings.
You need full access, custom extensions, or deep configuration
A recent PostGIS, custom FDWs, AGE for graph queries, pg_cron with superuser rights, or your own WAL destination are often blocked or limited on RDS. Solanica gives you the full open source engine without those restrictions.
You run databases in the cloud, on-prem, and at the edge
One Solanica control plane manages databases on any Kubernetes cluster: EKS in production, K3s on a factory floor, RKE2 in a colocation facility. One UI, one API, and one way of operating, wherever the cluster runs.
Moving from RDS
For PostgreSQL, the usual path is logical replication. Create a Solanica target cluster, stream changes from RDS with pglogical or native logical replication, run both in parallel while you validate, then switch DNS. For MySQL, use Percona XtraBackup or a logical dump with mysqldump. Aurora needs a logical dump step in between, because Aurora snapshots aren't portable.
We have helped several teams migrate off RDS. The cutover window is typically under 30 minutes, with no data loss.
- Migration paths exist for PostgreSQL and MySQL, from both RDS and Aurora.
- Logical replication keeps RDS running until you confirm the cutover.
- Solanica deploys on your existing EKS cluster, with no new infrastructure required.
- Your data never passes through Solanica servers.
To try OpenEverest first, follow the quick install guide. To plan a migration, book a call with our engineers.
Amazon Web Services, AWS, Amazon RDS, and Amazon Aurora are trademarks of Amazon.com, Inc. or its affiliates. Solanica and OpenEverest are not affiliated with or endorsed by Amazon, and these names are used here only to identify the products being compared. AWS details are based on publicly available AWS documentation as of April 2026.