The database question comes up at every Indian startup at some point. You've been running PostgreSQL on a VM, it's working, and someone suggests moving to a managed database service. Or you're starting fresh and trying to decide. Here's a practical framework for making the right call.
What Running Your Own Database Actually Involves
Self-hosted databases feel simple at first. Install PostgreSQL, configure it, connect your application. But production database operations are a different exercise entirely.
Backups. You need automated backups, backup verification (backups that haven't been tested are not backups), retention policies, and a tested restore procedure. This is typically a week of engineering work to set up correctly and ongoing operational overhead to maintain. High availability. A single database instance is a single point of failure. Setting up PostgreSQL streaming replication with automatic failover (using Patroni or similar) is a multi-day project that requires ongoing maintenance as PostgreSQL versions change. Monitoring. Query performance, connection counts, replication lag, disk usage, lock contention — each requires monitoring, alerting, and someone who understands what the alerts mean. Version upgrades. PostgreSQL major version upgrades require careful planning and execution. pg_upgrade or logical replication upgrade strategies each carry risk and require downtime windows or complex cutover procedures. Security patches. CVEs affecting PostgreSQL or the underlying OS need to be applied promptly. Each patch carries risk and requires a maintenance window. Capacity planning. Disk fills up. Connections get exhausted. IOPS limits get hit. Someone needs to monitor trends and plan ahead.None of this is impossible. But each item is a specialised skill, and collectively they represent a significant ongoing time commitment.
What DBaaS Takes Off Your Plate
A managed database service handles:
- •Automated backups with point-in-time recovery (restore to any second in the past 7–35 days)
- •High availability with automatic failover — typically under 30 seconds
- •Automated minor version upgrades and security patches
- •Vertical and horizontal scaling through a control panel, not a runbook
- •Read replicas for read-heavy workloads
- •Connection pooling
- •Performance insights and query analysis
The Incident Cost Calculation
The real cost of self-hosted databases shows up in incidents.
A database corruption incident on a self-hosted setup typically involves: discovering the incident (15–30 minutes if you have good monitoring, longer if you don't), diagnosing the problem (30 minutes to several hours), executing recovery from backup (1–4 hours depending on database size and backup strategy), verifying data integrity, and communicating with stakeholders throughout.
Call it 6–8 hours for a senior engineer who knows what they're doing. At ₹3,000/hour, that's ₹18,000–24,000 in engineering cost for a single incident — not counting the revenue impact of downtime.
DBaaS reduces the frequency of these incidents dramatically. Automatic failover means most node failures result in 30 seconds of disruption rather than hours of recovery. Point-in-time recovery means data corruption is a restore operation rather than a crisis.
When Self-hosted Makes Sense
Very large databases. At multi-terabyte scale, managed database pricing can become prohibitive. Large data warehousing workloads often benefit from self-managed setups with custom hardware configurations. Unusual engines or extensions. If you need PostgreSQL extensions that managed services don't support, or database engines that aren't offered as managed services, self-hosted may be necessary. Air-gapped environments. Highly regulated environments that require complete isolation sometimes cannot use managed cloud services. Cost sensitivity at early stage. For a very early stage startup with a tiny database and a founder-engineer who enjoys database administration, self-hosted on a single instance can be cheaper. The math changes quickly as the team grows and the database becomes business-critical.Making the Decision
For most Indian engineering teams:
- •Pre-product-market-fit: Self-hosted on a single instance is fine. The risk is low, the cost is minimal, and you learn a lot.
- •Post-PMF, growing team: Move to DBaaS. Your database is now business-critical, your team has more important things to do than database operations, and incidents are expensive.
- •Enterprise/regulated: DBaaS with India data residency, SLA guarantees, and compliance documentation.