MongoDB development
Build scalable, high-performance applicationswith MongoDB and modern database architecture
MongoDB works well when the data your application reads belongs together in a single document. It works badly when treated as a relational database without joins. We design schemas around your real queries, tune what exists and plan version upgrades.
What MongoDB work covers
Schema design in MongoDB starts from the queries, which is the reverse of relational design.
Schema design
Deciding what to embed and what to reference from how the application reads and writes data, and writing down the access patterns as we go.
Performance tuning
Using explain() and the profiler to find collection scans and poor indexes, and fixing documents that have grown too large.
Version upgrades
Moving replica sets and sharded clusters to a supported release, including driver updates and the feature compatibility step.
Moving to or from Atlas
Planning a move between self-managed servers and Atlas, or moving data to a relational database if MongoDB turned out to be the wrong fit.
MongoDB versions, as of October 2026
From MongoDB's lifecycle schedule for Enterprise Advanced. Atlas dates can differ.
9.0 is the current major
Released in September 2026, with end of life on 31 October 2031. New projects should start here unless a driver or host holds them back.
8.0 and 7.0 are still supported
8.0 runs to 31 October 2029 and 7.0 to 31 August 2027. A 7.0 deployment has under a year left, so its upgrade should be scheduled.
6.0 and older have ended
6.0 reached end of life on 31 July 2025, and 5.0 on 31 October 2024. 8.2 has also ended, on 31 July 2026.
Where MongoDB fits
Its limits are documented, and they should inform the decision.
A good fit
Data read as a whole, with a shape that varies: product catalogues with differing attributes, content, or event-style records. Single-document writes are atomic, which covers much of what you need.
A poor fit
Heavily relational data with many transactions across records, such as accounting. Transactions exist, but MongoDB's docs warn they cost more and aren't a replacement for good schema design.
Hard limits
A BSON document can't exceed 16 mebibytes or 100 levels of nesting. Arrays that grow without limit reach this eventually, so the schema has to plan for it.
Licensing
Server versions since October 2018 use the SSPL, while drivers use Apache 2.0. For most applications this has little effect. If you offer the database as a service, take legal advice.
How MongoDB work runs
It begins with what the application asks of the database.
List the access patterns
We write down each query and update, and how often it runs. This list, and not the entity diagram, shapes the schema.
Model and test with real sizes
We load realistic volumes, so document growth and index size show up before launch and not a year after it.
Index for those queries
Each index has to justify itself against the write cost. Unused indexes are removed, and new ones are built carefully on live clusters.
Upgrade with care
Binaries come first and the feature compatibility version is raised later, after a settling period, because raising it limits your way back.
How to engage us on MongoDB
A review of an existing database is a good, small place to start.
A schema and index review is a contained piece of work that we can quote after seeing your slow-query data and collection sizes. Larger work runs by the hour, from $20/h in USD, invoiced in USD, GBP, EUR or INR, or with a developer in your team.
We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment. We can work through a difficult upgrade step with your engineers on a call. Node.js is a common pairing, covered on our Node.js page.
Why we don't name MongoDB clients
Most of our work is delivered under NDA, so many projects cannot be named.
Data work is covered by the same agreements, and we don't publish any detail about client data. So this page is about method, and you can test that method on a sample of your own query logs.
Questions about MongoDB
Asked by teams deciding on it or having trouble with it.
Should we use MongoDB or PostgreSQL?
Can we skip versions when upgrading?
What happens after raising the feature compatibility version?
Our MongoDB is slow. Do we need to shard?
Send us your slowest queries
Or tell us which MongoDB version you run and where. We will explain what stands out and what we would look at next.
We reply within one business day (IST).