Problems, use cases, and product boundaries
Nexo places an ordered policy pipeline between MongoDB-compatible clients and an upstream MongoDB endpoint. The useful framing is not “replace MongoDB,” but “add a centrally managed enforcement and observation point without moving policy into every application.”
The problem
Teams commonly need to address several concerns across many services:
- Compatibility: older clients and newer servers may not share the same tested protocol and command behavior.
- Wire-level visibility: application monitoring does not always explain which database operations, namespaces, or pipeline components caused latency or errors.
- Traffic control: migrations and validation may require routing, duplication, or staged policy changes.
- Governance: logging, masking, filtering, rate limits, and tenant rules are difficult to implement consistently in every application.
- Performance: connection reuse, caching, query limits, and rewrites can reduce repeated work when the selected release actually executes those components.
Nexo does not remove the need to upgrade drivers, test database behavior, secure credentials, or operate MongoDB. It provides another control point where supported policy can be evaluated.
How Nexo works
- A client connects to the customer-hosted Nexo Service.
- The Proxy accepts the connection and establishes or selects an upstream connection.
- The Proxy decodes supported MongoDB wire messages.
- Ordered request components inspect, modify, allow, or reject the operation.
- A supported routing decision selects the upstream; MongoDB remains the system of record.
- Supported response components inspect or transform the reply.
- Logs, metrics, audit decisions, and health signals leave through configured observability paths.
Authentication, transactions, topology discovery, compression, and command coverage are release-specific. Consult Compatibility rather than assuming complete protocol translation from the architecture alone.
Representative use cases
Legacy client support
Use Nexo as an evaluation point while upgrading old drivers or servers. The Version
Compatibility component can enforce documented wire-version policy for supported
releases, but the current compatibility evidence does not promise arbitrary
OP_QUERY-to-OP_MSG translation, every driver, or every managed MongoDB service.
Traffic splitting and migration validation
The product model includes weighted traffic split, read/write split, shadow traffic, and multi-target failover concepts. Availability differs by bundle. In 0.2.0, the Proxy does not execute the router phase, so traffic split, read/write split, and tenant-isolation routing must not be used as migration controls. Shadow Traffic is executable but sends plaintext MongoDB wire payloads to its configured shadow target.
Canary deployments
Canary orchestration can stage configuration changes for eligible tiers, but it is not a substitute for workload-specific acceptance criteria. Define error, latency, correctness, and rollback checks before promotion. No automatic rollback threshold or bake-time contract is published by these docs.
Multi-tenant isolation
Tenant isolation is intended to prevent cross-tenant access by applying tenant context near the data path. Its protection depends on complete command coverage, trustworthy tenant identity, and an executable release path. The 0.2.0 router phase does not execute this component, so use database-native authorization for that bundle.
Audit and regulated workloads
Audit Log can record operation context and configured request or response material. Customers must choose retention, destination, access controls, and payload capture carefully. Nexo does not make a system SOC 2, HIPAA, PCI DSS, GDPR, ISO 27001, or other framework compliant, and no tamper-evident storage guarantee is implied.
Performance optimization
Connection pooling, cache, query guard or size limits, query rewrite, index advice, and
read/write splitting address different bottlenecks. Measure each change independently.
Do not rely on legacy percentage savings, automatic killOp, explain-plan enrichment,
Redis invalidation, or stale-while-revalidate claims unless the installed component guide
and release contract explicitly verify them.
Capability topics from the legacy overview
| Topic | Current authoritative interpretation |
|---|---|
| Extensible pipeline | Use the bundle-pinned component catalog. A public third-party plugin marketplace is not currently supported. |
| Version compatibility | A selectable policy component, not a blanket driver/server translation guarantee. |
| Traffic management | Component- and release-specific; router execution is absent in 0.2.0. |
| Observability | Logging and Metrics are available in 0.2.0; profiling, tracing, and payload capture require explicit component support and data-handling review. |
| Caching | MongoDB Cache is Pro-entitled and executable in 0.2.0, with release-specific semantics. |
| Security | Masking, audit, filtering, query limits, tenant isolation, and field encryption have distinct availability and threat models. |
| Marketplace | Legacy sample cards and install commands are demonstrations, not a supported commercial marketplace. |
See the component catalog for exact minimum tiers and execution status.
How Nexo differs
| Product | Primary role | Difference from Nexo |
|---|---|---|
| ProxySQL | MySQL-aware proxy and router | It targets MySQL rather than MongoDB. |
| PgBouncer | PostgreSQL connection pooler | It focuses on PostgreSQL pooling rather than a MongoDB policy pipeline. |
| Envoy | General L4/L7 proxy platform | It is general purpose; Nexo is designed around MongoDB-aware pipeline components. |
mongos | MongoDB sharded-cluster router | It is part of MongoDB sharding, not a general external policy pipeline. |
These are architectural distinctions, not benchmark, completeness, security, or commercial superiority claims.