Expert Guide Editorially reviewed

The Best Postgres Hosting in 2026

Where to run managed PostgreSQL in 2026, from scale-to-zero serverless to a plain always-on instance, compared on what actually shows up on the invoice.

Louis CorneloupFounder, Dupple · 600,000+ readers · Updated Aug 2026

Independently researched. No pay-for-placement. 5 tools compared

TL;DR

For a side project or a preview environment, Neon is the default: it scales compute to zero, its free tier gives you 100 CU-hours and 0.5 GB per project, and database branching makes per-pull-request databases trivial. If you want auth, file storage and realtime bundled with the database, Supabase at $25/month on Pro is the fastest path from empty repo to shipped product. If the database is one piece of a service you are already deploying, Railway keeps it in the same project for $5/month on Hobby. For a production database you intend to keep for years, Crunchy Bridge starts at $9/month with backups and connection pooling included, and Amazon RDS remains the answer when compliance and VPC peering decide for you.

Managed Postgres stopped being one product a while ago. The name on the tin is the same, and so is the wire protocol, but a serverless Postgres that suspends after five minutes of silence and a provisioned instance that never sleeps solve genuinely different problems, and they fail in different ways.

Picking on price per gigabyte is how teams end up migrating twice.

The useful question is not which host is fastest. It is which billing model matches your traffic shape, and how much operational work the host takes off your hands.

A database that costs nothing while nobody uses it is a gift for a preview environment and a liability for an API that has to answer in 40 milliseconds at 3am. Below, five hosts that cover the realistic range, with the prices they actually publish.

Top Picks

Based on features, real-world fit, and value for money.

Best Postgres Hosting: 5 tools compared, updated Aug 2026
Tool	Pricing	Best for
Neon	Free $0/month (100 CU-hours and 0.5 GB per project). Launch and Scale are usage-based: $0.106/CU-hour and…	Preview environments, spiky traffic and anyone who wants a database per pull request
Supabase	Free $0/month (500 MB database, 1 GB file storage, 50,000 MAU). Pro $25/month (8 GB disk included, then $0.125/GB)…	Shipping a product fast when you need auth, storage and realtime alongside the database
Railway	Free $0/month with $1 of usage credits. Hobby $5/month including $5 of credits. Pro $20/month per workspace including…	Teams already deploying their app on Railway who want the database in the same project
Crunchy Bridge	Hobby-0 from $9/month (2 cores, 0.5 GB memory), fully inclusive of machine costs, hosting, backups and connection…	A production database you plan to keep for years, run by people who take Postgres seriously
Amazon RDS	On-demand per instance-hour plus storage and I/O, with reserved instances for committed workloads. Rates vary by…	Organisations where VPC peering, compliance posture or an existing AWS commitment makes the decision

Pricing read from each vendor's own published pricing page, checked Aug 2026. Every vendor here publishes a price.

Neon

Top Pick

Best for: Preview environments, spiky traffic and anyone who wants a database per pull request

PricingFree $0/month (100 CU-hours and 0.5 GB per project). Launch and Scale are usage-based: $0.106/CU-hour and $0.222/CU-hour compute respectively, both $0.35/GB-month storage

+Branching is copy-on-write, so a branch of a 50 GB database is instant and nearly free

+Compute scales to zero, which makes dozens of preview databases cost close to nothing

+Autoscaling up to 16 CU (64 GB RAM) on Launch, so the free tier is not a dead end

−Cold starts on a suspended branch are real, and noticeable on user-facing requests

−Usage-based billing is harder to forecast than a flat instance, especially with many branches

Visit Neon →

Supabase

Best for: Shipping a product fast when you need auth, storage and realtime alongside the database

PricingFree $0/month (500 MB database, 1 GB file storage, 50,000 MAU). Pro $25/month (8 GB disk included, then $0.125/GB). Team $599/month

+You get auth, storage and realtime subscriptions without wiring three more services

+It is genuinely plain Postgres underneath, so nothing traps you at the SQL layer

+Row-level security is a first-class citizen rather than something you bolt on

−The bundle is only a bargain if you use the bundle; for a database alone it is not the cheapest

−The free tier pauses inactive projects, which surprises people using it for a staging environment

Visit Supabase →

Railway

Best for: Teams already deploying their app on Railway who want the database in the same project

PricingFree $0/month with $1 of usage credits. Hobby $5/month including $5 of credits. Pro $20/month per workspace including $20 of credits. Usage beyond credits is billed per second: $0.00000386/GB/second memory, $0.00000772/vCPU/second, $0.00000006/GB/second volumes

+The database sits in the same private network as your services, so no public egress and no extra config

+Per-second billing on memory and CPU, so a small database really does cost a few dollars

+Hobby scales up to 48 vCPU and 48 GB per service, which is far more headroom than the price suggests

−Credits-plus-usage pricing takes a month of real traffic before you can predict the bill

−It is a deployment platform first, so the Postgres-specific tooling is thinner than a dedicated host

Visit Railway →

Crunchy Bridge

Best for: A production database you plan to keep for years, run by people who take Postgres seriously

PricingHobby-0 from $9/month (2 cores, 0.5 GB memory), fully inclusive of machine costs, hosting, backups and connection pooling. Storage billed separately at $0.10 per GB, prorated by use

+Backups and connection pooling are included rather than line items you discover later

+Storage is billed by actual use at $0.10/GB, so you are not buying a volume you half fill

+Runs on your choice of cloud, which matters when the rest of your stack already lives somewhere

−No scale to zero, so an idle database still costs the monthly instance price

−No branching, so preview environments need the old dump-and-restore approach

Visit Crunchy Bridge →

Amazon RDS

Best for: Organisations where VPC peering, compliance posture or an existing AWS commitment makes the decision

PricingOn-demand per instance-hour plus storage and I/O, with reserved instances for committed workloads. Rates vary by instance class and region, so price your exact configuration in the AWS calculator

+Multi-AZ failover, read replicas and point-in-time recovery are mature and well understood

+Sits inside your VPC, which is often a hard requirement rather than a preference

+Reserved instances cut the cost substantially on a workload you know will stay

−The most operational work of the five: parameter groups, subnet groups and upgrade windows are yours

−The bill is genuinely hard to predict, because storage, I/O, backups and egress are all separate lines

Visit Amazon RDS →

What it is

Managed Postgres hosting means someone else runs the server, the backups, the failover and the version upgrades, and you get a connection string. What separates the options in 2026 is the compute model. Serverless hosts like Neon separate storage from compute and suspend the compute when idle, so you pay for the seconds you query.

Provisioned hosts like Crunchy Bridge and Amazon RDS give you a machine that stays up, which you pay for whether or not anyone connects. Platform hosts like Supabase and Railway wrap Postgres in a broader product, so the database arrives with an API layer, auth, or the rest of your services already next to it.

Why it matters

The choice shows up in two places you will feel. The first is the bill, and it rarely scales the way you assume: usage-based compute is dramatically cheaper for spiky or low traffic and dramatically worse for a steady always-on workload, because you are paying a premium rate for every second instead of a flat rate for a machine.

The second is cold starts. A suspended serverless database wakes in a few hundred milliseconds, which is invisible in a dashboard and very visible on a checkout page. Neither is a defect. They are trade-offs, and picking the wrong side is the single most common reason teams migrate a database they did not need to migrate.

Key features to look for

Pricing modelEssential

Usage-based compute billed by the CU-hour or the second, versus a flat monthly instance. Usage-based wins on spiky and low traffic, flat wins the moment the database is genuinely always busy.

Scale to zero and cold startsEssential

Whether idle compute suspends, and how long it takes to wake. Free for preview environments, a latency tax on anything user-facing.

Database branching

Copy-on-write branches of your data, so every pull request gets its own database with production-shaped rows instead of an empty schema and a seed script.

Connection poolingEssential

Postgres handles a few hundred connections badly and serverless functions open thousands. A built-in pooler (PgBouncer or equivalent) is the difference between working and mysteriously not working under load.

Backups and point-in-time recoveryEssential

How far back you can rewind, and whether it is included or billed separately. Check the retention window on the tier you will actually be on, not the enterprise one.

Extensions and version control

Whether you can install pgvector, PostGIS or TimescaleDB, and whether you choose when the major version upgrade happens rather than being told.

Mistakes to avoid

×Choosing serverless for a database that is never idle. Scale to zero saves nothing when traffic is constant, and the per-second rate is higher than the equivalent flat instance. Look at your traffic graph before your pricing page.

×Ignoring connection pooling until production. Postgres degrades badly past a few hundred connections, and serverless functions open one per invocation. Every host on this list offers a pooler; use the pooled connection string from day one rather than the direct one.

×Treating the free tier as a staging environment. Several free tiers suspend or pause inactive projects, which means your staging database is asleep exactly when a colleague tries to demo something.

Expert tips

→Price your real workload, not the headline. Take a week of query volume and idle time, then run it through the usage rates above. The answer flips between serverless and provisioned far more often than people expect.

→If you use branching, put a limit on branch lifetime. Copy-on-write is cheap per branch and expensive at forty abandoned branches, and nobody deletes them by hand.

→Check which extensions you need before you commit. pgvector, PostGIS and TimescaleDB availability varies by host and by tier, and discovering the gap after migrating is an expensive afternoon.

The bottom line

There is no best Postgres host, only a best match for your traffic shape. Spiky, bursty or preview-heavy work belongs on Neon, whose branching turns per-pull-request databases from a chore into a default. If the database is the start of a product rather than a component, Supabase at $25/month on Pro saves you weeks of wiring auth and storage.

Railway makes sense precisely when you are already there. And for a database that has to be up, backed up and boring for the next three years, Crunchy Bridge from $9/month or Amazon RDS inside your own VPC are the grown-up answers. Decide on the billing model first; the feature list follows from it.

Frequently asked questions

Is serverless Postgres actually cheaper?

Only for workloads with real idle time. Serverless bills a premium rate per second of compute and charges nothing while suspended, so a preview environment used two hours a day is dramatically cheaper. An API answering queries around the clock is usually cheaper on a flat instance, because you pay the lower rate continuously instead of the higher rate continuously.

What is database branching and do I need it?

Branching creates a copy-on-write clone of your database, so a branch of a large database is near-instant and costs only the changed pages. It is genuinely useful if you run preview environments per pull request and want production-shaped data in them. If your team ships from one staging database, it is a feature you will not use.

How bad are cold starts on a suspended database?

On a modern serverless Postgres a suspended compute resumes in a few hundred milliseconds. That is invisible on an internal dashboard or a cron job and clearly visible on a page a customer is waiting on. If a cold start would land on a user-facing request, either keep a minimum compute running or use a provisioned instance.

Can I move between these hosts later?

Yes, and that is the point of choosing Postgres. All five run real PostgreSQL, so pg_dump and pg_restore or logical replication will move you. The friction is never the data, it is the surrounding features: Supabase auth and row-level security policies, or Neon branches, do not travel. Keep the parts you would have to rewrite small if you expect to move.

Get the Devshot brief

Free daily newsletter, read in 5 minutes.

Subscribe free