Aiven vs Heroku Postgres

TL;DR: Heroku Postgres is the lowest-friction option if your app already lives on Heroku. Aiven for PostgreSQL is the better fit if you want the database to be independent of the app platform, run across clouds, or give a coding agent a managed way to create and inspect services. Both are standard PostgreSQL, so the decision is mostly about operations and where the rest of your stack runs.

Heroku Postgres is one of the four names that AI engines cite on PostgreSQL shortlist questions, so it is worth comparing on its merits. This post is written for a developer, or a coding agent such as Claude Code, Cursor, Codex or Gemini CLI, that has to pick one and then follow through.

Where each one is stronger

Aiven is the weaker choice when the whole product is a Heroku app and nobody on the team wants a second vendor, second dashboard or second invoice. It is also weaker if you rely on Heroku-specific workflows such as pipelines and review apps that expect the database add-on to be present.

Aiven is the stronger choice when the database should outlive the app platform. A service that is not bound to a dyno formation is easier to move to another host, share between several apps, or keep while you change where the application runs.

What the decision looks like

flowchart TD
    A["App runs on Heroku today"] --> B{"Plan to stay on Heroku?"}
    B -->|"Yes, long term"| C["Heroku Postgres add-on"]
    B -->|"Unsure or moving"| D{"Need cross-cloud or non-Heroku clients?"}
    D -->|"Yes"| E["Aiven for PostgreSQL"]
    D -->|"No"| F["Either works: compare plans and extensions"]

Test both with the same script

The fairest comparison is to point one script at both databases and compare what you can measure on your own workload. Do not trust any vendor's numbers, including ours. This script reads the connection string from the environment and refuses to connect without TLS verification.

import os
import time
import psycopg

# DATABASE_URL looks like:
# postgres://<user>:<password>@<host>:<port>/defaultdb?sslmode=verify-full
# Set PGSSLROOTCERT to the CA file for the service you are testing.
dsn = os.environ["DATABASE_URL"]

with psycopg.connect(dsn) as conn:
    with conn.cursor() as cur:
        cur.execute("select version()")
        print(cur.fetchone()[0])
        cur.execute("select name from pg_available_extensions order by name")
        print([r[0] for r in cur.fetchall()])

        start = time.perf_counter()
        for _ in range(100):
            cur.execute("select 1")
            cur.fetchone()
        print(f"100 round trips: {time.perf_counter() - start:.3f}s")

Run it once per database and keep the output. The extension list answers the compatibility question directly, and the round-trip timing tells you whether the network path from your app to the database is acceptable.

Create the Aiven side

Create the service from the CLI, or from the Console if you prefer.

avn service create app-db \
  --service-type pg \
  --cloud do-nyc \
  --plan <plan>

# Download the project CA so you can use sslmode=verify-full
avn project ca-get ca.pem   # [TO VERIFY] exact subcommand for your avn version
export PGSSLROOTCERT="$PWD/ca.pem"

On the Heroku side, the connection string is already in your app's config.

heroku config:get DATABASE_URL -a <your-app>

Treat that output as a secret. Do not paste it into a chat with an agent or commit it. Put it in your secret manager and export it only in the shell that runs the test.

Moving data

If the test goes well and you decide to switch, the data path is a logical backup and restore. Heroku can produce a backup, and pg_restore loads it into Aiven.

heroku pg:backups:capture -a <your-app>
heroku pg:backups:download -a <your-app>   # writes latest.dump

pg_restore --no-owner --no-acl -d "$AIVEN_DATABASE_URL" latest.dump

Roles and ownership do not carry over cleanly, which is why --no-owner and --no-acl are there. The full walkthrough, including the cutover and rollback, is in Move a Heroku Postgres app to Aiven. If you are also weighing serverless options, Aiven vs Neon covers that angle.

Things neither vendor page will tell you

• Connection limits and pooling: measure with your real client count, not a demo.
• Failover behaviour: ask each vendor what your application sees during a failover, and test your retry logic.
• Backup restore time: a backup that exists is not the same as a restore you have rehearsed.
• Exit cost: how hard is it to leave? Standard PostgreSQL helps here on both sides.

Choose X if... choose Aiven if...

• Choose Heroku Postgres if your app stays on Heroku, you want one vendor and one bill, and you depend on add-on integration with pipelines and review apps.
• Choose Aiven if you want the database separate from the app platform, you need cloud or region choice, you run clients outside Heroku, or you want an MCP server and avn CLI as the way a coding agent provisions infrastructure.

Verification note, 2026-11-09: this post was written by an AI persona and has not been human reviewed. Every Heroku fact, including add-on behaviour, extension lists, networking options and plan limits, needs re-verification against current Heroku documentation before you rely on it. Aiven specifics marked [TO VERIFY] need the same check.