Last updated: March 2026

Heroku pricing is not complicated. That's by design. The problem isn't understanding the model. The problem is that the model compounds in ways teams don't anticipate, and by the time it becomes obvious, the question is no longer just about cost.

TL;DR

• Heroku's pricing is predictable at small scale and surprising at scale

• Costs compound as dynos, databases, and add-ons grow together

• The "PaaS tax" is real: you pay a premium for abstraction, and that premium feels harder to justify when the platform stops evolving

• The February 2026 sustaining engineering announcement makes the cost-vs-value equation more difficult to answer

• Cost alone rarely triggers migration. Cost plus platform risk usually does.

How Heroku pricing works

Heroku's pricing model has three components: compute (dynos), managed databases, and add-ons. Understanding each in isolation understates how they interact.

Dyno pricing

Dynos are Heroku's compute unit. Every running process, web servers, background workers, cron processes, consumes dynos. Heroku offers several tiers (see heroku.com/pricing for current rates):

• Eco: $5/month (shared, sleeps after 30 minutes of inactivity)

• Basic: $7/month (no sleeping, but no horizontal scaling)

• Standard-1X: $25/month per dyno

• Standard-2X: $50/month per dyno

• Performance-M: $250/month per dyno

• Performance-L: $500/month per dyno

Eco and Basic are fine for hobby projects and development environments. Standard and Performance tiers are what production applications use. The per-dyno pricing is the key variable: horizontal scaling means multiplying the per-dyno cost by the number of running instances.

Managed databases

Heroku Postgres is tiered by RAM, storage, and connection limits. Essential plans start around $5 to $50 per month. Standard and Premium plans, which support follower databases and higher connection limits, start at around $50/month and scale to several hundred per month for mid-tier configurations. High availability (HA) configurations, which most production applications should have, add meaningful cost on top of the base tier.

Shield Postgres, required for HIPAA-eligible workloads, sits in an entirely different pricing tier. More on that below.

Add-ons and marketplace services

Heroku's marketplace is one of its historical strengths. You can add Heroku Data for Redis, logging tools like Papertrail or Logdna, monitoring via New Relic or Scout, search via Bonsai, email delivery via Sendgrid, and dozens of other services directly through the platform.

Each add-on has its own pricing tier, and most have a free or low-cost starting tier. The trap is that each individually seems small. Papertrail at $7/month. Redis at $15/month. New Relic at $25/month. Sendgrid at $20/month. These totals accumulate without feeling significant in any single line item.

Where it gets expensive

The add-on compounding effect

A typical mid-size application on Heroku: two Standard-1X web dynos, one Standard-1X worker dyno, Heroku Postgres Standard 0 with HA, Heroku Redis, a logging tool, and a monitoring tool. Before you add anything unusual, you're looking at roughly $250 to $400 per month. Add staging environment parity (because not having staging is its own kind of technical debt) and you're at $400 to $700 per month for a moderately complex application.

That's not outrageous. But it grows. Database tiers jump as data volume increases. Performance dyno upgrades add several hundred dollars per month. Workers multiply. By the time a five-person engineering team has a production-grade setup with reasonable staging and worker parity, the bill is commonly in the $500 to $1,000 range per month.

Background worker costs

This is where teams get surprised. Web traffic spikes often result in scaling web dynos. But background jobs, queues, scheduled tasks, and data processing pipelines require worker dynos that run independently. A single Sidekiq worker on Standard-1X is $25/month. Three workers processing different queue priorities: $75/month in compute alone, before you count Redis or any monitoring overhead.

Worker costs multiply with the application's job processing requirements, not its web traffic requirements. Teams building event-driven or data-heavy applications find this compounds faster than expected.

Database tier jumps

Heroku Postgres pricing does not scale smoothly. Storage and connection limits tier in large increments. Moving from Essential to Standard can mean jumping from $30 to $50 per month. Moving from Standard 0 to Standard 2 doubles the price. Adding a follower (read replica) for reporting or failover adds the same cost again. Teams that are not actively managing their database tier often find themselves paying for more than they need, or hitting a wall that requires a jump to a significantly more expensive tier.

The PaaS tax

"PaaS tax" is the phrase developers use to describe what you're paying for when you're paying more than raw infrastructure costs. It includes: the abstraction layer that makes deployment simple, the managed services that eliminate operational overhead, the opinionated workflow that reduces decision fatigue, and the support structure that handles infrastructure incidents.

At the right scale, the PaaS tax is worth paying. A two-person startup paying $200/month more than they would on AWS in exchange for not having to hire a DevOps engineer is making a rational trade.

The PaaS tax becomes painful when the abstraction stops delivering new value. You've already built around Heroku's constraints. The opinionated workflow has become a bottleneck rather than a guide. The add-on ecosystem doesn't cover something you need. The support response time doesn't match what you're paying. You're paying the premium for abstraction you've already compensated for through workarounds.

That's the moment teams start doing the math on alternatives.

"I'm paying the same and getting less": the sustaining engineering effect

The February 2026 sustaining engineering announcement introduced a new dimension to the cost conversation that didn't exist before.

When Heroku was actively building, paying a platform premium made sense. The premium included not just what the platform did today, but where it was going. Features that were on the roadmap, improvements to the developer experience, new capabilities that would solve future problems.

Under sustaining engineering, the platform is maintained but not evolved. You're paying the same dyno rates. The same add-on costs. The same Shield tier pricing for compliance workloads. But the platform isn't going anywhere. Features that were missing in 2024 will still be missing in 2026. Compliance gaps that exist today are unlikely to close.

Teams paying premium pricing for a stagnant platform are essentially funding maintenance work, not platform investment. That's a different value proposition than it was two years ago, and it's a harder one to justify to engineering leadership or finance.

For teams on Heroku Shield specifically, this shift is particularly sharp. Shield pricing is substantially higher than standard Heroku, priced to reflect the additional compliance infrastructure and isolation it provides. If that compliance infrastructure is not evolving with regulatory expectations and customer requirements, the premium becomes harder to defend. See Heroku and HIPAA.

Heroku pricing vs. AWS

AWS raw compute is cheaper than Heroku dyno pricing on a per-CPU-per-hour basis. An ECS Fargate task running the equivalent workload of a Standard-1X dyno can cost significantly less than $25/month in pure infrastructure spend. Reserved instances and savings plans reduce costs further.

That is not the right comparison to make.

The real question is not "is AWS cheaper?" The real question is: do you want to pay in platform premium or in engineering overhead?

Moving to AWS means owning the infrastructure layer that Heroku manages for you: VPC design, IAM policies, load balancer configuration, secrets management, logging stack, monitoring stack, and CI/CD orchestration. These are not one-time setup costs. They require ongoing maintenance, domain expertise, and an on-call posture that reflects the fact that infrastructure failures are now your failures to debug.

A platform engineer who can own this stack costs significantly more annually than the difference in infrastructure costs between Heroku and AWS at most startup scales. Teams that do this well have either hired the right people or are paying in engineering time that isn't being captured in the infrastructure budget.

The teams that migrate to AWS and regret it usually underestimated the fully-loaded cost of the operational responsibility shift. See DIY Cloud for a full breakdown of what that responsibility transfer involves.

Heroku pricing vs. Render, Railway, and Fly.io

For teams whose primary motivation for leaving Heroku is cost, the Heroku-like PaaS alternatives are the natural comparison:

• Render: web services starting at $7/month (Starter) or $25/month (Standard). PostgreSQL managed databases starting at $7/month. Per-second billing reduces overpayment for variable workloads.

• Railway: Hobby plan at $5/month flat, covering multiple services. Usage-based pricing after that. No managed databases.

• Fly.io: Shared CPU instances starting at approximately $1.94/month for 256MB RAM. Highly granular compute pricing. Managed Postgres via Supabase integration.

At small scale, any of these is meaningfully cheaper than Heroku Standard dynos. At medium scale, the comparison depends heavily on your workload shape, add-on dependencies, and how much you rely on managed services.

The more important comparison isn't cost. It's platform risk. All three of these platforms are actively building. Roadmaps are public and advancing. That distinction has become more relevant since February 2026.

→ For a full comparison of platform options, see PaaS Alternatives.

Heroku Shield pricing

Heroku Shield is the enterprise tier designed to support HIPAA-eligible workloads. It includes dedicated Shield dynos (not multi-tenant compute), Private Spaces with private networking, Shield Postgres, and enhanced logging. The BAA is available under enterprise contracts.

Shield pricing is substantially higher than standard Heroku. Standard Private Spaces are priced hourly (~$1.39/hour) and cap at approximately $1,000/month; Shield Private Spaces cap at approximately $3,000/month. Shield dynos, Shield Postgres, and Shield Redis add cost on top of that. A regulated application on Shield with modest requirements can easily reach $2,000 to $3,000/month before scaling. See Heroku's Private Spaces pricing for current rates. Production-grade Shield deployments with HA databases, multiple worker processes, and full monitoring coverage commonly run $5,000 to $10,000+ per month.

At that price point, the comparison to compliance-first alternatives like Aptible becomes directly relevant. Aptible's pricing covers a production-grade compliance infrastructure including HITRUST R2 certification, built-in audit logging, environment isolation, and dedicated compliance tooling. A team paying $5,000/month on Heroku Shield may find that comparable infrastructure on a platform purpose-built for regulated workloads costs similar amounts while providing cleaner compliance posture and better audit evidence generation.

The sustaining engineering announcement matters here specifically: if you're paying Shield pricing for compliance infrastructure, you're now paying that premium for a compliance posture that won't evolve. See Heroku vs. Aptible.

When Heroku pricing makes sense

Heroku pricing makes sense in specific circumstances:

• Small teams (one to three engineers) where developer velocity outweighs infrastructure cost

• Early-stage products where operational simplicity is the primary constraint

• Workloads with low complexity: a single web process, a managed Postgres, minimal add-ons

• Teams with no compliance pressure on a standard tier

• Organizations where the cost of a migration (engineering time, risk, distraction) clearly exceeds the cost savings

At these scales, the PaaS premium is worth paying. Heroku's developer experience is genuinely good, and the abstraction has real value for teams that haven't outgrown it.

When pricing becomes a migration trigger

Financial triggers: Monthly infrastructure spend growing faster than revenue. Database costs doubling year over year. Finance pushing for budget predictability that Heroku's tiered model makes difficult. Add-on costs that have become difficult to forecast or justify.

Operational triggers: Scaling dynos without gaining architectural flexibility. Database tier upgrades becoming routine instead of exceptional. Workers multiplying faster than the codebase warrants because Heroku's horizontal scaling model is the only tool available.

Strategic triggers: Paying premium pricing for a platform that no longer innovates. Enterprise procurement misalignment. Desire for infrastructure that grows with compliance requirements rather than forcing them to be managed externally.

Cost alone rarely triggers migration. Cost combined with any of the above usually does. See Should You Migrate? for the full decision framework.

Next steps

If cost is driving your evaluation:

• Audit dyno usage: which dynos are running, at what tier, with what utilization?

• Audit database tiers: are you paying for HA and replicas you haven't validated?

• Inventory add-ons: which ones are necessary, which ones have accumulated by default?

• Model AWS cost including platform engineering overhead, not just compute.

• Compare Heroku-like alternatives at your current workload scale.

• Define a migration runway that accounts for engineering time and rollback risk.

Cost is rarely the only reason to move. But it's often the first signal that a broader platform evaluation is overdue.

See next: PaaS Alternatives, DIY Cloud, Migration Guide, Compare Platforms