Advanced Database Platform

A Railway-focused skill for provisioning, configuring, and managing databases on the Railway cloud platform. Advanced Database Platform handles database plugin deployment, connection string management, environment variable wiring, and migration execution across PostgreSQL, MySQL, Redis, and MongoDB on Railway.

When to Use This Skill

Choose Advanced Database Platform when:

• Provisioning a new database on Railway (Postgres, MySQL, Redis, MongoDB)
• Managing database connection strings and environment variable references
• Running migrations against Railway-hosted databases
• Configuring database replicas, backups, or scaling parameters

Consider alternatives when:

• You're using a different cloud provider (AWS RDS, Supabase, PlanetScale)
• You need database schema design guidance (use a general database design skill)
• You're managing local development databases (use Docker Compose)

Quick Start

Copy
claude "Add a PostgreSQL database to my Railway project"

Copy
# Install Railway CLI if needed
npm install -g @railway/cli

# Login and link to your project
railway login
railway link

# Add PostgreSQL plugin
railway add --plugin postgresql

# View connection details
railway variables

# Connect to the database
railway connect postgresql

Copy
// Use the auto-injected environment variables
import { Pool } from 'pg';

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  ssl: { rejectUnauthorized: false }
});

Core Concepts

Available Database Plugins

Database	Plugin Name	Default Port	Use Case
PostgreSQL	postgresql	5432	Relational data, complex queries
MySQL	mysql	3306	Legacy app compatibility
Redis	redis	6379	Caching, sessions, queues
MongoDB	mongodb	27017	Document storage, flexible schemas

Environment Variables (Auto-injected)

Copy
# PostgreSQL variables injected by Railway
DATABASE_URL=postgresql://user:pass@host:port/railway
PGHOST=containers-us-west-xxx.railway.app
PGPORT=5432
PGUSER=postgres
PGPASSWORD=<generated>
PGDATABASE=railway

# Redis variables
REDIS_URL=redis://default:pass@host:port
REDISHOST=containers-us-west-xxx.railway.app
REDISPORT=6379
REDISPASSWORD=<generated>

Migration Workflow

Copy
# Run migrations against Railway database
railway run npx prisma migrate deploy

# Or with raw SQL
railway run psql $DATABASE_URL -f migrations/001_init.sql

# Check migration status
railway run npx prisma migrate status

Configuration

Parameter	Description	Default
database_type	PostgreSQL, MySQL, Redis, or MongoDB	postgresql
region	Railway deployment region	us-west1
high_availability	Enable replica for failover	false
backup_schedule	Automated backup frequency	daily
max_connections	Connection pool limit	100

Best Practices

1. Use DATABASE_URL for connection strings. Railway injects this variable automatically — hardcoding connection details makes your app non-portable. Reference the environment variable in your ORM configuration so the same code works across environments.

2. Run migrations through railway run. This ensures migrations execute with the correct environment variables and network access. Running migrations locally against a Railway database requires TCP proxy setup which adds unnecessary complexity.

3. Configure connection pooling at the application level. Railway databases have connection limits. Use a connection pooler like PgBouncer or your ORM's built-in pool (Prisma's connection pool, TypeORM's pool settings) to prevent "too many connections" errors.

4. Set up volume persistence for production databases. Railway's ephemeral filesystem means database data can be lost on redeploy without a persistent volume. Attach a volume to your database service for production workloads.

5. Use Railway's private networking between services. When your app and database are in the same Railway project, use internal hostnames (*.railway.internal) instead of public URLs. This reduces latency and avoids egress charges.

Common Issues

"Too many connections" error during deployment. Railway's default PostgreSQL has a 100-connection limit. If you have multiple service replicas or background workers, connections add up fast. Add connection pooling with max: 10 per service instance, and close idle connections with a timeout.

Migrations fail with "connection refused." If running locally, you need to use Railway's TCP proxy: railway connect postgresql opens a local proxy. If running in CI, ensure the build command uses railway run to inject environment variables. Check that the database plugin is actually deployed and healthy.

Data loss after redeployment. Without a persistent volume, Railway treats storage as ephemeral. Verify your database service has a volume attached: go to the database service settings in the Railway dashboard and confirm volume configuration. For existing services, add a volume and migrate data from a backup.