StitchDB vs Railway: Where Should Your Database Live?

Railway vs StitchDB is less "either/or" than it looks. Railway is an app platform: you deploy services, workers and databases on a canvas and pay for the CPU, RAM and disk they use. StitchDB is a managed backend: a Postgres database per project with Auth, REST and GraphQL APIs, Realtime, Storage and Edge Functions on flat monthly plans. Where they overlap is Postgres, and there the difference is how much of the database operations you want to own.

We make StitchDB. Railway facts are from railway.com/pricing and Railway's docs, as of November 2026.

#Two different products

Railway runs anything you can put in a container or build from a repo: a Next.js app, a Go API, a queue worker, Redis, Postgres. Postgres comes from a template that deploys a single node Railway maintains, and you can convert it to an HA cluster with automatic failover. You pay a plan fee (Free with $1 of credit, Hobby $5 with $5 included, Pro $20 per workspace with $20 included) plus usage: about $10 per GB of RAM per month, $20 per vCPU per month, $0.15 per GB-month of volume storage and $0.05 per GB of egress.

StitchDB doesn't host arbitrary containers. It hosts the backend: Postgres plus the services most apps build around it. Free is $0 with 2 projects; Pro is $15.99 a month with 10 GB of database per project, 7 days of point-in-time recovery, 100,000 monthly active users and 1 TB of egress included.

#Postgres head to head

#Cost: a small production database

A Postgres service on Railway using on average 1 GB of RAM and 0.5 vCPU with a 10 GB volume:

• RAM: $10
• CPU: $10
• Volume: $1.50
• Total: about $21.50 a month of usage, partly covered by the plan's included credit.

On StitchDB Pro: $15.99 a month, including the database (up to 10 GB), backups and PITR, plus Auth, Storage and the APIs. You don't size RAM or CPU; you work within plan limits instead (for example 1,000 API requests per second and 100 direct database connections on Pro). If a project outgrows shared servers, Scale and Enterprise projects can move to a dedicated server (compute).

Railway's usage model is fairer for very small or very bursty workloads, and it gives you direct control over resources. StitchDB's model is simpler to predict.

#Using both together

A common setup: app servers on Railway, database and auth on StitchDB.

# Railway service variables
STITCHDB_URL=https://<project-ref>.p.stitchdb.com
STITCHDB_SERVICE_ROLE_KEY=<service_role key, server only>
DATABASE_URL=postgresql://p_<ref>_owner:<password>@<db-host>:6543/p_<ref>?sslmode=require

// server code on Railway
import { createClient } from 'stitchdb-js'

const admin = createClient(process.env.STITCHDB_URL, process.env.STITCHDB_SERVICE_ROLE_KEY, {
  auth: { persistSession: false, autoRefreshToken: false },
})

const { data: overdue } = await admin
  .from('invoices')
  .select('id, customer_id, amount_cents')
  .lt('due_at', new Date().toISOString())
  .eq('status', 'open')

Two things to plan for:

1. Region. Put your Railway service in EU West (Amsterdam) so it is close to StitchDB's EU data centers. A Railway service in a US region would add a transatlantic round trip to every query.
2. Egress. Traffic from your Railway service to StitchDB leaves Railway's network, and Railway bills service egress at $0.05 per GB. Keep result sets small.

#When Railway is the better choice

• You want one canvas for every service, database included, with private networking between them.
• You need US or Asian regions.
• Your database needs custom configuration or a Postgres image you control.
• You want HA with automatic failover on a self-sized cluster.
• Your workload is so small or idle that usage billing costs less than any plan.

#When StitchDB is the better choice

• You want point-in-time recovery, single-table restore and a recycle bin without configuring anything (Backups).
• You need Auth, file storage and realtime, and don't want to run them as separate services.
• You want the frontend to query the database directly, with Row Level Security doing authorization.
• You prefer a flat bill with a hard cap (spend cap).
• Your users are in Europe.

#Migrating Railway Postgres to StitchDB

1. In Railway, enable public networking on the Postgres service to get DATABASE_PUBLIC_URL.
2. Run StitchDB's Import from Postgres with that URL, or dump and restore:

pg_dump "$DATABASE_PUBLIC_URL" -Fc --no-owner --no-privileges -f railway.dump
pg_restore --no-owner --no-privileges \
  -d "postgresql://p_<ref>_owner:<password>@<db-host>:5432/p_<ref>?sslmode=require" railway.dump

3. Update the DATABASE_URL variable on your Railway services and redeploy.
4. Turn Railway's public access off again, and remove the old database once you are confident.

More options in Railway database alternatives.

#Security model differences

Railway keeps databases private by default: services in the same project reach Postgres over Railway's private network, and nothing outside can connect. When you need outside access (your laptop, a BI tool, a migration), you enable public networking, which creates a TCP proxy and a DATABASE_PUBLIC_URL. From then on, the database password is the main barrier, so turn public access off again when you are done.

StitchDB puts every database behind a pooler that requires TLS 1.2 or 1.3 and checks the password before anything reaches Postgres. On Pro and up you can add an allowlist of up to 50 IPv4 addresses or ranges for ports 5432 and 6543; the APIs and Studio are not affected by it (Connect).

The bigger difference is at the API level. StitchDB has two keys: an anon key that is safe in browser and mobile code, and a service_role key that bypasses Row Level Security and must stay on servers. With RLS on every table, a browser can query the database directly and only see its own rows:

alter table public.invoices enable row level security;

create policy "customers see their invoices" on public.invoices
  for select to authenticated
  using (customer_id = auth.uid());

On Railway you get the same safety by writing that check in your API code. Both work; one keeps the rule next to the data.

#FAQ

#Can I host my API on StitchDB instead of Railway?

Partly. Edge Functions run TypeScript or JavaScript on Deno, and the REST and GraphQL APIs cover CRUD. Long-running servers, custom containers and other languages belong on a platform like Railway.

#Is Railway Postgres managed?

Railway describes its template as a single node it maintains. Backups and HA are features you turn on. If you change the template, the database is yours to manage.

#Which is cheaper?

For a steady small production database, StitchDB Pro at $15.99 is usually less than equivalent Railway usage. For tiny or mostly idle databases, Railway can cost less (as of November 2026).

#Does StitchDB have a region near Railway's EU West?

Railway's EU region is Amsterdam; StitchDB's data centers are in Germany and Finland, a short distance away compared with a US region.

#Does Railway or StitchDB handle Postgres upgrades?

Railway maintains the node its template deploys; if you modify the template, upgrades become your job. On StitchDB the platform runs the database for you, and your connection strings stay the same for the life of the project, including when a project moves to another server. Either way, test your app against a copy before a major version change.

Running apps on Railway? Add a free StitchDB project for the database and auth.