Backups, hosting choices, and the boring database decisions that keep Nepali business systems alive.
Every Nepali business system that matters — HRM, inventory, billing, school records — lives in a database, and almost every database disaster is self-inflicted: no backups, backups on the same disk, or nobody knowing the password when the developer moves on.
The three boring decisions
- Who owns the data? The business, not the developer. Get credentials, exports and schema documentation in writing at handover.
- Where does it run? Same server as the app is fine to start; separate it when uptime matters. Managed options (cloud SQL services) cost more but make backups and point-in-time recovery someone else’s job.
- How do you restore? Keep automated daily backups, one copy off-server, and actually test a restore. Write the steps down; the person doing it in a crisis may not be the person who set it up.
Sizing and hygiene
PostgreSQL and MySQL both run fine on modest hardware; most Nepali business workloads are tiny by cloud standards. The usual local failure mode isn’t scale — it’s entropy: no migration history, manual edits on production, and a spreadsheet running the real process alongside the database. Migrations belong in version control; spreadsheets belong in the database.
Security basics that get skipped
Strong passwords and non-default ports are table stakes; the real fixes are backups, least-privilege users (the app account shouldn’t be admin), encrypted connections where the data is sensitive, and removing test accounts. Nepal’s data-protection conversation is maturing — treat customer records as liabilities you’re holding, not assets.
FAQ
Where should a Nepali business host its database?
Wherever the application is. Local VPS for Nepal-only latency, or managed cloud (with automated backups) when the data matters more than the latency — which is almost always. The deciding factor is whether someone is accountable for backups.
How often should we back up?
Enough that losing a day of data is survivable: daily at minimum for business systems, with at least one copy stored outside the same server. Test a restore quarterly — an untested backup is a hope, not a backup.