Service

Database Development

The database is where software either ages well or falls apart. I design, optimize and repair data layers — schemas, relationships, queries and migrations — mostly in PostgreSQL, plus MySQL and MongoDB where they fit.

What I do

Choosing the right database

PostgreSQL is my default for applications: reliable, structured, and strict enough to catch data problems early. MongoDB fits genuinely document-shaped data and rapid prototypes. MySQL is common in hosting environments across Nepal and perfectly workable. The honest answer is that for most business software, the boring relational choice wins — I'll tell you when it doesn't.

Databases inside real products

Every serious project I ship leans on deliberate data modelling: LAHAN Hub coordinates 21 Django applications over one PostgreSQL layer, and Lafzloom models user-generated multilingual content with moderation states. The Django, React and PostgreSQL article shows how the data layer drives everything else.

Frequently asked questions

PostgreSQL, MySQL or MongoDB — which should we use?

For most business applications: PostgreSQL. If your hosting only supports MySQL comfortably, that's fine too. MongoDB earns its place for document-shaped or rapidly changing data. We'll decide based on your data, not fashion.

Can you fix a slow existing database?

Usually. I profile the queries, examine indexes and schema, and fix the biggest costs first. You get before/after measurements, not vague promises.

Can you migrate our data from spreadsheets or an old system?

Yes — exporting, cleaning and importing data is standard work at the start of custom software projects. The messy 10% of your data usually takes most of the care.

Do you handle backups?

I design backup strategy and set up automated backups as part of deployment — and verify that restores actually work, which is the part everyone forgets.

Next step

Data problems?

Describe your situation — new schema, slow queries or a risky migration. I'll assess it before proposing work.