Diagnosing and Scaling a Scalingo Managed PostgreSQL Database: A Practical Guide

The Problem: Running Out of PostgreSQL Storage on Scalingo

When your application's database hits the 10 MB limit of the default Hobby plan, you'll encounter write failures and potential data loss. The challenge is identifying whether you're constrained by storage, performance, or configuration—and then taking corrective action without downtime.

Recognizable Conditions

• Write errors in logs: Messages like "disk full" or "cannot add new records" indicate storage exhaustion.
• Slow query performance: Response times degrade as the database struggles with limited resources.
• Backup failures: Automated backups may fail when storage is nearly full.
• Application crashes: Database connection timeouts during peak usage.

Quick Diagnostic Table

Symptom	Potential Cause	Diagnostic Command
Write failures	Storage limit reached	scalingo db:info <app>
Slow queries	Insufficient memory/CPU	scalingo logs --app <app>
Backup issues	Near capacity or plan limits	scalingo db:backup <app>

Step-by-Step Checks

1. Check current plan and storage usage:

   scalingo db:info my-app-name
   # Look for: Plan, Storage Used, Storage Limit

   Run this from your terminal with Scalingo CLI installed and authenticated.
2. Verify backup status:

   scalingo db:backup my-app-name
   # Confirm last backup timestamp and success

   This lists available backups and helps identify if the backup system is functioning.
3. Review application logs for database errors:

   scalingo logs --app my-app-name --lines 100
   # Search for database-related error messages

   Look for patterns indicating connection issues or disk space warnings.
4. Monitor performance metrics:

   scalingo metrics my-app-name
   # Check CPU, memory, and disk usage trends

   This helps determine if you need more resources beyond just storage.

Applying Fixes Based on Findings

If storage is the issue: Upgrade to a larger plan that provides more storage. The Professional plan offers 1 GB storage compared to the Hobby's 10 MB.

# Upgrade from Hobby to Professional plan
scalingo db:upgrade my-app-name professional
# Verify the change
scalingo db:info my-app-name

If backups are failing: Create a manual snapshot before making changes, then export it as a safety measure.

# Create manual backup
scalingo db:create-backup my-app-name
# List backups to confirm
scalingo db:backup my-app-name

If performance is poor: Consider upgrading to a plan with more CPU and memory resources, even if storage isn't fully utilized.

Escalation Criteria

• Immediate escalation: If you see "disk full" errors preventing writes, upgrade immediately to prevent data loss.
• Scheduled escalation: If performance degrades gradually, plan an upgrade during low-traffic periods.
• Backup verification: After any upgrade, verify that automated backups resume successfully.

Important Considerations

Downtime during scaling: While Scalingo performs in-place migrations without full downtime, there may be brief pauses in write traffic (typically seconds) during plan upgrades.

Backup retention: Automated daily backups are retained for 30 days. Manual snapshots can be exported and stored independently for longer retention.

Connection stability: The DATABASE_URL environment variable provides a stable endpoint that persists across dyno restarts, with TLS encryption enabled by default.

Verification Steps

1. After upgrading, run scalingo db:info to confirm the new plan is active.
2. Check that your application can still connect using the DATABASE_URL environment variable.
3. Verify backups are running by checking the backup list after 24 hours.
4. Monitor application performance to ensure the upgrade resolved the issue.

Limitations and Next Steps

Scalingo's managed PostgreSQL service abstracts many database administration tasks, but you still need to monitor usage patterns and plan ahead for growth. The 30-day backup retention may not meet all compliance requirements—consider exporting critical backups to external storage for long-term archival.

If you need more control over your database configuration or have specific performance requirements, consider using a dedicated database service or self-managed PostgreSQL instance.