Professional MongoDB Administration for Web Applications
Imagine your web application starts slowing down—pages take 10 seconds to load, and the logs are full of slow MongoDB queries. Customers complain, and you can't figure out why. Most often, the cause is missing proper indexes or a suboptimal replica set configuration. We help companies avoid such situations, providing turnkey MongoDB administration. Contact us for a MongoDB audit—we'll assess the current state and propose a plan.
Recently, we assisted an e-commerce store with 50,000 products. The database was MongoDB 6.0 with a three-node replica set. After the audit, we discovered that 30% of indexes were unused, and the oplog size was only 1 GB—under heavy writes, replication lag reached 2 hours. We optimized indexes, increased oplog to 10 GB, and configured monitoring. Database response time dropped tenfold.
How Does a MongoDB Audit Work?
We start with diagnostics. We collect statistics on databases, collections, and indexes using db.stats() and db.collection.stats(). We identify unused or inefficient indexes via $indexStats. We check the replica set configuration and oplog size. The result is a map of bottlenecks.
Here is a typical script for initial data collection:
// mongosh use mydb // Database statistics db.stats({ scale: 1024 * 1024 }) // Collection statistics db.runCommand({ listCollections: 1 }).cursor.firstBatch.forEach(c => { const stats = db[c.name].stats({ scale: 1024 }) printjson({ name: c.name, docs: stats.count, size_kb: stats.size, storageSize_kb: stats.storageSize, totalIndexSize_kb: stats.totalIndexSize, nindexes: stats.nindexes }) }) // Index sizes for a collection db.orders.stats().indexSizes // Currently running operations (>1 second) db.currentOp({ "secs_running": { $gt: 1 } }) How Do We Optimize Queries?
The first step is creating proper indexes. We use compound indexes for typical queries, partial indexes for filtering active records, TTL indexes for automatic deletion of outdated data. Examples:
// Compound index for a typical query by user and date db.orders.createIndex( { user_id: 1, created_at: -1 }, { background: true, name: "idx_user_date" } ) // Partial index—only for active orders db.orders.createIndex( { created_at: -1 }, { partialFilterExpression: { status: { $in: ["pending", "processing"] } }, name: "idx_active_orders_date" } ) // TTL index for automatic deletion of expired sessions db.sessions.createIndex( { expires_at: 1 }, { expireAfterSeconds: 0, name: "ttl_sessions" } ) We verify index usage via $indexStats and analyze query plans with .explain("executionStats"). If we see a COLLSCAN with a large document count, an index is urgently needed. More on index creation can be found in the official MongoDB documentation.
A compound index can speed up queries 100x compared to a full collection scan, while partial indexes take up 60% less space and speed up writes.
How to Configure Replica Set and Monitoring?
Replica set setup consists of 4 steps:
- Initialize the set with an ID.
- Add members: primary, secondary, arbiter.
- Configure priorities to manage primary elections.
- Check status and test failover.
Here is an example initialization:
rs.initiate({ _id: "rs0", members: [ { _id: 0, host: "mongo1:27017", priority: 2 }, { _id: 1, host: "mongo2:27017", priority: 1 }, { _id: 2, host: "mongo3:27017", arbiterOnly: true } ] }) Why Is Correct Oplog Size Important?
The oplog is an operation log that allows secondary nodes to synchronize with the primary. If the oplog is too small, secondaries may fall behind and lose sync. We recommend an oplog size covering at least 6 hours of peak write activity. To calculate: oplog size = (average write rate in bytes/s) × 3600 × 6. In our e-commerce case, increasing oplog from 1 GB to 10 GB solved the replication lag issue.
How Do We Handle Backups and Restores?
For databases up to a few GB, we use mongodump from a secondary with --oplog for consistency. For larger databases (>100 GB), we use file system snapshots (LVM, EBS). We test restores monthly to ensure data integrity.
Backup method comparison:
| Method | Suitable for | Recovery time | Consistency |
|---|---|---|---|
| mongodump | < 100 GB | Depends on size | Point-in-time with --oplog |
| File snapshot | > 100 GB | Fast (minutes) | Requires write halt |
Summary: What's Included
| Stage | What we do | Result |
|---|---|---|
| Audit | Collect metrics, analyze indexes and queries | Report with recommendations |
| Design | Schema, indexes, replica set, sharding | Architecture documentation |
| Setup | Indexes, replica set, monitoring, backups | Working configuration |
| Testing | Load testing, failover verification | Test report |
| Deployment | Roll out to production, hand over access | Configured system |
| Support | 24/7 monitoring, alert response | Stability guarantee |
How Long Does It Take?
Timelines depend on complexity: basic audit takes 2–3 days, full replica set setup with indexes and monitoring takes 5–7 days. We estimate projects individually—contact us for a precise quote.
Why Trust Us with MongoDB Administration?
With 7+ years of experience and over 40 successful MongoDB optimization projects, we don't just configure the database—we ensure it handles the load. We use only stable versions (MongoDB 7.0+, WiredTiger) and apply patterns like Repository and BFF to reduce load. Our engineers hold MongoDB certifications.
Get a consultation for your project—we'll assess the current state and propose a plan.