Railway Postgres pricing: what does it really cost?

TL;DR: An always-on Postgres on Railway costs about $6 a month small, $36 medium and $145 busy, before your app. RAM is most of that bill, so it grows with your data even when nothing else changes.

• High availability runs three data nodes, so the database line roughly triples: the busy one passes $400.
• Backups are cheap; point-in-time recovery adds bucket storage and upload egress.
• Connecting from outside Railway costs $0.05 per GB of egress, including a frontend on Vercel and every pg_dump.
• The Free plan won't keep a Postgres running all month.
• Stay on Railway if the database costs a few dollars, or you want point-in-time recovery and failover.
• Move to your own server, with Ployz, which I build, if the database is past about $20 a month and growing. A $7 to $19 server runs the same database with your app on the same box.

Railway Postgres is an ordinary Railway service with a volume, running Railway's SSL-enabled Postgres 18 image. There's no database fee and no instance size; you pay for the RAM, CPU and disk the container uses, every minute it runs.

What does an always-on Railway Postgres cost per month?

With my assumptions, a small Postgres costs $6.30 a month, a medium one $35.50 and a busy one $145. RAM is 55% to 80% of the bill at every size. The volume, the thing people think of as "the database", is the smallest line until you're in the hundreds of gigabytes.

The three sizes, as average usage over a 30-day month:

• Small: a side project. 0.05 vCPU, 0.5 GB RAM, 2 GB volume, no public egress.
• Medium: a small business app. 0.5 vCPU, 2 GB RAM, 20 GB volume, 50 GB egress (an analytics tool, a few dumps, an admin client).
• Busy: a SaaS whose database works all day. 2 vCPU, 8 GB RAM, 100 GB volume, 200 GB egress.

These are assumptions, not measurements from my account. On Hobby, the small database alone uses more than the $5 credit, so your app's usage is on top of it. On Pro, the $20 credit is shared by every service in the workspace, so the medium and busy rows are what Postgres adds whatever else you run.

This is the database half of my Railway pricing breakdown, which prices a whole app.

What would your Postgres cost on Railway?

Open your Postgres service's Metrics tab on Railway, read the average memory and CPU, check the volume size, and set the sliders. Egress means data leaving Railway: queries over the public URL, dumps, or a frontend hosted somewhere else. The defaults are the medium database.

How is Postgres billed on Railway?

Like any other service: $10 per GB of RAM per month, $20 per vCPU per month, $0.15 per GB of volume per month and $0.05 per GB of egress. You pay for what the container holds, every minute it runs.

Railway's Postgres guide says the template runs "Railway's SSL-enabled Postgres image, which uses the official Postgres image from Docker Hub as its base." The template page pins it to Postgres 18. You get a container, a volume and connection variables like DATABASE_URL. Railway layers backups, point-in-time recovery, HA and PgBouncer on top.

The plan limits that matter for a database:

Three rules from the volumes reference shape how you run Postgres there: "Each service can only have a single volume", "Replicas cannot be used with volumes", and "there will be a small amount of downtime when re-deploying a service that has a volume attached, even if there is a healthcheck endpoint configured." The second is why HA is a separate cluster product and not a replica count.

Why does the database dominate a Railway bill?

Because Postgres is built to keep data in memory all the time, and memory is what Railway charges most for in practice. An app server can idle at a few hundred megabytes. A database with a working set of several gigabytes wants all of it in RAM, around the clock, at $10 per GB per month.

Railway says it plainly: "you pay for allocated resources, not traffic," and "a server running idle still uses memory to stay loaded" (understanding your bill). Railway's Serverless sleep doesn't help, because an open database connection keeps a service awake.

That's my Railway story. I was paying $500+ a month and the bill went up every month, mostly from the database. It was hit hard and held a lot of gigabytes, and as it grew Postgres used more memory to keep up. I never changed a plan; the meter kept going up with the data. Today one dedicated server at €80 a month runs more than I ever ran on Railway.

Two things make it worse than the table suggests:

• Postgres uses memory beyond shared_buffers. It relies on the operating system's file cache to keep hot data in RAM. How much of that counts as your container's memory depends on the platform, but a busy database reading a large table pushes its memory use up over time.
• Every environment is another database. A staging environment or a preview with its own Postgres is billed by the minute, at the same rates, for as long as it runs.

The cheap fixes on Railway are a smaller shared_buffers, fewer connections, and deleting environments nobody uses. Each Postgres connection is a process with its own memory, which is what Railway's PgBouncer option is for. None of these change the shape: a database that's doing well costs more every month.

What do backups, PITR and high availability add?

Volume backups are cheap. Point-in-time recovery adds bucket storage plus egress for every upload. High availability is the expensive one: three data nodes, each billed for its own RAM, CPU and volume, so the database line roughly triples.

Volume backups. Railway takes them on a schedule you choose: "Daily - Backed up every 24 hours, kept for 6 days", "Weekly - Backed up every 7 days, kept for 27 days", "Monthly - Backed up every 30 days, kept for 89 days" (backups docs). They're "incremental and Copy-on-Write", and you're "only billed for the incremental size of the backup." Even if the busy database's backups held a full extra 100 GB, that's $15 a month. When you restore, Railway mounts a new volume and the original "remains unmounted in the project", so delete it when you're done or you keep paying for it.

Point-in-time recovery. Railway's Postgres image ships every WAL segment to a Railway storage bucket with pgBackRest, takes "a full backup every week and a differential backup every day", and keeps about four weeks (PITR docs). "There's no separate PITR fee", but it's billed through bucket storage and "network egress from the database service for the uploads." For the busy database, four weekly 100 GB full backups is over 400 GB of uploads a month before any WAL: about $20 of egress plus a few dollars of storage. pgBackRest compresses by default, so treat that as an upper bound.

High availability. Railway converts Postgres into a cluster "backed by Patroni, etcd, and HAProxy" (HA docs). The defaults are 2 streaming replicas "in addition to the primary", 3 etcd nodes and 3 HAProxy instances. Each data node needs the same memory as your primary to take over:

The HA docs don't say what the etcd and HAProxy services use, so I left them out; they're small, but they're six more always-on services. If you go back to a single node, "the replicas' and etcd nodes' volumes stay in your project, unattached, and continue to count toward storage billing."

I think HA is worth paying for if downtime costs you real money. But a busy database plus HA is how a solo developer ends up with a database bill in the hundreds.

Does connecting from outside Railway cost extra?

Yes. Any connection from outside Railway goes through a TCP proxy, and everything the database sends back is egress at $0.05 per GB. That includes a frontend hosted elsewhere, a GUI client like pgAdmin, a BI tool and every pg_dump from your laptop. Inside the same Railway project, the private DATABASE_URL is free.

The Postgres guide says it directly: "You will be billed for Network Egress when using the TCP Proxy." Railway lists "not using private networking for databases" as a common cause of high bills (understanding your bill).

This bites hardest in a split stack, with the frontend on Vercel and the database on Railway. If a page reads 50 KB of rows and you serve a million of those pages, that's 50 GB, or $2.50. It's a line that grows with traffic, on top of a line that grows with data. If you're weighing a hosted database instead, I priced Supabase and Render's Postgres separately.

Leaving costs egress too: moving a 20 GB database off Railway with pg_dump "$DATABASE_PUBLIC_URL" is about $1.

Is Railway Postgres free?

Only for a trial or a toy. The Free plan gives "$1 of free credit per month", 0.5 GB of RAM and a 0.5 GB volume per service (pricing docs). $1 buys about 100 MB of RAM running all month, so an always-on Postgres won't stay inside it. New accounts also get a one-time $5 trial credit.

When the credit runs out, the docs say "your subscription will be cancelled" and "we will stop all of your workloads." For a database, that means your app is down until you pay.

What does Postgres cost on your own server?

A fixed monthly price for the whole server, whatever the database does with its memory. A Hetzner CX23 with 4 GB of RAM is $7.09 a month with IPv4, and a CX43 with 16 GB is $19.09. Postgres, your app and Redis share the box, and the bill doesn't move as the data grows, until you outgrow the server.

Hetzner prices are after its 15 June 2026 adjustment, before VAT, for Germany and Finland, with 20 TB of traffic included. Netcup has a US datacenter in Manassas. I'd look at Netcup first, because it gives more disk for the money, and the VPS 2000 has 256 GB for a growing database.

I sized the servers so the app and the OS fit next to the database: the busy Postgres uses 8 GB of the CX43's 16. A shared Hetzner vCPU isn't the same as a Railway vCPU, so don't compare CPU counts one to one. At the small size Railway is cheaper by about a dollar, and it does more for you.

What the server price doesn't include:

• No HA. If the server goes down, the database is down until it's back or you restore it from a mirror on another server.
• Backups need a second server. See the next section.
• Upkeep is your job. Disk space and Postgres major version upgrades.

How do you back up Postgres on your own server?

Keep the backup on a different server, so it survives if the database server dies. With Ployz, that's a mirror: a read-only copy of the database's volume on another of your servers, which you sync from the dashboard or with ployz volume sync. A sync sends only what changed.

If the database server dies, ployz volume restore brings the database back from the mirror. To retire the old server, ployz volume move moves the database onto the other one with seconds of downtime, and the old copy stays as the mirror.

A mirror is as fresh as your last sync. If losing the writes since then isn't acceptable, you want WAL archiving, which Railway's PITR gives you with no setup.

Railway Postgres or your own server?

Stay on Railway Postgres if your database costs a few dollars, you want point-in-time recovery or scheduled backups, or you need a failover cluster and will pay for three copies. Railway's backup and PITR features are real and easy to use.

Pick your own server if your database holds more than a gigabyte or two in memory, it's growing, or it's past about $20 a month on Railway. A $10 to $19 server runs what costs $36 to $145 on Railway, and the bill stays flat while your data grows. For every other fee on a platform bill, see the hidden costs of PaaS pricing.

Where Ployz fits

Ployz, which I build, gives you Railway's one-click Postgres on a server you rent. It runs the same Postgres image Railway's template does, with a 5 GB volume by default, a sealed generated password and the same variable names: DATABASE_URL, PGHOST, PGDATABASE. Your app references it as ${{ postgres.DATABASE_URL }}, the way it does on Railway.

The database has no public address, so there's no TCP proxy egress to pay. Your app reaches it over an encrypted private network, and from your laptop ployz service port-forward connects to it. Your app gets zero-downtime deploys once you set a health check, and every pull request gets a preview environment whose copied database starts empty.

For backups, Ployz mirrors the database's volume onto another of your servers and syncs it when you ask. If the first server dies, restore from the mirror, or move the database there with seconds of downtime.

It's free on your own servers. Start free on your own server.

FAQ

How much does Postgres cost on Railway?

About $6 a month for a small database, $36 for a medium one and $145 for a busy one, at $10 per GB of RAM, $20 per vCPU and $0.15 per GB of volume a month. High availability roughly triples it.

Does Railway back up Postgres?

Yes. Railway offers scheduled volume backups (daily, weekly or monthly) and point-in-time recovery through pgBackRest. You pay the incremental storage and the upload egress.

Why is my Railway Postgres bill growing?

Because Postgres keeps its working set in RAM, and Railway bills RAM by the minute. As your data grows, the database holds more memory and the bill follows, without any plan change.

How do I move Postgres off Railway?

Dump it over the public URL with pg_dump "$DATABASE_PUBLIC_URL" and restore it with pg_restore on the new server. A 20 GB database costs about $1 of egress to move.

How I checked

Prices were checked on 1 October 2026 on Railway's pricing docs and pricing page, and on Hetzner's and Netcup's own pages, all linked next to each number. Railway bills in USD. The three database sizes are assumptions, not measurements from my account. I build Ployz, which competes with Railway.

Run Postgres next to your app on your own server with Ployz, free: get started.