— Enterprise MongoDB Consultative Support —
MongoDB Consultative Support for Mission-Critical Workloads
24×7 Expert DBA Coverage | Replica Sets & Sharding | WiredTiger Tuning | Backup & PITR
MinervaDB delivers principal-level MongoDB Consultative Support to organisations that cannot tolerate downtime, silent data loss or unexplained tail latency. We engineer, tune and operate MongoDB estates from a single replica set to globally distributed sharded clusters across bare metal, Kubernetes and every major cloud — measured against explicit service level objectives rather than best-effort promises.
The MinervaDB Difference
Why Enterprises Choose MinervaDB for MongoDB Consultative Support
MongoDB carries an enormous amount of operational weight in a modern estate: customer profiles, catalogues, carts, sessions, telemetry, feature stores and the event tables behind analytics pipelines. It earns that position by being fast, flexible and schema-flexible, and it keeps that position only while the document model, index set and cluster topology still match the workload that actually runs.
It becomes hostile when they no longer do. An array grows without a bound until documents approach the 16 MB ceiling. A working set outgrows the WiredTiger cache and every read starts touching disk. A monotonically increasing shard key funnels every insert onto one shard. None of these announce themselves as MongoDB problems. They surface as checkout timeouts, abandoned sessions and dashboards that stopped refreshing.
MinervaDB exists for that gap. Our engineers work at the level of the storage engine, the replication protocol and the query planner, and we translate what we find there into changes your teams can ship. MongoDB Consultative Support from MinervaDB is not a ticket queue. It is a standing engineering relationship with people who have recovered real clusters under real pressure.
Vendor neutral
No licences, no resale, no incentive to oversize
We do not resell software, cloud credits or hardware. Every recommendation is judged on whether it makes your data layer faster, safer or cheaper to run, and we are equally willing to tell you that a change is unnecessary.
Principal engineers
Direct access to senior MongoDB specialists
You talk to the engineer who diagnoses the problem, not to a coordinator who relays it. Our team works daily on replica set behaviour, sharding topology, WiredTiger internals and driver-level failure handling.
Evidence first
Diagnosis before change, always
Every recommendation arrives with the explain output, the serverStatus counters, the oplog evidence or the profiler sample that justifies it. Nothing is changed in production on a hunch.
Whole estate
Self-managed, Kubernetes, Atlas and hybrid
We support MongoDB on bare metal, virtual machines, Kubernetes operators, AWS, Azure, GCP and managed Atlas deployments, including hybrid estates where one application spans several of them.
Reference Architecture
The MongoDB Architecture We Support End to End
Supporting MongoDB properly means understanding every layer between the driver call and the block device, because latency and data loss can originate in any of them. A connection pool that is too small produces the same user-visible symptom as an under-provisioned cache. A read preference that quietly points at a lagging secondary looks exactly like an application bug.
The architecture below is the mental model our engineers use on every engagement. It maps the driver tier, the mongos routing tier, the config server replica set, the sharded data tier and the WiredTiger storage engine that sits underneath every mongod process. Each layer has its own instrumentation, its own failure modes and its own service level objective.
Two properties of this picture matter more than any individual component. First, the config server replica set is the authority for the chunk map: if it is unhealthy, routing degrades even when every shard is perfectly fine. Second, every shard is itself a replica set, so replication health has to be assessed per shard rather than as a single cluster-wide number.
Configuration parameters we review on every engagement
The defaults in MongoDB are reasonable for a laptop and rarely correct for a production estate. These are the settings we validate, document and put under change control as part of MongoDB Consultative Support.
| Parameter | What it actually controls | How MinervaDB sets it |
|---|---|---|
| storage.wiredTiger.engineConfig.cacheSizeGB | Size of the WiredTiger cache, and therefore how much of the working set stays in memory | Sized against the measured working set, and set explicitly inside containers where the default reads host memory |
| storage.wiredTiger.collectionConfig.blockCompressor | Block compression algorithm for collection data | snappy where latency dominates, zstd where storage cost and I/O bandwidth dominate, decided per collection |
| storage.journal.commitIntervalMs | How often journal writes are grouped and flushed | Left at 100 ms unless j:true acknowledgement latency requires a tighter window on financial paths |
| replication.oplogSizeMB | Oplog capacity, which defines the point-in-time recovery window | Derived from the measured oplog write rate multiplied by your realistic detection and decision time |
| settings.electionTimeoutMillis | How long a lost primary goes unnoticed before an election begins | Tuned against the write outage your business can absorb, rather than left as an implicit ten seconds |
| settings.heartbeatIntervalMillis | Liveness probe interval between replica set members | Aligned with the real network characteristics between availability zones or regions |
| settings.catchUpTimeoutMillis | How long a new primary catches up before accepting writes | Balanced between rollback exposure and the time needed to restore write availability |
| members[n].priority and members[n].votes | Which members can be elected, and which can vote | Set so failover lands on a node with the right capacity in the right failure domain |
| members[n].secondaryDelaySecs | A deliberately lagging member as a logical corruption guard | One delayed member per critical replica set wherever the blast radius justifies the hardware |
| readPreference and member tags | Which members serve reads, and how stale those reads may be | Analytics traffic tagged away from the OLTP primary with an agreed maximum staleness |
| Default write concern | The durability contract every write inherits | majority as the floor for business data, majority with j:true for ledgers and audit records |
| maxPoolSize and minPoolSize | Driver connection pool size per application process | Derived from measured concurrency and pod count, never copied from a sample application |
| cursorTimeoutMillis | How long an idle cursor holds server-side resources | Set so long-running reports cannot pin memory and cache indefinitely |
| transactionLifetimeLimitSeconds | Ceiling on multi-document transaction duration | Kept deliberately short, with retry handling for TransientTransactionError verified in the application |
| net.tls.mode | Enforcement of transport encryption | requireTLS across the estate, with certificate expiry tracked as an operational risk |
| security.authorization | Whether role-based access control is enforced at all | Enabled with least-privilege custom roles, and never a shared administrative account |
Scope of Service
What MongoDB Consultative Support Covers
MongoDB Consultative Support is deliberately broader than break-fix cover. It combines an answered phone at three in the morning with the engineering work that stops the phone ringing in the first place. The six workstreams below run in parallel throughout an engagement.
01
Round-the-clock incident response
A named duty engineer, a fifteen-minute response target for Severity-1, and an escalation path that reaches principal engineers within the hour. Every critical incident closes with a written root cause analysis and tracked preventive actions.
02
Proactive detection and capacity forecasting
Golden-signal monitoring wired into your existing stack, thresholds derived from your workload, and growth models that tell you when the working set will outgrow cache or when the oplog window will fall below your recovery objective.
03
Performance engineering
Slow query analysis, plan cache review, index rationalisation, aggregation pipeline rewrites and connection pool tuning, all validated with explain output and profiler evidence before and after the change.
04
Architecture, schema and sharding design
Document model reviews against real access patterns, shard key simulation against real write distributions, replica set topology design for your failure domains, and resharding plans when an earlier decision needs to be undone.
05
Backup, recovery and disaster readiness
Backup strategy validated against a written recovery point and recovery time objective, scheduled restore rehearsals that are actually timed, oplog window monitoring and documented regional failover runbooks.
06
Security, hardening and audit evidence
Authentication modernisation, least-privilege role design, encryption at rest and in transit, field-level encryption where regulation demands it, and the control evidence your auditors will ask for.
Replication and High Availability
Replica Sets, Elections and High Availability Engineering
A three-member replica set is the smallest unit of durability in MongoDB, and almost every availability incident we are called into is a story about how that unit behaved under stress. The protocol itself is sound. What varies between estates is whether the settings around it were ever tuned, and whether anyone has measured what actually happens when a primary disappears.
With default settings, a lost primary is detected through missed heartbeats, an election begins once electionTimeoutMillis expires, a candidate with the highest optime wins a majority vote, and the new primary opens for writes after a catch-up phase. That sequence typically costs ten to twelve seconds of write availability. Whether that is acceptable is a business decision, not a database default.
The failure modes that hurt are rarely the clean ones. Elections that flap because two members share the same priority. Writes acknowledged at w:1 that are silently rolled back when the old primary rejoins. Reads served from a secondary that has been lagging for twenty minutes because nobody alerted on it. Each of these is invisible in an uptime dashboard and extremely visible to a customer.
Replica set behaviour: default versus engineered
| Scenario | What happens by default | What MinervaDB engineers instead |
|---|---|---|
| Primary host is lost | Ten to twelve seconds of write unavailability while an election completes | Election and catch-up timeouts tuned to the written outage budget, with drivers proven to retry cleanly |
| Two members share the same priority | Split votes and repeated elections under network jitter | A deterministic priority ladder so the same node wins predictably in every failure domain |
| Writes acknowledged at w:1 | Acknowledged writes can be rolled back after a failover | majority write concern as the floor for business data, with the rollback exposure measured and reported |
| Secondary falls behind | Reads on secondaryPreferred silently return stale documents | Lag alerting with a maximum staleness bound enforced in the driver, so stale reads fail loudly instead of quietly |
| Analytics queries on the primary | Reporting competes with transactional traffic for cache | Tagged analytics members, with heavy pipelines routed away from the OLTP path |
| A member needs rebuilding | Initial sync competes with production traffic and may never finish | Seeded rebuilds from a snapshot, scheduled in a change window with throughput limits in place |
| Logical corruption from a bad deployment | No safety net beyond the last backup | A delayed member on critical replica sets, giving an hour of live rollback capacity |
| Cross-region deployment | Write latency governed by the slowest voting member | Voting topology and write concern designed together so latency and durability are both explicit |
Durability Engineering
Write Concern, Read Concern and What Acknowledgement Really Means
The most expensive misunderstanding in MongoDB is the belief that a successful write is a durable write. Acknowledgement means exactly what the write concern says it means, and nothing more. A large part of MongoDB Consultative Support is making that contract explicit per collection, and then proving it holds under failure.
A write travels from the driver to the primary, mutates a page in the WiredTiger cache under a document-level intent lock, records an idempotent oplog entry in the same storage transaction, becomes journal-durable at the next group commit, and finally lands in the data files at the next checkpoint. Secondaries fetch and apply that oplog entry, and the majority commit point advances behind them.
Read concern: freshness against latency
Reads are governed independently of writes, and the choice is a real trade-off rather than a best practice to be copied. We set it per query pattern with the business consequence written down.
| readConcern | What you are guaranteed to see | Cost | Where we apply it |
|---|---|---|---|
| local | The most recent data on the node you happen to read, which may later be rolled back | Lowest latency | Non-critical reads where a rare rollback is harmless |
| available | Same as local, and on a sharded cluster it may include orphaned documents | Lowest latency | Effectively never on a sharded cluster we operate |
| majority | Only data that has been acknowledged by a majority and cannot be rolled back | Slight latency cost, waits for the commit point | The default for anything a customer or an auditor will see |
| snapshot | A consistent snapshot across documents and shards inside a transaction | Higher, holds a snapshot open | Multi-document transactions and cross-collection consistency requirements |
| linearizable | A real-time linear order for single-document reads on the primary | Highest, waits for confirmation | Narrow correctness-critical reads such as uniqueness checks |
The rollback trap. A write acknowledged at w:1 that has not reached a majority can be discarded when the old primary rejoins and rolls back. The application already told the customer it succeeded. MinervaDB audits every collection for this exposure and closes it on the paths where correctness is not negotiable.
Storage Engine Internals
WiredTiger Cache, Eviction and Checkpoint Behaviour
When a MongoDB cluster is described as mysteriously slow, the answer is usually inside WiredTiger. Cache occupancy, dirty content ratio, eviction pressure and checkpoint duration together explain the large majority of latency complaints we investigate, and none of them are visible from an application trace.
The cache defaults to half of RAM minus one gigabyte, which is frequently wrong in a container where MongoDB reads host memory rather than the cgroup limit. Once occupancy passes the eviction target, background workers start reclaiming pages. Once it passes the eviction trigger, application threads are conscripted into eviction, and your p99 latency changes shape within seconds.
Dirty content behaves the same way on a much tighter scale. Above the dirty target, reconciliation becomes aggressive. Above the dirty trigger, writers are throttled until the ratio recovers. A write-heavy batch job that was harmless last quarter can push a cluster across that line as data volume grows, with no code change and no configuration change to blame.
Storage engine signals and what they are telling you
| Signal | Healthy range | Investigate when | What it actually indicates |
|---|---|---|---|
| Cache used | Below 80% steady state | Above 92% for five minutes | The working set no longer fits, or eviction cannot keep pace with the workload |
| Dirty cache ratio | Below 5% | Above 15% and rising | Write volume is outpacing reconciliation, and throttling is imminent |
| Eviction pages evicted by application threads | Effectively zero | Any sustained non-zero value | User queries are paying the cost of eviction, which shows up directly as tail latency |
| Checkpoint duration | Seconds | Tens of seconds or minutes | Too much dirty data at checkpoint time, or a storage device that cannot absorb the flush |
| Bytes read into cache | Stable and proportional to traffic | Sudden sustained growth | Queries have started missing the cache, usually after an index or plan change |
| History store size | Small and stable | Continuous growth | Long-running snapshots or abandoned cursors are pinning old document versions |
| Queued read and write tickets | Zero queueing | Sustained queueing | Concurrency or storage saturation, often downstream of cache pressure |
| Compression ratio | Consistent per collection | Unexplained change | A schema or compressor change has altered the storage and I/O profile |
Data Modelling
Document Modelling and Schema Governance
MongoDB does not remove schema design; it moves the decision from the database into the application and defers the consequences. A model that reads beautifully in a design document can become the reason a cluster needs three times the hardware, because embedding decisions determine document size, index size and ultimately the working set that has to fit in cache.
Our schema reviews start from access patterns rather than entities. We collect the real query shapes, their frequency, their selectivity and their growth curve, then decide where to embed, where to reference, and where a subset or bucket pattern removes work from the read path. The output is a documented model with the reasoning attached, so future changes are informed rather than accidental.
Governance matters as much as the initial design. Without validators, documents drift away from what the code assumes, and the drift is only discovered when a null field breaks an aggregation months later. We put $jsonSchema validation in place where the risk warrants it, and report on drift where strict validation would be too disruptive to introduce at once.
Bounded growth
Arrays with a ceiling, by design
Every array in a reviewed schema either has a documented upper bound or is refactored into referenced or bucketed documents before it can approach the sixteen megabyte document limit.
Read path first
Denormalise where reads justify it
Subset and extended reference patterns duplicate the few fields a list view needs, removing joins from the hot path while keeping the authoritative record in one place.
Time series
Bucketing and native collections
Metric, IoT and event workloads are modelled as buckets or native time series collections, which shrinks document counts, index size and storage cost simultaneously.
Multi-tenancy
Tenant isolation without collection sprawl
A tenant identifier in the shard key prefix gives isolation and targeted queries without the catalogue and index bloat of one collection or database per tenant.
Performance Engineering
Index Strategy and Query Performance Engineering
Almost every MongoDB performance problem we are engaged on reduces to one of three things: a query with no usable index, a compound index whose field order does not match the query, or an index that exists but is never chosen because the plan cache learned a bad lesson under different data conditions.
The planner normalises each query into a shape, looks for a cached plan, and where none exists races candidate plans over a works budget before caching the winner. That mechanism is efficient and also means a plan chosen against last quarter’s data distribution can persist long after it stopped being the right one. Replan events are a signal we watch deliberately.
Field order in compound indexes follows the equality, sort, range sequence. Equality predicates lead, fields that satisfy the sort come next, and range predicates come last. Get that order wrong and MongoDB will still use the index, but it will add a blocking in-memory sort that spills once it exceeds thirty-two megabytes, turning a fast query into an unpredictable one.
The optimisation levers we apply, in order of impact
| Lever | Signal that it applies | Typical outcome |
|---|---|---|
| Add a missing compound index | COLLSCAN in explain, or keysExamined far above nReturned | Order-of-magnitude latency reduction on the affected query shape |
| Reorder an existing compound index | An index is used but a SORT stage remains in the winning plan | The blocking sort disappears and p99 latency stops depending on result size |
| Make a query covered | FETCH stage present although only indexed fields are projected | Reads served entirely from the index, cutting cache pressure and I/O |
| Retire unused indexes | $indexStats shows near-zero usage over a full business cycle | Faster writes, smaller working set and lower storage and backup cost |
| Replace regular expression scans | Case-insensitive or leading-wildcard patterns forcing full scans | Collation-aware indexes or a dedicated search index restore index usage |
| Bound the result set | Large skip values or unbounded find operations in the profile | Range-based pagination replaces skip, and latency stops growing with page depth |
| Right-size the connection pool | Connection churn, or connections near the server ceiling | Queueing disappears and tail latency flattens across the service fleet |
| Isolate analytics traffic | Reporting pipelines competing with OLTP for cache and tickets | Transactional latency becomes stable and predictable again |
Aggregation
Aggregation Pipeline Engineering
Aggregation is where MongoDB does its most valuable work and where it is easiest to write something that is fast on a test dataset and ruinous in production. The distinction that matters is whether a stage streams its input or blocks on it, because blocking stages buffer, and buffers have limits.
A $match that runs first can be served by an index and passes documents through without buffering. A $sort without a supporting index has to accumulate its entire input. A $group accumulates one entry per key. Both are capped at one hundred megabytes unless allowDiskUse is enabled, and enabling it converts a hard failure into a slow, disk-bound success that is often worse operationally.
On a sharded cluster the pipeline is split. Stages before the split run in parallel on every shard; the rest run on a merging node. Pushing $match and $project earlier is therefore the cheapest optimisation available, because it reduces both the work each shard does and the volume that crosses the network to the merger.
- Verify in explain that $match reached the shards rather than the merger, and that it used an index.
- Give every $sort an index that satisfies its key order, so the SORT stage disappears from the plan.
- Index the foreign field of every $lookup, otherwise each input document triggers a scan of the joined collection.
- Replace repeated heavy pipelines with a materialised rollup written by $merge on a schedule your business can tolerate.
- Treat allowDiskUse as a diagnosis rather than a fix: it tells you the pipeline is spilling and needs redesign.
Horizontal Scale
Sharding, Shard Keys and Balancer Operations
Sharding is the most consequential decision in a MongoDB deployment and the hardest to reverse. Resharding exists and works, but it is a data movement exercise measured in hours or days at scale. The right time to get the shard key right is before the collection is sharded, and that requires simulation rather than intuition.
Three properties decide whether a shard key works: cardinality, frequency and monotonicity. High cardinality gives the balancer enough distinct ranges to distribute. Even frequency stops a handful of values dominating. Absence of monotonic growth stops every new insert landing on the shard that owns the highest range, which is the single most common cause of a hot shard.
Operationally, the balancer needs supervision rather than trust. Migrations consume I/O and network on both donor and recipient, range deletion runs afterwards as background work, and orphaned documents can persist if that work is interrupted. We schedule migrations into agreed windows, monitor the deleter backlog and verify document counts before any capacity conclusion is drawn.
The sharding questions we answer with data
| Design question | Why it decides everything | How MinervaDB answers it |
|---|---|---|
| Which field or fields form the shard key | It fixes write distribution, query targeting and the ceiling on future growth | Cardinality and frequency analysis over a real sample, replayed against actual query shapes |
| Ranged, hashed or compound | Ranged preserves locality, hashed spreads writes, compound can do both | Simulated distribution for each candidate, with the read amplification cost quantified |
| Should zones be used | Zones pin data to regions for residency and latency requirements | Zone design mapped to the legal and latency constraints you actually have to satisfy |
| How many shards, and when to add one | Adding shards mid-incident is slow, so the trigger must be known in advance | Growth model on data size, working set and write rate, with a documented add-a-shard threshold |
| What happens to unsharded collections | They stay on the primary shard and can quietly become a bottleneck | Primary shard load reviewed explicitly, with candidates for sharding or relocation identified |
| When is resharding justified | It is expensive, so it must be cheaper than living with the current key | Cost and duration modelled against the ongoing penalty of the existing distribution |
Backup and Recovery
Backup, Point-in-Time Recovery and Disaster Readiness
A backup you have never restored is a hypothesis. MongoDB Consultative Support treats recovery as a measured capability: a written recovery point objective, a written recovery time objective, and rehearsals that produce real numbers against both. Anything else is a plan that has never met production.
Point-in-time recovery depends on two things being true at once. A snapshot must exist at or before the recovery target, and the oplog must still contain every operation from that snapshot forward to the target timestamp. The second condition is the one that quietly fails: the oplog window shrinks as write volume grows, and nobody notices until a restore is needed.
That is why the oplog window is treated as a first-class recovery metric rather than a replication detail. If corruption is detected six hours after it happened and the oplog holds four hours, point-in-time recovery is impossible at any price. We size local.oplog.rs against realistic detection and decision time, and we alert on the trend rather than the breach.
What we put in place, and how it is proven
| Requirement | What MinervaDB implements | How it is proven |
|---|---|---|
| Recovery point objective | Continuous oplog capture on top of scheduled consistent snapshots | Restores to a nominated timestamp, timed and recorded in the rehearsal log |
| Recovery time objective | Restore path sized for your largest collection, not your average one | Full rehearsal on production-scale data with the wall-clock result documented |
| Logical corruption protection | A delayed replica set member plus retained snapshot generations | A deliberate corruption exercise recovered from the delayed member in a game day |
| Backup consistency on a sharded cluster | Coordinated cluster-wide snapshots rather than per-shard snapshots taken independently | Cross-shard referential checks executed on the restored copy |
| Production impact of backup | Snapshots taken from a hidden member so production nodes are untouched | Latency comparison across the backup window shows no measurable effect |
| Restore verification | A queryable restore copy validated before any cutover decision | Row counts, checksums and application smoke tests signed off jointly |
| Regional failover | Documented runbooks with named owners and decision criteria | Executed as a scheduled exercise, with the timeline and gaps written up |
The number we insist on knowing. How long does a full restore of your largest shard actually take, on the hardware you have today, with the data volume you have today? If nobody in the organisation can answer that with a measured figure, the recovery time objective is aspirational rather than real.
Observability
Observability, Golden Signals and Proactive Detection
The difference between a support contract and an operations capability is whether anyone knew before the customer did. We instrument MongoDB so that the signals which predict an incident are collected, baselined and alerted on, and so that alerts which cannot be acted upon are deleted rather than tolerated.
Collection integrates with whatever you already run. Prometheus, VictoriaMetrics, Datadog, New Relic, Grafana, PagerDuty and OpsGenie are all supported, and we deploy exporters that capture WiredTiger, replication, sharding and connection metrics at a resolution high enough to see a five-second stall rather than a five-minute average that hides it.
Thresholds are derived from your workload. A cache at ninety percent is normal in one estate and the start of an incident in another, so a copied template produces either noise or blindness. Every alert we configure names the runbook step, the owner and the escalation path, and every alert that fires without a corresponding action gets reviewed and removed.
What we instrument, layer by layer
| Layer | What we collect | The alert we configure |
|---|---|---|
| Replication | Optime deltas per member, oplog window, election and rollback events | Lag above the agreed bound, or an oplog window shorter than the detection budget |
| Storage engine | Cache used, dirty ratio, eviction by application threads, checkpoint duration | Cache or dirty pressure trending toward the eviction trigger, before it is breached |
| Query layer | Slow query log, profiler samples, plan cache and replan events, $indexStats | Keys examined per document returned crossing the ratio agreed for that collection |
| Sharding | Chunk and data distribution per shard, migration queue, range deleter backlog | Distribution skew, or migrations still queued at the end of the maintenance window |
| Connections | Current and available connections, churn rate, per-service pool utilisation | Pool utilisation above the ceiling agreed with each application team |
| Concurrency | Read and write ticket availability, global lock queues, active operations | Sustained queueing, which is nearly always a downstream symptom |
| Transactions | Commit and abort rates, transaction duration, TransientTransactionError volume | Abort rate or duration drifting outside the baseline for that workload |
| Host and storage | CPU steal, memory pressure and cgroup limits, device latency, filesystem headroom | Device latency degradation, which precedes almost every checkpoint problem |
Security and Compliance
Security, Compliance and Data Protection
MongoDB ships with strong security primitives and, historically, permissive defaults. The gap between the two is where breaches live. Our hardening work is delivered as reproducible configuration under version control rather than as a checklist someone ticked once, because a control that cannot be re-applied is a control that will drift.
We work through the layers in order. Network exposure first, because an unauthenticated listener on a public interface makes every other control irrelevant. Then authentication, authorisation, encryption in transit and at rest, field-level protection for regulated attributes, and finally auditing that produces evidence an assessor will accept without a conversation.
Authentication
Modern mechanisms, no shared accounts
SCRAM-SHA-256 as the baseline, x.509 mutual TLS for service identity, LDAP, Kerberos or cloud IAM integration for enterprise directories, and the elimination of every shared administrative credential.
Authorisation
Least privilege that survives audit
Custom roles scoped to the collections a service actually touches, with database administration rights separated from application rights and reviewed on a quarterly cycle.
Encryption
In transit, at rest and at field level
requireTLS across the estate, encrypted storage with KMIP or a cloud key management service, documented rotation, and client-side or queryable encryption for regulated attributes.
Assurance
Evidence, not assertions
Native auditing with immutable log shipping, a role matrix with attestation history, certificate and cipher inventories, and CIS-aligned hardening applied as code.
Compliance in practice. SOC 2, ISO 27001, PCI DSS, HIPAA and GDPR do not ask whether MongoDB supports a control. They ask you to demonstrate it was in force for the period under review. We build the evidence trail as part of normal operations, so an audit request is a report rather than a project.
Change and Migration
Version Upgrades, Resharding and Migration onto MongoDB
Upgrades and migrations are where well-run estates are separated from lucky ones. MongoDB gives you the tools to move without downtime; what it cannot give you is a rehearsal, a rollback plan or the discipline to treat feature compatibility as a separate decision from the binary upgrade.
Major versions cannot be skipped, so every path is a sequence of hops. Each hop is a rolling binary upgrade across secondaries, a controlled stepdown of the primary, and only then a decision about raising featureCompatibilityVersion. Keeping those two steps apart preserves the ability to downgrade, which is the only real rollback a major upgrade has.
Migrations onto MongoDB from a relational source fail for a predictable reason: the tables are copied instead of the access patterns being modelled. We start from the queries the application needs to serve, design documents around them, backfill in bulk, attach change data capture for the delta, and prove parity with dual reads before anything is cut over behind a flag.
How we sequence a change so it stays reversible
| Change type | The risk we control | How MinervaDB sequences it |
|---|---|---|
| Major version upgrade | Behaviour changes and an FCV that blocks downgrade | Binary upgrade first across secondaries, soak period, then FCV as a separate change ticket |
| Driver upgrade | Silent semantic changes and authentication regressions | Compatibility matrix proven in staging against the target server version before rollout |
| Index creation on a large collection | Foreground builds blocking writes on the primary | Rolling builds member by member, inside an agreed window, with progress monitored |
| Resharding a collection | Extended data movement and elevated load during the operation | Cost and duration modelled first, executed in phases with abort criteria defined up front |
| Schema change on live data | Documents diverging from what the application assumes | Backfill script, validator introduced in warn mode, then enforced once drift reaches zero |
| Cloud or datacentre migration | Cutover risk and an unclear rollback path | Replicated target, dual reads for verification, feature-flag cutover with the source kept warm |
Incident Response
Severity Model, Escalation and the First Hour
When a production cluster is in trouble, the value of a support contract is decided in the first sixty minutes. Who answers, what they do before they touch anything, how quickly a principal engineer is involved, and whether evidence is captured before a restart destroys it. Those four things are the whole product.
Our discipline is containment before diagnosis and diagnosis before change. A restart may clear a symptom and it will also destroy the state that explains it, which guarantees a second outage later. We capture currentOp output, serverStatus counters, logs and profiler samples first, then stabilise, then fix, and only then write up what happened.
Support tiers and service level targets
| Tier | Response target | Coverage | Designed for |
|---|---|---|---|
| Business hours advisory | 4 business hours | Your working day, one region | Development and staging estates, and teams building toward production |
| Production support | 1 hour for Severity-1 | Extended hours with an on-call rota | Single-region production workloads with a tolerable maintenance window |
| Mission critical 24×7 | 15 minutes for Severity-1 | Round the clock, every day of the year | Revenue-bearing and regulated systems where downtime has a direct cost |
| Fully managed operations | 15 minutes, with proactive ownership | Round the clock, MinervaDB holds the pager | Teams without a dedicated MongoDB specialist who still need enterprise reliability |
Pricing is structured per cluster rather than per node, so scaling horizontally does not multiply your support cost, and development environments do not attract production pricing. Support credits, monthly retainers and fixed-scope statements of work are all available, and they can be combined.
Failure Analysis
The Quiet Failure Modes Behind Most 3 a.m. Pages
The incidents that hurt most are rarely dramatic. A node does not die; something gradually stops fitting. These are the patterns we find repeatedly, and the reason each one survives conventional monitoring is that every individual component reports itself as healthy while the system as a whole degrades.
| What the business reports | What is actually happening | Why the dashboards missed it |
|---|---|---|
| Checkout is slow at peak, fine at other times | The working set has outgrown the WiredTiger cache, so peak reads fault to disk | CPU, memory and disk utilisation all look normal; the signal is cache occupancy and bytes read into cache |
| One page is slow, but only for large accounts | A query with no supporting index scans in proportion to tenant size | Average latency stays healthy because most tenants are small; only the p99 for large tenants moves |
| Reports show numbers that were correct yesterday | Reads are served from a secondary that has been lagging for a long period | Replication is monitored as up or down rather than by measured optime delta |
| Writes succeed but records occasionally vanish | Writes acknowledged at w:1 were rolled back after an election | Nothing errors; the application was told the write succeeded and the rollback is only in the logs |
| Nightly batch has started colliding with morning traffic | A blocking aggregation stage began spilling to disk as data volume grew | Job duration is trended but the spill event itself is never surfaced |
| One shard is always the hot one | A monotonically increasing shard key sends every insert to the highest range | Cluster-wide averages look balanced because two of three shards are idle |
| Recovery took far longer than the plan said | The oplog window had shrunk below the detection time, so PITR was not possible | Backups are monitored for success, but the oplog window is never trended against detection time |
Each of these is straightforward to detect once you know it exists and instrument for it. That is the practical value of MongoDB Consultative Support: it converts a category of surprise into a category of routine, monitored, forecastable work.
Coverage
Deployment, Distribution and Platform Coverage
We support MongoDB wherever it runs, including the awkward hybrid estates where a single application spans a self-managed cluster and a managed service. Support is never conditional on you moving to a platform we prefer.
Version coverage runs from legacy 4.x estates that still need a safe upgrade path through to current releases, including the planning work to get from one to the other without a maintenance outage.
Engagement
Engagement Models for MongoDB Consultative Support
Different problems need different commercial shapes. A regulated platform with a permanent on-call requirement needs something very different from a team that needs three weeks of index and schema work before a launch. All of the models below can be combined inside one agreement.
| Model | How it works | Best suited to |
|---|---|---|
| 24×7 consultative support retainer | Named engineers, contractual response targets, unlimited incident volume, monthly service review | Production estates where downtime carries direct revenue or regulatory cost |
| Fully managed MongoDB operations | MinervaDB holds the pager and owns uptime, performance and cost while you keep administrative access | Teams without a dedicated MongoDB specialist who still need enterprise reliability |
| Fixed-scope performance audit | A structured review of schema, indexes, configuration and topology with a prioritised remediation plan | Estates with a known performance or cost problem and no clear root cause |
| Architecture and design engagement | Deep design work on data modelling, sharding strategy, high availability topology or migration | New builds, major re-platforms and moves onto or off MongoDB |
| Support credits, drawn as needed | A pre-purchased block of engineering hours with no expiry, used for incidents or projects | Variable workloads and teams that need expert capacity available but not always active |
| Training and enablement | Workshops covering MongoDB for relational teams, schema design at scale and internals for performance engineers | Organisations building durable in-house capability alongside external support |
Every engagement begins the same way: a short discovery call, a rapid assessment against our best-practice framework, and an executive summary containing a risk matrix, a cost impact model and a prioritised roadmap. You see the findings before you commit to the work.
Industries
Where Our MongoDB Support Is Deployed
Financial services and fintech
Payment authorisation, ledgers and fraud scoring where write durability is non-negotiable and every acknowledgement must survive a failover. Journalled majority writes, audit evidence and rehearsed recovery are table stakes.
Software as a service
Multi-tenant platforms with thousands of tenants on shared clusters, where one large tenant must not degrade everyone else. Tenant-aware shard keys, per-tenant observability and noisy-neighbour containment.
E-commerce and retail
Catalogue, cart and inventory workloads with flash-sale traffic profiles. Elastic read capacity, cache-aware schema design and pre-tested scaling runbooks for known peak events.
Gaming and interactive media
Player state, leaderboards and session data at very high concurrency with strict latency budgets. Bounded document design, tight connection pool control and regional topology for latency.
Healthcare and insurance
Patient, claims and policy data under HIPAA and GDPR obligations. Field-level encryption, least-privilege role design, retention control and evidence that satisfies an assessor.
IoT, telemetry and adtech
Very high ingest rates with time-based access patterns. Bucketing or native time series collections, TTL-driven retention and aggregation pipelines engineered to stay off disk.
Most MongoDB incidents are not caused by MongoDB. They are caused by a model, an index or a topology that stopped matching the workload months earlier, and by monitoring that reported every component as healthy while the system quietly stopped fitting. Our job is to find that mismatch before your customers do.
MinervaDB Engineering
Questions
Frequently Asked Questions About MongoDB Consultative Support
What exactly does MinervaDB MongoDB Consultative Support include?
It combines round-the-clock incident response with the engineering work that prevents incidents. That means a named duty engineer with contractual response targets, golden-signal monitoring wired into your existing stack, schema and index reviews, sharding and replica set design, backup and point-in-time recovery assurance, security hardening and audit evidence, and a written root cause analysis after every critical event. You get an engineering relationship rather than a ticket queue.
How quickly do you respond to a production MongoDB outage?
On our mission critical tier the Severity-1 response target is fifteen minutes, twenty-four hours a day, every day of the year. A duty engineer triages and contains first, a senior MongoDB engineer joins within thirty minutes if the issue is not already resolved, and a principal engineer is involved within the hour for anything touching replication, sharding or the storage engine.
Do you support MongoDB Atlas as well as self-managed clusters?
Yes. We support MongoDB Community and Enterprise Advanced on bare metal, virtual machines and Kubernetes, Percona Server for MongoDB, and managed MongoDB Atlas deployments. We also work with hybrid estates where one application spans a self-managed cluster and a managed service. Support is never conditional on you moving to a platform we happen to prefer.
Can you help us choose or change a shard key?
Yes, and it is one of the most valuable things we do. We analyse cardinality, frequency and monotonicity over a real data sample, replay your actual query shapes against each candidate key, and quantify both write distribution and read amplification before anything is sharded. Where an existing key is already causing a hot shard, we model the cost and duration of resharding against the ongoing penalty of leaving it.
How do you diagnose unexplained MongoDB latency?
We start with evidence rather than theories. WiredTiger cache occupancy and dirty ratio, eviction performed by application threads, checkpoint duration, read and write ticket queueing, replication lag, slow query log samples, plan cache and replan events, and connection pool behaviour. In most engagements the answer turns out to be cache pressure, a missing or badly ordered index, or a blocking aggregation stage that has begun spilling to disk.
What is the difference between consultative support and fully managed operations?
With consultative support your team retains operational control and we provide expertise, on-call cover, reviews and remediation plans. With fully managed operations MinervaDB holds the pager and owns uptime, performance and cost outcomes directly, while you keep full administrative access. Many customers start with consultative support and move specific clusters into managed operations later.
Do you provide point-in-time recovery for MongoDB?
Yes. We implement continuous oplog capture on top of scheduled consistent snapshots, which allows recovery to a nominated second rather than to the last backup. Critically, we treat the oplog window as a first-class recovery metric and alert on its trend, because point-in-time recovery becomes impossible if corruption is discovered after the window has closed. Restores are rehearsed on a schedule and the results are timed and recorded.
Can you help us migrate from a relational database to MongoDB?
Yes. We start from the access patterns your application must serve rather than from the existing tables, design documents around those patterns, backfill in bulk, attach change data capture for the delta, and prove parity with dual reads before cutting over behind a feature flag with the source system kept warm. We also handle the reverse direction and migrations between MongoDB platforms.
How is MongoDB Consultative Support priced?
Pricing is per cluster rather than per node, so scaling horizontally does not multiply your support cost and development environments do not attract production pricing. You can engage through a monthly retainer, pre-purchased support credits with no expiry, or a fixed-scope statement of work for a defined project. These models can be combined within a single agreement.
Will you work alongside our existing DBAs and platform team?
That is the normal arrangement. We are frequently brought in as the specialist depth behind a capable platform team, taking the storage engine, replication and sharding problems while your engineers keep ownership of the application and the delivery pipeline. Knowledge transfer is explicit: every finding is documented, and workshops are available where you want to build the capability internally.
Related Services
Explore More MinervaDB Database Services
For the authoritative reference on server behaviour and configuration parameters, see the official MongoDB Manual. Our recommendations are always traceable to documented behaviour and to measurements taken on your own estate.
Next Step
Turn your MongoDB estate into a predictable platform
Start with a thirty-minute discovery call. We capture your topology, your pain points and your compliance obligations, then return a rapid assessment with a risk matrix, a cost impact model and a prioritised roadmap. You see the findings before you commit to anything.