mongos as MongoDB's native router & why MongoDB rarely uses third-party proxies
Parent: Database Proxies & Query-Optimization Middleware · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-70b86d349efb
↓ Facts as markdownall context files
Source-anchored research for mongos as MongoDB's native router & why MongoDB rarely uses third-party proxies. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- MongoDB drivers select a server per operation and can distribute operations across eligible mongos instances within a latency window; mongos separately applies read preference when selecting members of replica-set shards. (medium confidence) [source]
Problems, failure modes and limitations
- Shard-key predicates can allow targeted routing; queries that cannot be targeted scatter to all relevant shards. Each receiving shard chooses an eligible index locally, so mongos routing is distinct from shard-local query planning. (low confidence) [source]
- For ordinary connections through a proxy to multiple mongos routers, MongoDB documents client affinity. Percona's historical topology analysis explains the failure mechanism: a getMore sent to the wrong router can produce Cursor Not Found. (high confidence) [source]
- Cursor Not Found does not uniquely diagnose proxy misrouting: Mongoose issue #6504 records a sharded-cursor failure that stopped reproducing after a driver update, with the exact cause left uncertain. (low confidence) [source]
Comparisons and alternatives
- Load-balanced mode changes connection-pool capacity: instead of separate maxPoolSize allowances per mongos, the client has a pool for the load-balancer endpoint, while open cursors and transactions retain pinned connections. The specification warns applications may need to increase maxPoolSize. (low confidence) [source]
- Envoy documents its MongoDB network filter as protocol sniffing with BSON parsing, operation timings, query logging, callsite statistics, and fault injection. Lyft’s SREcon17 deployment combined a Mongo sniffer with TCP balancing across mongos and connection-rate limiting, demonstrating a complementary proxy role rather than replacement shard routing. (high confidence) [source]
- The MongoDB load-balancer specification defines explicit loadBalanced=true opt-in, requires a serviceId in the server handshake, and lists minimum server version 5.0. Its URI rules reject multiple hosts, replicaSet, directConnection=true, and positive srvMaxHosts. This describes a compatibility contract rather than universal plug-and-play proxy support. (low confidence) [source]
Facts and statements
- In a sharded cluster, mongos is MongoDB's native application-facing query and write router; it routes operations to the underlying shards. (high confidence) [source]
- mongos caches config-server metadata to locate shard data, establishes cursors on targeted shards and merges results. It has no persistent state, but this does not mean it lacks runtime metadata or cursor state. (low confidence) [source]
- Architectural inference: native mongos routing supplies the shard-awareness that a generic connection balancer does not provide. A third-party network proxy can front mongos without replacing its routing role. (medium confidence) [source]
- MongoDB's load-balancer driver specification defines an explicit loadBalanced=true mode with a serviceId handshake and connection pinning for cursors and transactions. This scopes historical warnings; inserting a load balancer without the matching mode and server configuration is not equivalent. (medium confidence) [source]
- Lyft's SREcon17 engineering presentation documents Envoy in front of mongos, combining connection-rate limiting, MongoDB traffic statistics and TCP load balancing. This is a historical deployment example, not evidence of current prevalence. (low confidence) [source]
- The MongoDB Labs mongoproxy repository describes wire-protocol request and response transformation through modules. It demonstrates that programmable MongoDB middleware exists; its description explicitly disclaims support as a MongoDB product. (low confidence) [source]
- In a sharded MongoDB deployment, applications use mongos as the query router; an external load balancer can front the mongos tier but does not replace it. (high confidence) [source]
- Architectural inference: native driver server selection plus mongos shard-aware routing reduce the need for a separate proxy whose sole purpose is routing or load distribution. These mechanisms alone do not prove low third-party-proxy adoption. (medium confidence) [source]
- An arbitrary load balancer can break cursor affinity: getMore must reach the mongos holding the cursor. MongoDB load-balanced driver mode preserves affinity by pinning a cursor to one connection; transactions also require connection pinning, subject to specified commit/abort retry exceptions. (medium confidence) [source]
Children
- MongoDB driver topology discovery and server selection (frontier)
- mongos cursor affinity and load-balanced connection pinning (frontier)
- Envoy MongoDB traffic observability (frontier)
Frontier under this node: Envoy MongoDB traffic observability, MongoDB driver topology discovery and server selection, mongos cursor affinity and load-balanced connection pinning