# Which document databases support ACID transactions and data consistency guarantees at scale?

<p class="elv-tracking-normal elv-text-default elv-font-figtree elv-text-base elv-leading-base elv-font-normal" elv="true">The conversation about ACID transactions in document databases used to be simple: relational databases had them, NoSQL did not. That is no longer accurate, but the degree to which different systems implement ACID guarantees varies significantly, and for applications where consistency is not negotiable, the difference matters.</p><p class="elv-tracking-normal elv-text-default elv-font-figtree elv-text-base elv-leading-base elv-font-normal" elv="true">From reviews in the <a class="a a--md" elv="true" href="https://www.g2.com/categories/document-databases">document databases</a> category, filtered by consistency, transactions, and use cases where data integrity is a hard requirement, the products with meaningful ACID support are MongoDB Atlas, Google Cloud Firestore, and Azure Cosmos DB.</p><ol>
<li>
<a class="a a--md" elv="true" href="https://www.g2.com/products/mongodb-atlas/reviews"><strong>MongoDB Atlas</strong></a><strong>:</strong> Multi-document ACID transactions are supported, though reviewers note they are not as fully developed as in traditional relational databases. Single-document operations are atomic by default. Reviewers building financial and transactional systems describe using MongoDB for workloads that require consistency, but they also flag that transaction performance at scale requires careful query design and index optimization to avoid degradation.</li>
<li>
<a class="a a--md" elv="true" href="https://www.g2.com/products/google-cloud-firestore/reviews"><strong>Google Cloud Firestore</strong></a><strong>:</strong> Reviewers specifically call out ACID transaction support as a built-in capability. One reviewer described it as supporting ACID transactions and being highly scalable without breaking a sweat. Automatic scaling with ACID guarantees is considered a practical advantage for applications where workloads are variable but consistency cannot be relaxed.</li>
<li>
<a class="a a--md" elv="true" href="https://www.g2.com/products/amazon-web-services-aws-amazon-dynamodb/reviews"><strong>Amazon DynamoDB</strong></a><strong>:</strong> Supports transactions via the TransactWriteItems and TransactGetItems APIs, enabling ACID operations across multiple items. Reviewers describe it as one of the most useful options for transactional use cases, particularly for async task management using TTL. The trade-off is that the data model design has to be done correctly up front, or the transactional performance does not hold at scale.</li>
<li>
<a class="a a--md" elv="true" href="https://www.g2.com/products/couchbase/reviews"><strong>Couchbase</strong></a><strong>:</strong> Supports distributed ACID transactions, which is part of what makes it viable for enterprise workloads that require data consistency across nodes. Reviewers describe the hybrid architecture as combining relational-style consistency guarantees with NoSQL scalability.</li>
<li>
<a class="a a--md" elv="true" href="https://www.g2.com/products/azure-cosmos-db/reviews"><strong>Azure Cosmos DB</strong></a><strong>:</strong> Offers configurable consistency levels, including strong consistency, across a globally distributed data set. Reviewers in Azure-centric architectures describe this as genuinely useful for applications that need to balance consistency and latency across regions.</li>
</ol><p class="elv-tracking-normal elv-text-default elv-font-figtree elv-text-base elv-leading-base elv-font-normal" elv="true">For applications where a single inconsistency would be a production incident, which of these did you trust enough to actually run financial transactions through?</p>

##### Post Metadata
- Posted at: 4 days ago
- Author title: Writer
- Net upvotes: 1


## Comments
### Comment 1

The ACID checkbox is almost a distraction here, because in a document DB the consistency you actually want usually comes from modeling so the things that must change together live in one document, which is atomic by default and holds fine at scale. Multi-document transactions do exist now, but they&#39;re the escape hatch, not the design center, and if you find yourself needing them everywhere (especially across shards) that&#39;s usually the tell you&#39;ve modeled relationally inside a document store, and those cross-document transactions will degrade at exactly the scale you were asking about.

##### Comment Metadata
- Posted at: 1 day ago
- Author title: Tech Consultant





## Related discussions
- [How well does Trello scale into a larger team?](https://www.g2.com/discussions/1-how-well-does-trello-scale-into-a-larger-team)
  - Posted at: about 13 years ago
  - Comments: 6
- [Can we please add a new section](https://www.g2.com/discussions/2-can-we-please-add-a-new-section)
  - Posted at: about 13 years ago
  - Comments: 0
- [Quantifiable benefits from implementing your CRM](https://www.g2.com/discussions/quantifiable-benefits-from-implementing-your-crm)
  - Posted at: about 13 years ago
  - Comments: 4


