Architecture / Ideal Workloads
Distributed SQL, shared-nothing, peer-to-peer architecture. All nodes symmetrical; any node can handle reads/writes. Cluster uses distributed consensus: No matter where data lives, every node can access data anywhere in cluster
SYSTEM OF RECORD. Optimized for transactional workloads that require strong consistency and global distribution, such as AI innovators, cybersecurity, eCommerce & retail, financial services, fintech/payments, gaming, quant/trading & research, and online travel
NoSQL Document Store: Stores data in BSON (binary JSON) documents designed for high-volume data ingestion. Replica set model with one primary and one or more secondaries. Sharded clusters add config servers and mongos routing processes. Compute and storage are co-located per shard; no shared-nothing peer-to-peer symmetry across nodes
SYSTEM OF ENGAGEMENT. Optimized for simple hierarchical data models with minimal transactions and flexible or evolving schemas, such as content management, catalog, user profiles, and mobile/web backends where flexible schema and document-oriented data fit the use case. Not optimized for complex relational workloads, financial transactions, or strong consistency requirements
Auto-Sharding (Dynamic Re-Sharding Online)
NATIVE & AUTOMATIC. Automatically shards data into ranges and dynamically splits, merges, and rebalances online across nodes based on load and size. Zero downtime, fully transparent
MANUAL & COMPLEX. Requires defining a shard key upfront. Changing shard keys (resharding) is possible but resource-heavy in recent versions, and in versions prior to MongoDB 6.0, shard key cannot be changed after collection creation. Online resharding added in 6.0 but remains resource-intensive. Chunk balancing across shards is automatic but based on the fixed shard key value
Automatic Geo-Partitioning (Multi-Region Data Affinity)
NATIVE AND AUTOMATIC. Declarative SQL schema adjustments automatically route, partition, and anchor data close to the user's location, automatically moving data to the region where it is most frequently accessed. Supports geo-partitioning with zone configurations for data locality, compliance, and low latency
PARTIAL AND MANUAL. Atlas Global Clusters provide zone-based data placement using a location field as part of the shard key. Configuration requires manual zone mapping and shard key design. Data residency boundaries are not enforced at the document level independently of shard key values
Availability including Multi-Cloud and Hybrid
Available on all public clouds, e.g., AWS-Google Cloud-Azure; can run a single logical cluster spanning multiple clouds. Can run on prem/local, and cloud + prem hybrid deployments
Atlas managed service is available on all public clouds and supports multi-cloud clusters. Self-managed deployments require manual networking and replication configuration across clouds. Hybrid (on-prem + cloud) is possible but operationally complex
Change Data Capture (CDC)
NATIVE. CHANGEFEED command enables scalable, resilient streaming of data changes to Kafka, cloud storage, and webhooks; no third-party CDC tool needed. CDC Queries enable SQL-based filtering and transformation of streams
NATIVE. Change Streams feature built on the oplog monitors collections/databases for changes in real time. Requires a replica set or sharded cluster. Ordering guarantees are per-shard; cross-shard ordering requires resume tokens. External connectors (Kafka Connect, Debezium) typically needed to route changes to downstream targets at scale
Data Anomalies
ZERO under Serializable isolation: all standard SQL anomalies (dirty reads, non-repeatable reads, phantom reads, lost updates, and write skew) are prevented by default with no additional developer configuration. Read Committed is also available for workloads where some consistency relaxation is an acceptable tradeoff for reduced latency
Default read concern allows stale reads from secondaries. Without majority write concern, data acknowledged as written can be rolled back on primary failure. Dirty reads, non-repeatable reads, and lost updates are possible unless read/write concerns are explicitly set to their strictest values on every operation
Data Integrity & Foreign Keys Support
Provides strict ACID enforcement at the storage layer and full referential integrity. NATIVELY VALIDATES FOREIGN KEYS, explicit CHECKs, and transactional constraints to ensure absolute global correctness across global nodes
Flexible schema means application code is responsible for data quality. Schema Validation exists, but is optional. No foreign keys or referential integrity enforcement. JSON Schema validation available but disabled by default; without it, corrupt or inconsistent data can be written without error
Data Model Complexity
LOW. Relational model with strict schemas, normalized tables, joins, and referential integrity. Ideal for managing complex relationships and transactional systems of record; adapts easily to microservices and enterprise legacy systems
LOW TO MODERATE. Document model with nested JSON/BSON and per‑document structure. Good for heterogeneous data and content, but cross‑document relationships are manual; can get complex; and are managed via embedded documents or expensive-to-use $lookup command. Data modeling requires upfront embedding vs. referencing decisions; restructuring large collections is costly
Data Residency
STRONG, INTUITIVE, AND LOCALITY-AWARE. Helps fulfill compliance (e.g., GDPR, CCPA) with Row-Level Control: can pin specific rows to specific geographic regions using REGIONAL BY ROW command, while preserving single logical data platform. Business and compliance teams can use simple SQL commands to ensure customer data never leaves specific geographic borders
MODERATE & MANUAL. Uses Zone Sharding and tag‑aware sharding, or separate clusters per region. Data residency requires a location field in the shard key and manual zone map configuration. Changing a document's residency zone requires a delete and re-insert. Residency is not enforced at the database level independently of shard key values and application logic
Developer Tools / Experience / Ease of Use
Rich ecosystem: Local CLI, web console UI, ORMS, BI tools, SQL clients, native DB migration toolkits, language‑specific drivers, and compatibility with standard PostgreSQL developer tools like psql
PostgreSQL wire protocol-compatible; feels exactly like developing on standard PostgreSQL. Fits effortlessly into existing ORMs, drivers, and frameworks
Can be spun up instantly in any environment (AWS, GCP, on-prem) with the exact same management interface. The cluster manages its own data balancing, scaling, and hardware survival automatically; DBAs do not need to be distributed systems experts to keep it running smoothly.
Rich ecosystem: MongoDB Compass (GUI), mongosh CLI, Atlas UI, MongoDB Charts for visualization, Atlas Device Sync for mobile, and official drivers for most languages. Schema validation and aggregation pipeline builder in Compass
Document model with native JSON/BSON storage suits rapid iteration on evolving schemas. Proprietary MongoDB Query Language (MQL) requires developers to learn MongoDB-specific APIs. No SQL support; SQL ORMs and tools not compatible without adapters
Getting started with a single replica set or Atlas free tier is straightforward—but sharded clusters, shard key selection, and multi-region topology require significant operational expertise
Distributed ACID Transactions
Fully distributed, multi-row, multi-table ACID transactions out-of-the-box. Fully supported with serializable isolation using distributed consensus (Raft Protocol) across tables, ranges, and regions; strong ACID guarantees
Yes, but layered on top of an originally non‑transactional document store; best suited for shorter‑lived, scoped transactions | Multi-document ACID transactions across replica sets and shards supported since v4.2. Performance overhead is significant vs. single-document operations. Transactions are limited to a 60-second timeout; long-running transactions are not supported
Enterprise Support
Dedicated 24/7/365 enterprise support directly from Cockroach Labs with strict SLAs and custom engineering channels. Offers global follow-the-sun support (TSE+SRE) with proven reliability and global partnerships with industry leaders. Single Global Incident Management integrates Engineering + Support + Customer Success in one channel for consistency/immediacy
Provides commercial support for Enterprise Advanced and Atlas tiers. Community Edition is community-supported. Enterprise support includes 24/7 access; SLAs and escalation paths depend on contract tier
FinOps Support
HIGH. Straightforward pricing based on predictable node usage or consumption metrics. Avoids hidden, fluctuating network traps when moving data across different infrastructure regions. Supports financial governance/FinOps
MODERATE TO HIGH. Atlas pricing is consumption-based (compute, storage, data transfer); costs can be difficult to predict under variable workloads. Cross-region data transfer fees apply in multi-region Atlas clusters. Community Edition is free but requires DBA labor for HA, backups, and operations
Follower Reads
SUPPORTED. Supports follower/replica reads with Bounded (controlled) Staleness, allowing low‑latency local reads from nearby replicas while keeping strong global ordering
SUPPORTED. Secondary reads are supported and configurable via read preference; these are inherently eventually consistent and subject to replication lag rather than an explicit staleness window
FREEDOM
ZERO VENDOR LOCK-IN. Runs on any public or private cloud, across multiple clouds, via CockroachDB's Bring Your Own Cloud (BYOC) offering, on-premises, bare metal, Kubernetes, self-hosted, or in a hybrid deployment encompassing some or all of these. Business Source License (BSL) but Source Available. Full commercial-grade support directly from CockroachDB
MODERATE TO HIGH VENDOR LOCK-IN. SSPL License is source available but highly restrictive regarding offering MongoDB as a service (not OSI open source-compliant). SSPL requires that any service offering MongoDB as a service must open source all software used to provide that service. Community Edition is free to use but license restricts cloud-service deployment. Atlas creates vendor dependency on MongoDB Inc. infrastructure and pricing
Joins
Executes fully distributed hash joins, merge joins, and lookup joins across arbitrary nodes with CockroachDB's advanced Cost-based Optimizer. Full standard SQL support for complex INNER, OUTER, LEFT, RIGHT joins across distributed tables
$lookup performs an in-memory join on the aggregation pipeline host; large result sets can exceed memory limits. $lookup across sharded collections is restricted in some configurations. Complex multi-way joins require multiple aggregation pipeline stages and can be slow. LEFT OUTER JOIN equivalent exists but is computationally expensive and difficult to scale across shards
LDAP Support
NATIVE. Direct native support for external authentication systems like LDAP, Active Directory, GSSAPI, and OIDC
NATIVE in MongoDB Enterprise and Atlas, not Community Edition. Supports LDAP authentication and authorization via LDAP group-to-role mapping
Migrations
Uses MOLT (Migration Off Legacy Technology) Toolkit & change data capture (CDC): MOLT handles schema conversion/verification and CDC moves data out. PostgreSQL wire protocol compatibility enables lift-and-shift; shadow mode testing
Atlas Live Migration supports online migrations to Atlas. No native schema migration tooling; schema changes are managed in application code. Migrating from MongoDB to a relational database requires significant data transformation effort
Multi-Active
YES: FULLY MULTI-ACTIVE/MULTI-REGION; read/write and handle connection requests from any node in the cluster. All nodes are equal and active; any node can accept read and write traffic simultaneously.
NO. Single primary per replica set handles all writes; secondaries are read-only by default. Atlas Global Clusters allow writes to be routed to different regional primaries for different data zones, but zone-sharding setup is required and no node can accept any arbitrary write
Multi-Data-Center Support
FULL. Connects geographically isolated, heterogeneous data centers (AWS, GCP, Azure, on-prem) into a single logical cluster, supported by features such as Physical Cluster Replication (PCR) and Logical Data Replication (LDR)
PARTIAL. Replica sets can span data centers for DR; secondaries in other data centers are read-only unless promoted. Sharded clusters across data centers require mongos and config servers in each location. Atlas manages multi-region topology but each shard still has one primary write location per zone
Multi-region Functionality / Multi-region Writes
ACTIVE-ACTIVE: Read/Write from any node in any region; built-in low-latency local access patterns and Survival Goals (e.g., ALTER DATABASE...SURVIVE REGION FAILURE) commands configure fault tolerance intent
True multi‑region, multi‑active writes: any node in any region can serve reads and writes while preserving serializable consistency guarantees
Mostly ACTIVE-PASSIVE. Atlas Global Clusters allow some regional write routing, but each document is owned by a single primary zone. Cross-zone writes route to the owning region's primary. No native declarative multi-region configuration commands
Atlas Global Clusters support zone-based write routing, but each document's writes still route to its zone's primary. Simultaneous multi-region writes to the same documents are not supported; conflicts require application-level resolution
Replication
Built-in, automatic consensus replication using the Raft protocol; data is divided into ranges and replicated across nodes
Replica set model: one primary, up to 49 secondaries (typically 2-4 in production). Replication is asynchronous by default; write concern 'majority' makes writes synchronous at the cost of write latency. Uses a custom election protocol based on majority votes, not Raft consensus
Required Downtime
ZERO. Online schema changes, rolling upgrades, and cluster expansion occur without taking the data platform offline
LOW. Rolling upgrades maintain availability across replica set members. Index builds use a hybrid approach (MongoDB 4.2+) to reduce blocking. Shard key changes and major collection restructuring can require significant time and resources, with performance impact during the operation
Resilience
Five 9s availability: Survives node/disk/rack/region failures automatically via Raft consensus, with zero data loss (RPO=0). Naturally resilient to outages with granular row-level control
Replica sets: Primary node handles writes; secondaries replicate asynchronously; has Automated failover but can have data loss windows. Replica set election on primary failure typically takes 10-30 seconds, during which writes are unavailable. Async replication means secondaries may lag; data loss risk (RPO > 0) on primary failure unless write concern majority is enforced
Scale
Virtually unlimited horizontal scale-out. Automatic, seamless handling of growing datasets; increase storage and throughput capacity linearly simply by adding more nodes
Horizontal (Sharding): Requires manual configuration of sharding infrastructure (config servers, mongos) and exacting selection of shard keys. Shard key selection is permanent and critical; a poor key causes hotspots and scatter-gather queries. Atlas offers managed sharding but shard key choice remains a manual, upfront design decision
Schema Changes
FULLY ONLINE & NON-BLOCKING. Online transactional schema changes (add/alter columns, indexes, constraints) run in the background without locking tables with zero downtime. Designed for always‑on services
Adding new fields requires no DDL but managing schema consistency across large collections requires application-level migration scripts. Creating indexes on large collections degrades query performance during the build. Shard key changes require rehashing the entire collection
Security-Privacy-Compliance
RBAC, Encryption at Rest with Customer Managed Encryption Keys (CMEK), TLS encryption in transit, IAM integrations, column-level encryption, and robust data-masking natively. Fine-grained encryption at cluster, database, table, or partition levels. Certified SOC 2 Type II and SOC 3, PCI-DSS, HIPAA, and ISO 27001-27017-27018 compliant, with ISO 42001 (Responsible, Ethical, and Safe AI Governance) pending. CockroachDB CIS Benchmarks to deploy hardened CockroachDB configurations. Comprehensive support for GDPR and DORA compliance
RBAC, TLS in transit, encryption at rest (WiredTiger), field-level encryption (client-side), LDAP integration, and audit logging in Enterprise/Atlas. SOC 2, ISO 27001, PCI DSS, and HIPAA certifications available for Atlas. GDPR data residency requires manual zone-sharding design; no native document-level geo-pinning
SQL Compatibility
HIGH. PostgreSQL Wire Compatible: Uses PG wire protocol; strong ANSI SQL with complex queries, joins, window functions, triggers, stored procedures, and UDFs. Supports spatial data, extensions, syntax; most apps connect with minimal or no changes
LOW. Uses proprietary MongoDB Query Language (MQL); Atlas SQL Interface and MongoDB Connector for BI provide limited read-only SQL access via JDBC/ODBC and cover a subset of SQL features. Standard SQL tooling, relational ORMs, and SQL-based migration paths are not supported natively
Storage Engine
Built on Pebble, a highly tuned, GO-based, LSM-tree key-value storage engine developed by Cockroach Labs and inspired by RocksDB specifically for distributed SQL
Built on WiredTiger, a storage engine optimized for document compression and concurrency
Stored Procedures
SUPPORTED AND MATURE. PL/pgSQL and other languages such as Python and Perl support deep procedural logic, autonomous transactions, and complex business rule enforcement. Supports user-defined stored procedures
NOT SUPPORTED. Does not use traditional stored procedures; pushes logic into application layer or implements via server‑side JavaScript, triggers, or functions in managed offerings. Atlas Functions provide server-side logic in the managed offering but are not equivalent to RDBMS stored procedures in SQL procedural capability
Transaction Performance / Isolation Levels
Optimized for OLTP with strong consistency; cross‑region transactions maintain data correctness. Optimizations like Parallel Commits drop distributed execution overhead to a single network round-trip for most transactions
Enforces strict Serializable isolation exclusively, the strongest isolation level, to ensure zero data anomalies under heavy parallel traffic, and Read Committed
Transactions align roughly with snapshot semantics; consistency is further controlled via read/write concerns and replica read preferences rather than a rich set of ANSI isolation levels. No standard ANSI isolation level API. Isolation behavior depends on read/write concern configuration per operation
Simple single‑document writes are very fast; multi‑document, cross‑shard, or cross‑region transactions can be significantly slower. Multi-document transactions hold locks for their duration, increasing contention under high concurrency. Cross-shard transactions use two-phase commit, adding latency. Aggregation pipelines on large unindexed collections can be slow
Triggers & Deferrable Constraints
FULLY SUPPORTED. Supports triggers and deferrable constraints across all deployment models
FULLY SUPPORTED. Atlas Triggers execute logic on database changes in the cloud but are Atlas-only; not available in Community or Enterprise self-managed deployments. Change Streams do the same for self-managed. No deferrable constraints
Vector Search
BUILT-IN NATIVE VECTOR SEARCH, scalable distributed HNSW/IVF indexing, and pgvector (the industry standard for vector similarity search). CockroachDB's C-SPANN provides distributed vector indexing (ANN) at scale; available across all tiers. Suited for AI/ML inference and RAG applications where vectors and transactional data coexist in one engine without a separate vector database
VECTOR SEARCH SUPPORTED—IN ATLAS. Lucene-based Vector Search is built into the Atlas platform but not self-managed Community or Enterprise editions. Vectors and transactional data reside in separate Lucene index infrastructure, not in the core WiredTiger storage engine
Writes and Query Routing
Every node is a gateway to the entirety of the database for unlimited reads and writes in any region. Any node can accept SQL queries; a Distributed Optimizer routes work to the right ranges/replicas based on locality and cost
Mongo S routers and query engine route operations to shards based on shard key. All writes must go to the primary of each shard's replica set. Poor key choice can cause scatter‑gather queries and hotspots. Mongo S adds a network hop on every operation
PRICING
SIMPLE. Commercial Enterprise: Simple, straightforward pricing, plus the ability to tie data to a location to avoid egress costs. Free for single-node/dev. Free Community Tier
Freemium / Enterprise: Open source (SSPL); Free Community Edition; Enterprise Advanced and Atlas (Cloud) adds security/management. Atlas pricing is consumption-based (instance size, storage, IOPS, data transfer); costs can scale unpredictably. Cross-region data transfer fees apply in multi-region clusters
