Migrating From Heroku Postgres to a Managed Database

Migrating off a managed database platform is a forced decision, driven by a specific security flaw, a patch cycle that keeps getting busier, and a pricing structure that punishes teams for waiting. This piece walks through both halves of that decision: which managed provider actually fits your workload, and how to move the data without losing any of it.

Start with the flaw itself. CVE-2026-2003 is an information disclosure vulnerability published in February 2026. It affects every PostgreSQL version before 18.2, 17.8, 16.12, 15.16, and 14.21, and it only takes an authenticated session to exploit. If your team is running an older build on an unpatched host, you're exposed right now, not hypothetically. This is not a one-off. PostgreSQL published multiple security vulnerabilities through 2025, and average CVSS severity scores trended higher in 2024 than in prior years. The patch cadence is picking up, not slowing down, and a database platform that can't keep pace puts every application behind it at risk.

Money adds pressure on top of security. The same workload can cost close to nothing on one provider or configuration, and several hundred dollars a month on another. Teams stuck on older managed Postgres setups frequently pay a steep markup over what current alternatives charge for equal or better service. AWS makes the penalty for delay explicit: RDS Extended Support, which kicks in once a database version hits community end-of-life, charges a per-vCPU-hour surcharge, and that rate doubled on March 1, 2026. Staying put has a price tag attached, and it goes up on a schedule.

None of this is unsolvable. You can pick the right destination and move the data cleanly, because both problems already have well-understood answers. The rest of this guide covers both, in order: how to pick a provider, then how to execute the move itself.

What a managed database means in practice

A managed PostgreSQL service takes over provisioning, patching, backups, scaling, and high availability, running those tasks automatically instead of leaving them to whoever's on call. How much of that work actually gets lifted off your plate changes a lot depending on who you pick. What's bundled into the base price versus billed separately can swing the real monthly cost by several times over, so if two providers quote similar sticker prices, they can end up miles apart once backups, storage, and failover get added in.

Managed also has a ceiling. No provider makes your schema decisions, tunes your queries, or does your migration work for you. Those stay on your team's desk no matter which vendor you pick. What managed buys you is freedom from server maintenance, security patching, performance tuning, and disaster recovery planning, which matters most for teams without a dedicated database administrator on staff. That's the strongest case for picking a higher-abstraction option when engineering headcount is tight: every hour not spent patching a server is an hour spent on the product.

Managed Postgres splits into two broad categories: platform-native and specialist, and the right choice depends on which ecosystem and feature set the workload actually needs. Platform-native managed Postgres, the kind offered directly by the major clouds (RDS, Cloud SQL, Azure Flexible Server), integrates tightly with the ecosystem around it: IAM, VPC networking, native monitoring tools. It's the natural fit when the rest of the application already lives in that same cloud. Specialist managed Postgres, offered by vendors like Neon, Supabase, Aiven, and Crunchy Data, brings features the major clouds don't match: branching databases like a git repo, a full backend-as-a-service stack, a single control plane spanning multiple clouds, or deep extension support for teams that need it. You can also switch clouds later without switching database vendors, because these specialist platforms are built to be portable.

Migration itself takes real engineering time, a cost worth factoring in before the provider comparison. Budget four to eight hours a month for the first three months after the move, then two to four hours a month once things settle. You need to weigh that cost against what it costs to stay on an unpatched, overpriced setup. The math usually favors moving, but you need to know the bill up front.

How to choose a provider before touching any data

Four variables decide which managed Postgres provider fits a given team, and they apply in a strict order: compliance requirements first, then workload pattern, then existing cloud footprint, then team size. Working through them in sequence eliminates most of the field fast. Most teams end up choosing between one or two real options, not five.

Compliance comes first because it overrides every other preference. If the application touches protected health information under HIPAA, or falls under SOC 2, PCI DSS, or federal regulatory frameworks, the list of viable providers shrinks immediately, before cost or performance even enter the conversation. Crunchy Data co-authored the DISA STIG for PostgreSQL and the PostgreSQL CIS Benchmark, which makes it the strongest credential on the table for regulated federal and healthcare workloads. Neon offers HIPAA and SOC 2 compliance on its Scale plan, backed by PrivateLink, point-in-time recovery, single sign-on, and a strong uptime SLA at that tier. Supabase can handle HIPAA too, but only after a signed Business Associate Agreement and the HIPAA add-on are both in place. SOC 2 certification by itself does not cover HIPAA requirements on Supabase, so you need to confirm both pieces are active before you store any protected data. Amazon Aurora backs its compliance posture with encryption at rest through AWS KMS, SSL/TLS in transit, IAM authentication, and patching handled automatically during scheduled maintenance windows. Whichever provider makes the shortlist, check for support of pgAudit, the standard extension for compliance-grade audit logging. It produces structured log entries that map directly to what SOC 2, HIPAA, and PCI DSS auditors ask for.

Workload pattern is the second filter. If your application sits idle for long stretches, you need a different provider than you would if it ran constant, high-throughput writes. Neon scales to zero, so an idle database costs nothing in compute, and that makes it the clear choice when your workload spends a meaningful chunk of the month inactive, for preview environments, or for databases spun up per pull request. Aurora Serverless v2 autoscales compute automatically and fits AWS-native applications with unpredictable traffic. Aurora in its provisioned form delivers up to three times the throughput of standard PostgreSQL with failover typically completing in under 30 seconds, making it the strongest pick for high write throughput on AWS. On Google Cloud, AlloyDB offers notably faster transactional performance along with a built-in columnar engine for analytical queries, which matters for teams running mixed transactional and analytical workloads (HTAP) on GCP.

Existing cloud footprint is the third filter, and it's often the deciding one once compliance and workload pattern have narrowed the field. Teams already deep into AWS, using IAM, VPC peering, RDS Proxy, and Lambda daily, get the smoothest path by staying with RDS or Aurora. Teams built on GCP get native integration through Cloud SQL or AlloyDB. Azure shops benefit because Flexible Server has built-in PgBouncer connection pooling and can stop and start instances on demand. Azure added more reasons to stay in 2025: MCP Server integration for AI applications, generally available on-demand backups, and near-zero-downtime scaling for servers running in high-availability mode. For teams that aren't locked into any single cloud, Aiven runs across AWS, GCP, Azure, DigitalOcean, UpCloud, OVHcloud, and more, all through one control plane backed by a strong SLA. That makes Aiven the strongest option available for genuinely multi-cloud setups.

The fourth and final filter is team size and how much you want a managed developer experience. If your small team has no dedicated database administrator, you should weight abstraction heavily, because every layer of manual database work removed is a layer no specialist needs to cover. Supabase bundles authentication, realtime subscriptions, S3-compatible storage, edge functions, and auto-generated REST APIs (with GraphQL available as an opt-in extension) directly on top of plain Postgres. Wiring all of that together independently would take four to six weeks; Supabase ships it as one platform from day one. A six-month benchmark comparing these providers side by side landed on a practical rule for greenfield projects: start on Neon or Supabase, and migrate to Crunchy Data or RDS only when compliance or performance requirements force the move.

Provider profiles: costs and tradeoffs

What managed Postgres advertises as its price rarely matches what you actually end up paying. High availability, backups, egress charges, and extended support added to the base rate raise the real number, and across the providers compared here, the final total can differ by a factor of ten for what is otherwise the same workload.

Neon's Launch plan costs an entry-level monthly price, and it covers a moderate allotment of storage, compute hours, and projects, with no monthly minimum since December 2025. The Scale plan costs more and adds more storage and compute hours: it bills per CU-hour for compute and per GB-month for storage, and storage costs more than raw EBS gp3 rates. On the free tier you get 0.5 GB of storage, a limited number of projects, and scale-to-zero behavior. PgBouncer connection pooling comes included at every tier, a real edge over RDS, where pooling is not built in. Neon's control plane had two multi-hour incidents in 2025, so it is getting more reliable, but it hasn't caught up to RDS-level maturity yet.

Supabase's Pro plan costs a mid-range monthly price, including a moderate allotment of storage and data egress, with overage rates applying once either limit is exceeded. HIPAA compliance requires both a signed BAA and the HIPAA add-on activated. SOC 2 certification alone does not cover it. The real differentiator for Supabase is the backend-as-a-service bundle: authentication, realtime, storage, and edge functions all in one platform. If you don't need that bundle, you may end up paying for capability you won't use, so check whether a leaner, Postgres-only option costs less for the same workload.

A higher-tier plan from one provider costs more each month, but a hobbyist tier exists for single-node setups and comes with one free month included. Aiven runs on AWS, GCP, or Azure with VPC peering and PrivateLink support, backed by a strong uptime SLA and a wide range of extensions, including TimescaleDB. The best fit is a multi-cloud shop already running Kafka, ClickHouse, or Redis alongside Postgres and looking for one control plane to manage all of it.

Crunchy Data's Bridge Hobby tier starts at an entry-level monthly price, but it has no permanent free tier, and it advertises no free trial. What Crunchy delivers is vanilla PostgreSQL with more than 60 extensions and direct access to deep Postgres expertise, backed by its role co-authoring the DISA STIG and the CIS Benchmark for PostgreSQL. It fits enterprise, compliance-heavy, and regulated workloads best, along with Postgres purists who need specific extensions you can't get anywhere else.

If you build a production configuration on AWS RDS or Aurora, costs can pile up fast. Multi-AZ deployment roughly doubles compute cost on its own. Extended Support then adds a per-vCPU-hour charge starting in year three after a version's community end-of-life, and that rate doubled effective March 1, 2026. A full high-availability production setup, Multi-AZ plus a read replica plus a meaningful amount of storage, costs the top of the price range across every provider compared here. Aurora costs about 20% more than standard RDS for equivalent instance sizes, but at high-throughput workloads, it can work out cheaper per unit of performance. Aurora storage autoscales up to 256 TiB on supported engine versions and shrinks back down automatically as data gets deleted. RDS overall carries a substantial markup over raw compute once a Multi-AZ configuration includes backups and monitoring, so model the actual workload against that markup before defaulting to AWS-native by habit. The clearest fit for RDS or Aurora is an application already using IAM, VPC peering, RDS Proxy, and Lambda as part of its daily operation.

Google Cloud SQL supports PostgreSQL versions 9.6 through 18, scales up to 624 GB of RAM and 64 TB of storage, and offers private IP with VPC peering plus tight integration with BigQuery and Looker. AlloyDB, Google's higher-tier option, costs noticeably more than Cloud SQL Enterprise Plus, with storage priced at roughly double Cloud SQL's SSD storage rate. In exchange, it offers a strong uptime SLA that holds even during maintenance windows, AI-powered vector search through Google's ScaNN index (described as significantly faster than HNSW), and Gemini integration for generating SQL from natural language. For SaaS startups focused on cost, GCP's compute and database pricing runs lower than both AWS and Azure, and that gap widens further with sustained-use discounts applied over time.

Azure Database for PostgreSQL Flexible Server offers a burstable compute tier suited to variable workloads, built-in PgBouncer pooling, and the ability to stop and start instances on demand, a useful lever for any environment that doesn't need to run around the clock.