Host PostgreSQL with AZIN

AZIN provisions managed PostgreSQL directly in your cloud account. On GCP, you get Cloud SQL. The database runs in your VPC, encrypted at rest, with automated backups — and your data never touches a third-party vendor.

#How it works

Add a postgres service to your azin.yaml. AZIN provisions the managed instance in your cloud account and injects the connection string as DATABASE_URL. Your app connects like it would to any Postgres database.

# azin.yaml
name: my-app
services:
  web:
    build:
      type: railpack
    cloud: gcp
    region: europe-west4
    env:
      DATABASE_URL: "@db.url"
    scaling:
      min: 1
      max: 5
      target_cpu: 70
 
  db:
    type: postgres
    version: "17"
    plan: production
    cloud: gcp
    region: europe-west4
    storage: 20
    # Provisions Cloud SQL PostgreSQL in your GCP account

That is the entire config. AZIN handles the provisioning, security groups, and connection string injection.

#What you get

The underlying managed Postgres service (Cloud SQL) provides production features out of the box:

• Automated daily backups with configurable retention
• Point-in-time recovery — restore to any second within the backup window
• Encryption at rest (AES-256) and in transit (TLS)
• Read replicas for scaling read-heavy workloads
• Connection pooling via PgBouncer or Cloud SQL Auth Proxy
• High availability with regional failover (production plan)
• Automated minor version patches during maintenance windows

These are native cloud provider features. AZIN does not reimplement them — it provisions the managed service and lets your cloud provider handle the rest.

#Managed PostgreSQL vs self-hosted

Running Postgres in a Docker container works for local development. In production, it means you own backup scheduling, failover, patching, disk monitoring, and connection pooling.

Managed Postgres (Cloud SQL) handles all of that. The trade-off is cost — a managed instance costs more than a bare VM running Postgres. But the operational overhead of self-hosting a production database is significant, and a single missed backup or failed disk is a data loss event.

With AZIN, you get managed Postgres without the vendor lock-in. Cloud SQL is a commodity — if you leave AZIN, your database stays in your cloud account untouched.

#Connecting from your application

AZIN injects DATABASE_URL as an environment variable. Most frameworks read it automatically.

# Django — settings.py
import dj_database_url
 
DATABASES = {
    "default": dj_database_url.config(default=os.environ["DATABASE_URL"])
}

// Node.js — using pg
import pg from "pg";
const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
  ssl: { rejectUnauthorized: false },
});

# Rails — config/database.yml
production:
  url: <%= ENV["DATABASE_URL"] %>

No connection string hardcoding. No secrets in your repo. The DATABASE_URL is scoped to your service and injected at runtime.

#PostgreSQL hosting compared

As of February 2026, these are the main options for hosting Postgres:

The trade-off is clear. Neon and Supabase offer the cheapest entry with serverless free tiers. Railway is the cheapest persistent PaaS database. Render's free Postgres expires after 30 days — reduced from 90 days in May 2024 — after which you upgrade to $55/mo or lose your data.

AZIN sits in a different category: you pay your cloud provider's Cloud SQL rates directly, with no markup on the database itself. Cloud credits (Google for Startups) apply to your Postgres bill. Your data stays in your VPC, inheriting your cloud account's SOC 2, HIPAA, or ISO certifications without evaluating a third-party vendor.

#What managed PostgreSQL costs on GCP

If you provision Postgres through AZIN on GCP (Cloud SQL), you pay the cloud provider directly. AWS and Azure support is on our roadmap. As of February 2026:

GCP Cloud SQL PostgreSQL (us-central1, Enterprise):

Plus $0.222/GB-month for SSD storage.

These rates are significantly lower than PaaS markups. Render charges $55/mo for a Postgres instance that would cost ~$26/mo on Cloud SQL directly.

#Running migrations

A CLI (azin run) is on our roadmap and will let you execute one-off commands against your service environment. The planned interface looks like this:

# Run Django migrations
azin run web -- python manage.py migrate
 
# Run a Rails migration
azin run web -- rails db:migrate
 
# Run a raw SQL file
azin run db -- psql -f schema.sql

The command will run in the same network as your database, with DATABASE_URL available. No SSH tunnels, no port forwarding.

#Related guides

• Deploy Docker containers with AZIN — Container deployment guide
• Deploy Django with AZIN — Django uses Postgres by default
• Railway vs Render — Database hosting comparison
• AZIN vs Render — Render's 30-day Postgres expiration
• Best Heroku alternatives in 2026 — Heroku Postgres users migrating

#Frequently asked questions