Database technologies
The database decision you can't easily undo.
Schema and index design will affect your application longer than any framework choice.
Databases outlive applications. We default to PostgreSQL unless there's a specific reason not to, because a relational database with good indexes handles far more than people expect — and the alternatives usually solve a problem you don't have yet.
What we use
And why we picked each one.
PostgreSQL
The most capable open-source relational database.
WhyOur default. JSON columns, full-text search and vector support mean it covers cases people reach for other databases to solve.
MySQL
The most widely deployed open-source relational database.
WhyIncluded on Hostinger and most shared hosting, so it's often the pragmatic choice for Indian SME deployments.
MongoDB
Document database with a flexible schema.
WhyGenuinely useful for varying document shapes — catalogues, logs, CMS content. Frequently chosen for the wrong reasons.
Redis
In-memory data store.
WhyCaching, sessions, rate limiting and job queues. Rarely the primary store, almost always present.
Elasticsearch
Search and analytics engine.
WhyWhen you need real search — relevance ranking, typo tolerance, faceting — that a LIKE query can't approximate.
pgvector
Vector similarity search inside PostgreSQL.
WhyFor RAG and semantic search, this avoids running a separate vector database until your scale genuinely demands one.
SQLite
Embedded single-file database.
WhyOffline-first mobile and desktop apps. Enormously capable and consistently underrated.
Comparison
PostgreSQL vs MySQL vs MongoDB
Including what to watch out for in each. There is no option without a downside.
| Option | Strengths | Watch out for |
|---|---|---|
| PostgreSQL | Richest feature set — JSON, full-text, vectors, window functions, strict constraints. | Slightly more operational knowledge required; fewer cheap shared hosts. |
| MySQL | Everywhere, well understood, excellent read performance, included in most hosting. | Weaker on advanced query features and data-integrity guarantees. |
| MongoDB | Flexible schema suits genuinely varying documents; easy horizontal scaling. | Loses relational integrity; teams often pick it to avoid schema design, and pay later. |
How we choose
Four criteria, in this order.
Fit
Does it solve your actual problem, or a more interesting one?
Hiring pool
Could you hire for it in India if you took the project in-house?
Total cost
Licences, hosting and the operational time to run it — not just build cost.
Exit risk
How hard would it be to leave? We don't build things you can't walk away from.
Services
What we build with it.
- 01Custom Software DevelopmentSoftware built for how your business actually works.
- 02Web Application DevelopmentComplex, data-heavy applications that stay fast at scale.
- 03API DevelopmentVersioned, documented APIs your partners can build on.
- 04Cloud SolutionsMigration and architecture that cuts your monthly bill.
SQL unless you have a specific reason. Most projects that chose NoSQL to 'move fast' end up rebuilding relational integrity in application code — which is slower and less reliable than letting the database do it.
Usually not at first. pgvector inside PostgreSQL handles millions of vectors comfortably, and keeping one database is a large operational saving. Move to Pinecone or similar when scale genuinely demands it.
Usually. Most slowness is a handful of missing indexes or N+1 queries rather than an architectural problem. We start with a paid audit that identifies where the time actually goes.