Solanica vs AWS RDS
Open, Portable Database Platform vs AWS-Locked Managed Service
Both Solanica and AWS RDS eliminate the need to hand-manage database infrastructure. The fundamental difference: RDS runs your databases deep inside AWS — your backups are in AWS-proprietary format, your extensions are AWS-curated, and your migration path out is painful by design. Solanica runs everything on your Kubernetes clusters — any cloud, any data centre, fully portable.
- Runs on any Kubernetes — AWS, GCP, Azure, on-prem
- Open standard backups; migrate anywhere, any time
- Full superuser access and OS-level configuration
- Apache 2.0 licensed control plane
- Databases run exclusively on AWS infrastructure
- RDS snapshots are AWS-proprietary; export required to migrate
- No superuser, no OS access, curated extension list
- Aurora adds a proprietary storage engine layer
Feature Comparison
A factual comparison across the dimensions that matter most: portability, cost, access, and data control. Where RDS has a genuine advantage, we say so.
| Feature / Dimension | ● Solanica + OpenEverest | ● AWS RDS |
|---|---|---|
| Portability & Vendor Freedom | ||
| Cloud portability | ✓ Runs on 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 deployment option |
| Backup format & migration | ✓ Open standard backups (pgBackRest, PBM, XtraBackup). Restore anywhere — no proprietary tooling required | ◦ RDS snapshots are AWS-proprietary. Migrating out requires RDS Export to S3 (Parquet format) or logical dump via pg_dump / mysqldump — slow for large datasets |
| On-prem / bare metal | ✓ Fully supported — run in your data centre, colocation, or edge clusters | ✗ RDS on Outposts available but requires Outposts hardware purchase and AWS connectivity at all times |
| Air-gapped / disconnected environments | ✓ Supported — control plane and database operators run entirely within your network. No external endpoints required | ✗ Requires persistent AWS connectivity. Air-gapped deployments are not supported |
| Multi-cloud or hybrid strategy | ✓ Same control plane, same operator tooling across AWS, GCP, Azure, and on-prem simultaneously | ✗ AWS-only. Multi-cloud requires separate tooling for each cloud, with different APIs and operational models |
| Pricing & Cost | ||
| Pricing model | ✓ Pay for the Kubernetes compute you own or provision. Solanica adds a predictable platform fee, not a per-node markup on every resource | ◦ Instance hours + Multi-AZ surcharge (2×) + storage (gp3/io1) + provisioned IOPS + backup storage + data transfer + optional RDS Proxy |
| Multi-AZ high availability cost | ✓ HA is native to Kubernetes-based operators (synchronous replication, automated failover) — no extra licensing surcharge | ◦ Multi-AZ deployment doubles instance cost. Single-AZ RDS offers no automated failover |
| Storage & I/O costs | ✓ Standard Kubernetes PVC (gp3, local NVMe, or your SAN). No additional I/O cost layer beyond the underlying storage | ◦ RDS gp3 includes baseline IOPS; additional IOPS are charged separately. Aurora I/O-Optimized tier reduces per-I/O cost but increases base pricing |
| Typical cost at scale (20+ instances) | ✓ 50–70% lower total cost at comparable scale — no per-instance licensing, no Multi-AZ surcharges, no RDS Proxy fees | ◦ RDS remains competitive for small fleets; cost compounds significantly at scale with Multi-AZ, Proxy, and PIOPS requirements |
| Data Sovereignty & Security | ||
| Data residency control | ✓ Data stays in your Kubernetes cluster — your network, your hardware, your jurisdiction. Solanica's control plane never touches your data | ◦ Data runs in your AWS account and VPC, but on AWS-managed hardware. AWS has hypervisor-level access as part of the service model |
| Bring Your Own Key (BYOK) encryption | ✓ Integrate with Vault, AWS KMS, or native K8s Secrets. Available to all tiers with no additional cost | ◦ AWS KMS customer-managed keys available at additional KMS cost. Keys are still managed within the AWS trust boundary |
| Compliance scope | ✓ Audit scope stays within your own infrastructure. Your SIEM, your audit logs, your DPA — no shared responsibility with a third-party SaaS | ◦ AWS holds SOC 2, ISO 27001, FedRAMP, HIPAA BAA. Compliance audits include AWS as a shared-responsibility infrastructure provider |
| Database Access & Flexibility | ||
| Superuser / root access | ✓ Full superuser access. kubectl exec into any pod as an escape hatch for diagnostics or manual intervention | ✗ No superuser. RDS grants a privileged user but restricts system-level operations (e.g. pg_reload_conf, log_fdw, certain pg_catalog modifications) |
| PostgreSQL extensions | ✓ Install any extension — including custom-built or community extensions not in AWS's allow-list | ◦ Curated extension list only. Extensions not pre-approved by AWS cannot be installed, including recent versions of PostGIS, TimescaleDB, and others |
| Database version upgrades | ✓ In-place and blue-green upgrades via operator CRDs. You choose the timing and process | ◦ Major version upgrades require a maintenance window. Some versions are force-deprecated on AWS timelines, not yours |
| Configuration depth (postgresql.conf / my.cnf) | ✓ Full parameter set accessible via UI, API, or CRD spec. No restricted parameters | ◦ RDS Parameter Groups expose a subset. Some parameters (e.g. wal_level, archive_mode) are managed by AWS and not directly configurable |
| Platform & Operations | ||
| Control plane license | ✓ OpenEverest core and all bundled operators: Apache 2.0. The underlying data path is always open source — no proprietary storage engine | ◦ PostgreSQL and MySQL engines are open source. RDS automation layer and Aurora's storage engine are proprietary AWS services |
| GitOps / IaC provisioning | ✓ Native Kubernetes CRDs — Helm, ArgoCD, Flux, or any GitOps toolchain. Databases are first-class K8s resources | ◦ Terraform AWS provider and CloudFormation available. CDK supported. Not K8s-native — requires separate tooling from your app deployments |
| Operational overhead | ◦ Low — operator automates provisioning, HA, backups, upgrades, and monitoring. Requires existing K8s competency in your team | ✓ Very low — AWS manages hardware, OS, patching, and storage. Best-in-class managed service if your team has no K8s footprint |
What Makes the Difference
The comparison table covers the feature checklist. This section covers why those differences matter — especially once you've been running RDS for a year and want to move, grow, or simply understand what you can't do.
Vendor Lock-In Is Structural, Not Incidental
AWS RDS doesn't just run your database on AWS — it wraps it in a set of proprietary layers that make leaving progressively more expensive. This is by design. The more you adopt, the harder it gets:
OpenEverest uses standard open-source backup tools (pgBackRest for PostgreSQL, PBM for MongoDB, XtraBackup for MySQL). Backups are stored in your own S3 bucket or object store in open formats. You can restore from those backups to any PostgreSQL, MySQL, or MongoDB instance anywhere — no proprietary tooling, no AWS dependency, no migration surcharge.
The RDS Bill Has More Line Items Than You Expect
RDS pricing looks simple in the calculator — instance type × hours. In practice, production RDS costs accumulate across multiple dimensions that compound at scale.
The crossover point where Solanica is cheaper than RDS is typically around 5–8 database instances, once Multi-AZ, RDS Proxy, and storage IOPS are factored in. At 20+ instances the savings are typically 50–70%.
Your VPC Is Not the Same as Your Infrastructure
It is a common misconception that RDS in your VPC means RDS on your infrastructure. Your VPC controls your network boundary — but the physical compute, hypervisor, and storage are managed by AWS. This matters in specific regulated contexts:
Solanica's control plane communicates only with your Kubernetes API server — it never connects to your database pods directly or moves your data. Metrics, logs, and telemetry stay within your observability stack (Prometheus, Grafana, Loki, or whatever you run). Your legal team can draw a clear boundary: your hardware, your network, your audit trail.
Configuration Depth & Operational Access
RDS trades operational access for zero-ops convenience. For many workloads that trade-off is worth it. For teams with complex performance tuning requirements, custom extensions, or deep diagnostic needs, the walls become apparent quickly.
When to Choose Each Platform
There's no universal answer. AWS RDS is the right choice for certain teams and workloads. Solanica is the right choice for others. Here is our honest take.
Choose AWS RDS when…
If your entire stack — compute, networking, security tooling, IAM — lives on AWS and you have no plans to change that, RDS's deep integration with IAM, VPC, CloudWatch, Secrets Manager, and AWS Backup is genuinely compelling. The operational surface is tightly unified with services your team already understands.
Solanica requires a Kubernetes cluster to operate. If your team has no K8s footprint and no near-term plans to adopt it, RDS is the lower-friction path. You should still model the future cost of lock-in and portability — but if K8s is genuinely not in the picture, Solanica is not the right choice right now.
For teams running <5 RDS instances with no compliance constraints, the managed service convenience of RDS outweighs the cost premium. At small scale, the operational simplicity is worth the AWS markup. Re-evaluate at 10+ instances when the TCO gap becomes meaningful.
Aurora Serverless v2, Aurora Global Databases, and Aurora's tight integration with AWS AppSync, Lambda, and Bedrock provide capabilities that have no direct equivalent in an open-source stack today. If those integrations are load-bearing for your architecture, Aurora is the right tool — just model the lock-in cost explicitly.
Choose Solanica when…
Any team with a realistic possibility of changing clouds — due to cost renegotiation, M&A, regulatory jurisdiction, or customer requirements — needs a portable database layer. Solanica runs identically on EKS, GKE, AKS, and on-prem. Your databases follow your infrastructure, not the other way around.
Healthcare (HIPAA), financial services (FCA, MAS TRM, OCC), government (FedRAMP High, IL4/IL5), and regulated SaaS companies frequently have requirements that go beyond running in your VPC — they require running on infrastructure where you, not AWS, are the infrastructure operator. Solanica is designed for this constraint from first principles.
Teams migrating from RDS to Solanica most commonly do so when their monthly RDS bill — amplified by Multi-AZ surcharges, RDS Proxy fees, provisioned IOPS, and backup storage costs — becomes a significant line item. If you are spending $50k+/month on RDS, the TCO analysis for Solanica almost certainly shows significant savings.
PostGIS at a recent version, custom FDWs, AGE for graph queries, pg_cron with superuser semantics, custom WAL destinations — these are routinely blocked or limited on RDS. If your database layer has specific technical requirements that RDS constrains, Solanica provides the full open-source engine without restrictions.
Solanica's single control plane manages databases across any Kubernetes cluster — your EKS clusters in prod, your on-prem K3s clusters in factory floors, your RKE2 clusters in a colocation facility. One UI, one API, one operational model, regardless of where the cluster runs.
For PostgreSQL, the standard path uses logical replication: provision a Solanica target cluster, set up pglogical or pg_logical streaming from your RDS instance, run parallel for a validation window, then cut over DNS. For MySQL, Percona XtraBackup or logical dumps via mysqldump provide the migration path. Aurora requires an intermediary logical dump step since Aurora snapshots are not portable. Our team has helped multiple teams through RDS migrations — the typical cutover window is under 30 minutes with zero data loss. Book a migration planning call →
Move from AWS RDS to Solanica
Stop paying the AWS markup and stop building on infrastructure you can't move. Run PostgreSQL and MySQL on any Kubernetes cluster — with the same operational comfort as a managed service, minus the lock-in.
