Scheduled start and stop is in the product.
Every managed database can stop and start on a schedule: pick a preset or your own days and times in the console, in your local time. A three-broker Kafka cluster stops and starts as one and the MCP server sets the same schedules from your editor.
It shipped as a start and stop schedule per database rather than the cron expressions proposed below. A stopped database stops its compute charge; its storage, snapshots and backups keep billing.
The original proposal: Database Job Scheduler
Schedule Your Databases
Cut Dev Costs by 70%
AWS RDS requires stitching together Lambda and EventBridge just to schedule start/stop and even then, instances auto-restart after 7 days, quietly erasing your savings. Other providers either lock you into their ecosystem or rely on idle-based scaling that is not predictable for real workflows. Selfhost.dev builds scheduling in natively: simple, reliable and cross-provider, so your databases run only when needed, cutting dev and staging compute costs by up to 70% without extra infra or maintenance.
7 days
Forced auto-restart window in AWS RDS that breaks long-term shutdown savings
DIY only
Scheduling requires stitching Lambda + EventBridge, no native support
Idle ≠ predictable
Idle-based scaling in Neon / Amazon Aurora Serverless v2 does not match fixed team usage hours
What idle databases are actually costing you
The same database. The same workload. The only difference is whether it’s running when no one needs it.
Runs 24/7 by default, even during nights, weekends and zero-traffic hours
Runs only during active usage hours, automatically stopped when idle
What you're actually dealing with
Database providers give partial solutions. None give a clean, universal scheduling layer.
Existing Tools
- Azure SQL Managed Instance: Built-in scheduling, but limited to Azure ecosystem
- Amazon Aurora Serverless v2: Auto-pause works, but only for compatible workloads
- Neon: Scale-to-zero is elegant, but idle-based, not time-based
- AWS RDS: Requires Lambda + EventBridge setup, with forced restart after 7 days
- Result: You either compromise on flexibility or build and maintain your own scheduling system.
After Selfhost.dev
- Unified cron-based scheduling across all databases
- No infra glue (no Lambda, no EventBridge, no scripts)
- Works for dev, staging and predictable production workloads
- Result: Your database runs only when your team does.
How Selfhost.dev is planning to solve this
Simple on the surface. Reliable under the hood.
Layer 1 of 3
Scheduling Layer
Time-Based Control
- Define start/stop windows using familiar cron expressions, giving you precise control over when each database should run based on actual team usage patterns, not assumptions.
- Attach multiple schedules to the same database (e.g., weekdays vs weekends), allowing flexible control without needing separate setups or manual switching.
- Ensure timezone-aware execution so databases align with your team’s working hours, even if your infrastructure and team are distributed globally.
What all is included
The full capability set, end to end.
Additional capabilities:
Help this reach further.
The more input we get, the better we build. Share this idea and bring in more voices.
Shipped as Scheduled start and stop
Tell us what it still needs with the suggestion form above.
Browse
Other ideas to
explore.
Database Storage Downsizing
AWS locks storage at its peak - once autoscaling bumps up your volume, you pay for that size forever. Selfhost.dev can shrink it back transparently, something RDS structurally cannot do.
Cost Monitoring
AWS Cost Anomaly Detection waits up to 24 hours. Selfhost.dev flags active cost anomalies in 5-15 minutes, maps the likely culprit even with incomplete tags and gives your team context to act before the bill compounds.
Database Cost Comparison
No tool combines performance benchmarks, instance pricing and feature gaps in one place. Define your workload and see exactly what you would pay and get across every major provider.