Blog
The 10 best NoSQL cloud databases
Explore the top 10 NoSQL cloud databases in this detailed guide. Discover key features, benefits, and why they stand out in a competitive market.
Blog
Explore the top 10 NoSQL cloud databases in this detailed guide. Discover key features, benefits, and why they stand out in a competitive market.
You may have seen our two earlier posts in this three-post series: NoSQL cloud databases: Benefits and features explained, and NoSQL cloud database use case guide. This is the last post, which helps you determine how to pick one.
A lot has happened since we first published this guide back in 2024. Two of the ten products changed owners: IBM completed its acquisition of DataStax in May 2025, and Haveli Investments took Couchbase private in September 2025. Two changed licensing: Redis added AGPLv3 alongside its source-available licenses with Redis 8, and ScyllaDB moved to a source-available license entirely. And vector search, which barely featured in operational databases two years ago, now ships natively in seven of the ten. Those all changed how to evaluate a shortlist, so this version adds ownership, licensing, and vector capability alongside the usual questions about consistency, scale, and cost.
Every product here is a legitimate choice for some workload. None is the right answer for all of them. The comparison table below is the fastest way to narrow the field; sections that follow explain what each one is good at and where it isn’t. Every factual claim is sourced to vendor documentation or announcements, and where a vendor's own docs name a limit, we have used their words rather than ours.
Here are the ten, in alphabetical order.
Product | Data model | Ownership and license (2026) | Strongest consistency guarantee | Native vector search | Best fit |
|---|---|---|---|---|---|
Aerospike Cloud | Key-value, document/JSON | Aerospike, Inc., private | Distributed ACID with strict serializability in strong consistency mode, since Database 8 | No | High-throughput real-time OLTP at petabyte scale |
Amazon DynamoDB | Key-value, document | Amazon, proprietary managed service | Multi-region strong consistency, GA June 2025, requires exactly three regions and excludes the transaction APIs | Yes, GA August 2026 | AWS-native workloads, including agentic memory and RAG |
Couchbase Capella | Key-value, document | Haveli Investments, private since September 2025 | ACID transactions within a single cluster; cross-region replication is eventually consistent | Yes | SQL++ familiarity, and mobile or edge sync |
DataStax Astra DB (now IBM) | Wide-column, key-value, time series, vector | IBM, acquisition closed May 2025, sold within watsonx.data | Eventual consistency; LOCAL_QUORUM for the Data API and clients | Yes | Cassandra-compatible workloads inside an IBM data stack |
Google Cloud Bigtable | Wide-column, key-value | Google, proprietary managed service | Strong within a single cluster; eventual across replicated clusters | Partial: in-database distance functions, no managed ANN index | High-throughput operational and analytical key-value |
Microsoft Azure Cosmos DB | Multi-model across six APIs | Microsoft, proprietary managed service | Five configurable levels including strong | Yes, DiskANN in the NoSQL API | Azure-native workloads needing consistency tuning |
MongoDB Atlas | Document | MongoDB, Inc., public; server is SSPL, not open source | Multi-document ACID transactions across collections, databases, and shards | Yes, Atlas Vector Search | Document workloads across clouds where schema flexibility and fast iteration matter most |
Oracle NoSQL Database Cloud Service | Document, key-value, fixed-schema | Oracle, proprietary managed service | ACID with adjustable durability; absolute or eventual consistency per operation | No; Oracle markets vector search in Oracle AI Database | Existing Oracle estates |
Redis Enterprise Cloud | Key-value plus JSON, time series, probabilistic, vector | Redis, Inc.; AGPLv3, SSPLv1, or RSALv2 since Redis 8 | Strong within a shard; active-active is strong eventual consistency | Yes, vector sets and Redis Query Engine | Hot data, caching, session state, semantic caching |
ScyllaDB Cloud | Wide-column, key-value, time series | ScyllaDB, Inc.; source-available since December 2024 | Tunable consistency | Yes, on dedicated vector nodes | Cassandra migrations needing higher throughput per node |
Aerospike Cloud is a fully managed DBaaS built for predictable performance as data volume grows, scaling alongside your applications from gigabytes to petabytes. It is designed for high-throughput, low-latency applications and deploys with cross-zone replication, so a cluster survives the loss of an availability zone. The degree of protection depends on the topology, which ranges from replication factor 2 (RF2) across two zones to replication factor 3 (RF3) across three. Every cluster includes an SLA, which varies by configuration.1
Why it stands out:
Proven at scale: Dream11 runs Aerospike on AWS, adding 35 TB per day at millions of transactions per second with sustained sub-15ms latency.1, 3
Predictable performance: Hybrid Memory Architecture is the default storage configuration, holding the primary index in memory and record data on SSD. In-memory and all-flash configurations are also available, and each namespace can be configured separately.2
No transaction charges: Unlike the hyperscaler databases on this list, Aerospike Cloud prices compute, cloud management, and network transfer, not requests.1
Top features:
Distributed ACID transactions with strict serializability, introduced in Aerospike Database 84
Automatic failover, rebalancing, and reconfiguration, with no dropped traffic during those operations1
Cluster provisioning and management through both a console UI and an automation API1
Multi-model support for key-value and document/JSON APIs1
Selectable consistency mode per cluster, high availability (AP) or strong consistency (SC)1
Benefits:
Failovers, rebalancing, and upgrades are handled by the service, with 24/7 support from Aerospike engineers and integrations into existing observability tooling, including Datadog and Grafana.1
SOC 2 certified, with Type II attestation available on request. Traffic stays inside VPC isolation and private peering, and encryption at rest and in transit is on by default.1
Deployment is not locked to one cloud. Aerospike Cloud runs on AWS and Google Cloud, and the underlying database can also be self-managed in your own data center, so the platform choice does not have to be permanent.1
Cons:
Parts of the developer toolchain are still pre-release. The Developer SDK is in preview, with the Python SDK at an alpha release5
Pricing is capacity-based, so you pay for provisioned compute and storage rather than actual request volume, which favors steady workloads over spiky ones1
Google Cloud support is not at parity with AWS, because self-service deployment on GCP has not yet shipped1
Best for: Businesses that aim for high-performance applications, such as AdTech, that require real-time data processing at a global scale.
Organizations that prioritize predictable latency under load will find the storage model and per-cluster consistency controls do most of the work here. Aerospike Cloud fits critical applications such as fraud detection and customer engagement platforms, and serves as a real-time user profile database.
If your organization uses Amazon Web Services (AWS) as its cloud provider, it makes sense to consider Amazon DynamoDB, Amazon's NoSQL cloud-managed services product.
Why it stands out:
Proven at extreme scale: Over the four days of Prime Day 2025, Amazon properties made tens of trillions of calls to the DynamoDB API, with DynamoDB peaking at 151 million requests per second while maintaining single-digit millisecond responses.6
Zero-RPO multi-region strong consistency: Global tables can be configured so every replica always returns the latest write, a guarantee few managed NoSQL services offer. It reached general availability in June 2025.7, 8
Vector search alongside operational data: Native vector indexing reached general availability in August 2026, so embeddings are stored in the same table as the records they describe, with no separate vector store to sync.9
Top features:
Global tables with two consistency modes: multi-region eventual consistency by default, or multi-region strong consistency across three regions8
On-demand and provisioned capacity modes, with no servers to provision or patch in either11
Enterprise-grade security with fine-grained access control11
DynamoDB Streams for change data capture, feeding downstream processing and replication11
ACID transactions spanning multiple items and tables within a region11
Benefits:
The same table design scales from a low-traffic application to Prime Day volumes without re-designing, which removes a migration most teams otherwise face.6
Fully serverless operation with automated backups and point-in-time recovery, so there is nothing to provision, patch, or size.11
Native integration across the AWS stack, including Bedrock for generating the embeddings that vector indexes store, and IAM for access control.9, 11
Cons:
A hard 400 KB per-item size limit, which forces access patterns to be designed up front and rules out storing large documents or blobs in the table10
Request-based pricing makes cost forecasting difficult, because cost tracks read and write volume rather than provisioned footprint, and two workloads with the same monthly totals cost differently depending on the spikiness of the traffic11
Multi-region strong consistency comes with real constraints: it requires exactly three regions, does not support the transaction APIs, and a global table's consistency mode cannot be changed after creation8
Best for: Companies of all sizes that require a database with good performance and scalability, particularly those already integrated within the AWS ecosystem.
The case for DynamoDB is rarely the database in isolation. It is the fit with everything else in an AWS account, from IAM to Bedrock, and the operational model that comes with a service Amazon runs at its own scale. For teams already committed to AWS, that integration is usually the deciding factor.
Couchbase Capella offers more flexibility for organizations that run on more than one cloud provider, or that want to keep their cloud provider options open for the future. Couchbase went private in September 2025 when Haveli Investments completed a roughly $1.5 billion all-cash acquisition, so roadmap and pricing decisions are now made by a private equity owner rather than public markets.12
Why it stands out:
Deploy on any major cloud: Capella runs on AWS, Google Cloud, and Microsoft Azure, and the same engine can be self-managed on-premises, so a move between providers is not a re-platform.13
Search across cloud and edge: Couchbase ships vector search across Capella, self-managed Server, and Couchbase Lite. Server 8.0 added Hyperscale and Composite vector indexes in October 2025, alongside the existing Search Vector indexes for hybrid queries that combine vector similarity with text or geospatial search.14, 15
Couchbase Lite: An embeddable database for mobile, Internet of Things (IoT), and web apps, with cloud-to-device and peer-to-peer sync, deterministic version-vector conflict resolution, and on-device vector search that runs semantic queries with no network connection.25, 26
Top features:
Queries JSON data with SQL++ (formerly N1QL), a complete SQL dialect familiar to anyone with relational experience16
Full-text, geospatial, and vector search in one engine, all reachable from one SQL++ query14, 15
Includes fully managed integrated cache layer17
Capella Columnar for real-time JSON analytics alongside operational workloads, generally available since September 202418
Memory-first architecture, with the Magma storage engine as the default for datasets that exceed available memory17, 19
Benefits:
Couchbase Capella supports familiar SQL-like queries, making it easier for developers who need to transition from relational databases.16
A cloud-agnostic setup avoids vendor lock-in, and the same engine can run self-managed if cloud is not an option.13
The memory-first design serves the working set from cache, while Magma handles datasets larger than memory at a memory-to-data ratio as low as 1%.17, 19, 20
Cons:
Magma's performance is tied to the underlying disk subsystem. Couchbase recommends SSDs for the data path, so hardware quality is a direct input to performance rather than something you can trade away19, 21
ACID transactions are scoped to a single cluster. Cross Data Center Replication is asynchronous and eventually consistent, and Couchbase advises against combining transactions with active-active bidirectional replication, so multi-region deployments cannot get transactional guarantees across regions22, 23
The platform has broadened and been renamed repeatedly. Columnar reached general availability in September 2024, and the AI offering went from Capella AI Services in private preview in December 2024, to general availability in December 2025, to the current AI Data Plane. Each addition is more surface area to evaluate, price, and keep current with, and renamed products make older documentation and community answers harder to trust18, 24, 27
Best for: Organizations that like Couchbase’s SQL++ query language and that wish to take advantage of its mobile sync capabilities.
Couchbase is the only entry with a serious offline story, so the question is rarely Capella against another cloud database in isolation. It is whether an application needs the same query language and sync model running in a data center and on a device that loses connectivity, a narrow requirement that almost nothing else satisfies.
DataStax Astra DB has changed hands since this guide was first published. IBM completed its acquisition of DataStax on May 28, 2025, and Astra DB is now sold as a component of the IBM watsonx.data multicloud offering, where it extends a lakehouse architecture with a fully managed, cloud-native NoSQL service.28, 29, 30 The Astra Classic product was rebranded as Astra Managed Clusters.31 The underlying engine is still Apache Cassandra, so the technical profile is largely unchanged from 2024. What has changed is where you buy it and how it is packaged. Like Couchbase Capella, Astra DB is not tied to one cloud provider, which suits organizations running hybrid services or wanting to switch providers more easily.
Why it stands out:
Cassandra lineage: Astra DB runs Apache Cassandra, so existing Cassandra Query Language (CQL), drivers, and Cassandra operational knowledge carry over.33
Vector search on an operational engine: Astra DB is intended for generative AI workloads, with vector search running against the same Cassandra tables that serve operational traffic rather than a separate store.32
Embedded in an enterprise AI stack: Astra DB is configurable from the watsonx.data Infrastructure Manager, so it is provisioned and governed alongside a lakehouse rather than as a standalone database.30
Top features:
Supports wide-column, key-value, time series, and vector data models32, 33
Cloud-agnostic deployment across the major public clouds, with multi-region databases supported33
Two access paths: a Data API for document-style development and CQL through the shell and Cassandra drivers33
Triple replication managed for you, with data replicated across three availability zones in every deployed region at a replication factor of 333
Configurable consistency levels through CQL, including EACH_QUORUM, SERIAL, and ALL for writes that must be acknowledged across all regions33, 34
Benefits:
Cassandra compatibility means CQL, existing drivers, and Cassandra operational experience transfer without retraining.33
Cloud-agnostic support works well for hybrid organizations that want to keep their cloud options open.33
Vector and operational data are stored in the same tables, and IBM's watsonx integration puts governance and access control in the same place as the rest of an enterprise AI stack.30, 32
Cons:
Astra DB follows an eventual consistency model, and replicas cannot be independently managed, restricted, or modified. The Data API and clients always use LOCAL_QUORUM, and write consistency levels ONE, ANY, and LOCAL_ONE are unavailable33, 34
Cross-region replication is asynchronous. DataStax's documentation says replication across regions generally takes minutes but can take hours or days in the event of failures or outages35
The legacy Document, REST, GraphQL, and gRPC APIs for Astra Managed Clusters reached end of life in May 2026, so applications built on them need to be migrated to the Data API or CQL31
Best for: Distributed data environments requiring only eventual consistency.
Astra DB is the clearest case on this list where the acquisition matters more than the engine. Cassandra's strengths and limits are well understood and largely unchanged. The question a buyer faces in 2026 is whether being inside IBM's watsonx portfolio is an advantage, because it brings lakehouse governance and enterprise AI tooling, or a constraint, because the database's roadmap is now set by a much larger platform strategy.
Google Cloud Bigtable is the managed version of the wide-column store Google has run internally for more than 20 years, first described in a 2006 research paper and still underpinning Search, Ads, Maps, and YouTube.36, 44 It is a sparse, distributed key-value store indexed by row key, which makes it a different product from BigQuery, Google's analytics warehouse, despite the similar name.41 Google positions it as the NoSQL pioneer, and scalability is where that lineage shows.37
Why it stands out:
Massive scalability: Bigtable is the system behind Google Search, Ads, Maps, and YouTube. As of April 2024, Google reported it serving 7 billion queries per second at peak across its fleet, with more than 10 exabytes under management.36 For one customer deployment, capacity is provisioned per node, with each node serving up to 17,000 requests per second.37
Wide-column with cell versioning: Each intersection of a row and column can hold multiple cells, each a uniquely timestamped version of the value, so the data model records how a value changed over time without a separate history table.41
SQL on a NoSQL engine: Bigtable's SQL interface reached general availability in April 2025, and continuous materialized views let you define an aggregation in SQL that Bigtable keeps current incrementally, without affecting read and write performance.37, 38
Top features:
Easy administration for tasks such as replication and cluster resizing37
Automatic load balancing helps keep response times steady37
Multi-region replication with configurable single-cluster or multi-cluster routing policies40
GoogleSQL interface, generally available since April 2025, runnable from Bigtable Studio or programmatically through the Java, Python, and Go client libraries38, 43
Continuous materialized views that update incrementally as data arrives, so real-time aggregations do not require a separate pipeline37, 38
Benefits:
The availability SLA scales with topology, reaching 99.999% for replicated instances using multi-cluster routing across three or more regions.39
Customer-managed encryption keys with external key manager support, IAM integration, VPC Service Controls, and audit logging meet the controls most regulated industries require, with access authorized down to the table, column, or row level.37, 42
Integration with Dataflow, Dataproc, and BigQuery keeps Bigtable inside an existing Google Cloud data stack.37
Cons:
Cost climbs quickly at sustained high volume, because you pay for provisioned nodes rather than per request37
SQL support is read-only. There is no DML beyond SELECT, no DDL, and no subqueries, JOINs, UNIONs, or CTEs, so it is a query convenience rather than a full query engine. SQL requests also do not fail over to another cluster, even under a multi-cluster routing policy38, 40, 43
Availability and transactions are mutually exclusive. Bigtable prevents you from enabling single-row transactions on an app profile that uses multi-cluster routing, because there is no safe way to run both, so multi-cluster availability means giving up read-modify-write operations40
Best for: Developers building applications that need high throughput and scalability for key-value data, such as customer 360, financial services, and IoT.
If you're concerned about scalability, a NoSQL database that supports Google's operations can probably handle yours.
If your organization is already using Microsoft Azure, it makes sense to look at Microsoft's NoSQL offering, Azure Cosmos DB. One engine stores JSON items natively and exposes them through six APIs, one proprietary and five compatible with the wire protocols of MongoDB, Cassandra, Gremlin, Azure Table Storage, etc.51 Cosmos DB is not several databases but one, wearing whichever interface your application already speaks.
Why it stands out:
Five consistency levels, not two: Microsoft's documentation notes that most commercially available distributed NoSQL databases offer only strong and eventual consistency. Cosmos DB offers strong, bounded staleness, session, consistent prefix, and eventual consistency, configurable per account or overridden per request.45
SLAs on four dimensions: Azure backs throughput, latency, availability, and consistency contractually, including latency at the 99th percentile. Most managed NoSQL services commit to availability alone.46, 47
Search built into the engine: Vector search and the DiskANN index reached general availability in 2024, and full-text and hybrid search followed at Build 2025, so semantic retrieval runs in the same container as the operational data.48, 49
Top features:
Global distribution across any number of Azure regions46
Single-digit millisecond read and write latencies at the 99th percentile within a region46
Multi-model support with APIs for NoSQL, MongoDB, Cassandra, Gremlin, and Table45
Vector search with flat, quantized flat, and DiskANN index types, plus full-text and hybrid search using BM25 ranking and reciprocal rank fusion48, 49, 50
Autoscale and serverless throughput modes, with one-click conversion from serverless to provisioned without downtime or data migration49
Benefits:
Availability commitments scale with topology, from 99.99% for a single-region account to 99.999% for reads on any multi-region account, and 99.999% for writes once multi-region writes are enabled.47
Throughput scales automatically with usage, and the service is integrated into Azure identity, networking, and monitoring rather than deployed alongside them.46, 49
Wire-protocol compatibility means MongoDB and Cassandra applications point at Cosmos DB with driver changes rather than a rewrite, and the NoSQL API uses SQL-like syntax familiar to relational developers.45, 46
Cons:
Strong and bounded staleness halve read throughput. Microsoft's documentation states that these levels read from two replicas in a four-replica set, so for the same number of request units you get half the read throughput of session, consistent prefix, or eventual. 45
Costs escalate if not managed appropriately. Billing is per request unit rather than per node, so expense tracks query complexity as well as volume, and each additional region multiplies the provisioned throughput you pay for.46
New capabilities land on the NoSQL API first. Vector, full-text, and hybrid search all shipped there, so teams on the MongoDB, Cassandra, Gremlin, or Table APIs get compatibility at the cost of feature parity.48, 49, 50
Best for: Organizations that need a wide range of development options for applications such as chatbots, fintech, IoT, and e-commerce.
In the same way that Google Bigtable is good for organizations using Google and Amazon DynamoDB is good for organizations using AWS, Microsoft Azure Cosmos DB is good for organizations using Microsoft Azure. That said, its wide variety of data and consistency models, as well as its multiple query languages, give developers more familiarity and flexibility.
MongoDB Atlas is the managed cloud service for MongoDB, the document database that has been the default NoSQL answer for most of the last decade. Data is stored as BSON documents in collections, grouped into replica sets for availability and sharded horizontally for scale.52
Why it stands out:
Multi-cloud by default: Atlas runs on AWS, Google Cloud, and Microsoft Azure, and one cluster can place replicas across more than one provider, which is a stronger form of portability than deploying separately on each.52
Deep ecosystem: Drivers, ODMs, and framework integrations exist for essentially every major language and stack, and the pool of developers who already know the query language is the largest of any database on this list.52
Owns its embedding models: MongoDB acquired Voyage AI in February 2025 and has been folding its embedding and reranking models into Atlas. No other vendor on this list owns the models that generate the vectors it stores.57
Top features:
Document data model52
Multi-document ACID transactions spanning multiple operations, collections, databases, documents, and shards53
Atlas Search for full-text and Atlas Vector Search for semantic retrieval, both running against the same cluster as operational data52, 56
MongoDB Query Language and the aggregation pipeline for multi-stage transformation and analysis in the database52
Integrated security including role-based access control, network isolation, and encryption at rest and in transit52
Benefits:
The document data model is built for flexibility and speed of development, because the structure of the data follows the application rather than the reverse.52
The size of the ecosystem means tooling, tutorials, and experienced developers are easy to find, though the server itself is source-available under the SSPL rather than open source.52, 54
Replica sets provide automatic failover, so the loss of a primary node is handled by the cluster rather than by staff. 52
Cons:
MongoDB is source-available, not open source. Community Server has been licensed under the SSPL since October 16, 2018, and MongoDB's own FAQ confirms the license is not OSI-approved, which rules out offering it as a managed service without a commercial agreement54
Write scaling depends on shard key choice. MongoDB's documentation warns that a suboptimal shard key produces jumbo chunks, uneven load distribution, and query performance that degrades over time. Resharding has been possible since version 5.0, but it is a heavy operation, so the decision carries weight up front55
The recommended pattern pushes complexity into schema design. MongoDB's documentation notes that single-document atomicity means you don’t need multi-document transactions for many practical use cases. However, that means embedding related data rather than normalizing it, and getting that structure wrong is expensive to undo later53
Best for: Teams looking for a NoSQL database with data structure flexibility, especially those operating in a multi-cloud environment or needing a rich feature set to support diverse application requirements.
There are advantages to using something popular. Tooling exists, hiring is easier, and someone has already encountered whatever problem you are about to have. But popularity is not a fit assessment. What matters here is whether your write patterns suit a single primary per shard, and whether you can commit to a schema design early, because both are harder to change later.
Oracle is synonymous with SQL, but it offers a fully managed NoSQL service as well. It handles document, key-value, and fixed-schema data with single-digit millisecond response times, ACID transactions, and active-active regional replication, all on Oracle Cloud Infrastructure.58 Pricing is pay-per-use across both on-demand and provisioned capacity modes.58
Why it stands out:
On-premises and cloud parity: Oracle advertises 100% compatibility between the cloud service and on-premises Oracle NoSQL Database, reachable through one programmatic interface with no application code changes, so a hybrid or repatriation move is not a rewrite.58, 60
Global Active Tables: Tables can be replicated across regions with local reads and writes in each, and Oracle provides built-in conflict resolution when the same record is updated in two regions at once.60
Oracle-native security and identity: Authorization and data access run through Oracle Cloud Identity and Access Management rather than a separate credential system, which matters if the rest of your estate is already governed there.58
Top features:
Multi-model support for document, key-value, and fixed-schema data58, 60
Adjustable durability and consistency per operation, with absolute and eventual consistency both available60, 61
SQL queries over schema-less JSON, with secondary indexes on any supported field and server-side atomic updates to parts of a JSON document59
On-demand and provisioned capacity modes, so throughput and storage can be scaled up during peaks and back down afterward59
Time-to-live on table rows, so records expire automatically without a cleanup job59
Benefits:
Oracle manages the infrastructure, software, security, capacity scaling, operations, and maintenance, including upgrades, patches, and hardware failures.59, 60
Consistency is tunable per operation, so latency-sensitive reads can be relaxed to eventual consistency while transactional paths keep ACID guarantees.60
Predictable single-digit millisecond response times, with data replicated for high availability.58
Cons:
Absolute consistency costs twice as much as eventual. Oracle's capacity documentation shows a 1.5 KB record using two read units for an eventually consistent read and four for an absolutely consistent one61
Vector search is not in this service. Oracle's vector capability lives in Oracle AI Database, so semantic retrieval alongside NoSQL data means running and syncing two Oracle products rather than one
The Always Free tier is available in one region. Oracle's documentation restricts Always Free NoSQL Database Service to Phoenix, which makes low-cost evaluation awkward for teams outside that region59
Best for: Enterprises that already rely on a range of Oracle products.
Organizations that already use Oracle relational databases and other products might find Oracle NoSQL Database Cloud Service an easier sell if they are looking to experiment with NoSQL. Its multiple data models, consistency policies, and SQL-like query language act as a familiar on-ramp.
Initially created as an in-memory cache store to boost performance, Redis has evolved over the years. Today it serves as a high-speed, low-latency NoSQL database with search, JSON, time series, and vector types built into the core engine.64 Its licensing has changed several times since 2024: Redis left the BSD license in March 2024 for the source-available RSALv2 and SSPLv1, then added AGPLv3 as a third option with Redis 8 in May 2025.63
Why it stands out:
Speed: Its in-memory architecture makes it fast, particularly for data that's frequently accessed. Redis positions predictable performance and linear scalability as core properties of the managed service.62
Local writes in every region: Active-active databases accept reads and writes in each geographic copy with sub-millisecond local latency, and conflicts between concurrent writes are resolved automatically by conflict-free replicated data types rather than by your application.66, 67
One engine, many data structures: Redis 8 merged Redis Stack into the core product, so search, JSON, time series, vector, and five probabilistic structures ship in the database itself rather than as modules you add.64, 65
Top features:
In-memory data store for sub-millisecond data serving62, 71
Active-active geo-distribution with multi-primary replication and strong eventual consistency across regions66, 67
Redis Flex, which tiers data across RAM and SSD so datasets can exceed available memory at lower cost per gigabyte69
A wide array of native data structures, including strings, hashes, lists, sets, sorted sets, and streams, plus JSON, time series, and probabilistic types such as Bloom filter, cuckoo filter, top-k, count-min sketch, and t-digest64, 71
Redis Query Engine for full-text, numeric, and vector queries, plus the vector set data type for lightweight similarity search, and hybrid search via FT.HYBRID as of 8.465, 68
Benefits:
Serving the hot working set from memory removes the disk round trip that dominates latency in most database reads.62, 71
Available across major public cloud providers, with the same engine deployable on-premises as Redis Software, which suits hybrid organizations.62, 70
Instant failover, backups, and recovery are handled by the service, with 24/7 monitoring and support.62
Cons:
Licensing is complicated. Redis left BSD in March 2024 for RSALv2 and SSPLv1, then added AGPLv3 as a third option with Redis 8 in May 2025. The change prompted the Valkey fork, which some organizations are now evaluating instead.63, 64
Memory is the expensive resource, so cost tracks working-set size rather than request volume. Redis Flex mitigates this by tiering to SSD, but it adds a storage tier to size and manage.69
Active-active carries limits. Redis Cloud caps Active-active subscriptions at 10 regions and 10 databases, and the consistency model is strong eventual consistency, so CRDT conflict resolution is predictable but may not match your application's intended semantics.66, 67
Best for: Frequently accessed data where latency is the binding constraint, particularly caching, session state, real-time leaderboards, and semantic caching for AI applications.
Organizations that rely on real-time analytics or need to manage live sessions with users find that Redis Enterprise Cloud performs well.
ScyllaDB is a NoSQL database designed for data-intensive applications that require high throughput, low latency, and predictable scalability. It supports wide-column and key-value modeling from hundreds of gigabytes to petabytes with high availability. Its licensing changed in December 2024, when ScyllaDB moved to a source-available license and made OSS AGPL 6.2 its final open-source release.76
Why it stands out:
Shard-per-core performance: ScyllaDB assigns one shard per CPU core and reports steady single-digit millisecond P99 latency at workloads exceeding two million operations per second.72, 79
Tablets-based elasticity: Data is split into tablets that Raft rebalances dynamically, so clusters scale in parallel rather than serially. ScyllaDB reports scaling from 100,000 to two million operations per second in minutes and running safely at up to 90% storage utilization.72, 74, 75
Proven in real-time machine learning serving: Tripadvisor runs ScyllaDB on AWS for personalization, handling roughly 500,000 operations per second at peak with P99 latency of 1 to 3 milliseconds, and serving up to 5 million static features and 0.5 million user features per second from its feature store.80, 82
Top features:
Compatible with Apache Cassandra, including support for Cassandra Query Language, offering a transition for existing applications72
Advanced caching mechanisms improve read and write speeds72
Automatic scaling that adjusts node count and instance size as storage demand rises and falls, with no manual capacity planning or cluster rebalancing73
Support for key-value, wide column, and time series data formats72
Vector search on dedicated nodes with a RAM-resident index, decoupled from the operational storage engine so heavy vector queries cannot affect database latency, supporting embeddings up to 16,000 dimensions and tuned ANN indexes at billion-vector scale80, 81
Benefits:
Latency stays predictable as throughput rises, which matters when an SLA is measured at P99 rather than on average.72
Non-hierarchical architecture makes scaling simple, because all nodes are equivalent and replication and repartitioning are automatic.78
It integrates well with existing Cassandra workloads for ease of migration.72
Cons:
The data model is narrow. ScyllaDB covers wide-column, key-value, and time series, with no native document, JSON, or graph model, so it is a poorer fit than Couchbase, MongoDB, or Cosmos DB for schema-flexible application data.72
Licensing tightened in December 2024. ScyllaDB moved to a source-available license, with OSS AGPL 6.2 as the final open-source release, and the free tier of the full-featured Enterprise edition is capped at 10TB of total storage and 50 vCPUs per organization starting in 2025.76, 77
Scylla X Cloud does not yet support multi-datacenter deployments. ScyllaDB's documentation states multi-DC support is in progress, so the newest cluster type and multi-region topology are currently an either-or choice.73
Best for: Companies with large data streams needing real-time processing, such as in financial services, AdTech, or IoT, which require low latency.
Organizations that anticipate rapid growth will find ScyllaDB X Cloud's auto-tuning, replication, and repartitioning optimizations to be critical assets that don't require as much operator time.
Three questions help determine the right choice.
Where does your consistency requirement stop? DynamoDB will give you strong consistency across exactly three regions and no transactions with it. Couchbase gives you ACID inside a cluster and eventual consistency between them. Cosmos DB gives you five levels, but its documentation notes that the two strongest halve your read throughput per request unit. Astra DB is eventually consistent by design. If your application needs a guarantee that a specific write is visible everywhere before you act on it, that constraint eliminates most of this list.
What does your bill track? Request-based pricing, as in DynamoDB and Cosmos DB, means expense follows traffic, which is efficient for spiky workloads but hard to forecast. Capacity-based pricing, as in Aerospike Cloud and Bigtable, means expense follows provisioned footprint, which is predictable but wasteful at low utilization. Neither is better. They depend on how well you know your traffic.
How locked in are you willing to be? DynamoDB, Bigtable, Cosmos DB, and Oracle NoSQL are each excellent inside their own cloud and a re-platform outside it. Couchbase, MongoDB, Redis, ScyllaDB, Astra DB, and Aerospike run in more than one place. If that portability is worth something to you, it is worth pricing now.
Two other factors are also worth considering:
Consolidation and license tightening have moved in one direction since 2024, and nothing on this list has moved back, so the licensing and ownership column deserves the same weight you would give a technical constraint.
Vector search has arrived inside general-purpose operational databases rather than staying in specialist ones, which means the case for running a separate vector store is now narrower than it was when we first published this guide.
Whatever you choose, the decision gets easier once it stops being theoretical. The next step is picking two or three choices from the table above and testing them against your own access patterns, at the volumes you expect a year from now rather than the ones you have today. The differences that matter show up under load, and they show up faster than you might expect.
Frequently asked questions
Picking the wrong one is expensive to reverse once an application is built around a data model and query pattern, so it's important to choose carefully. Each product is focused on a different kind of problem: DynamoDB for AWS-native serverless workloads with unpredictable traffic, MongoDB Atlas for document flexibility and developer familiarity, Cosmos DB for Microsoft-ecosystem multi-region apps, Cassandra/ScyllaDB for massive write-heavy workloads with the staff to support it, and Aerospike for latency-sensitive, high-throughput workloads where predictable performance at scale matters more than query flexibility.
The right starting question isn't "which database is best" but "what are my access patterns, my consistency requirements, and my tolerance for operational overhead." A comparison made on features alone tends to miss cost and modeling tradeoffs that show up only in production.
Unpredictable billing usually comes from a mechanism that isn't obvious until it's already expensive.
DynamoDB's on-demand pricing has no ceiling and serves every request and bills for it, which can turn a modest monthly bill into a large unexpected charge within days. Global secondary indexes make this worse because every base-table write also writes to each index, so adding a GSI can roughly double write costs without any warning from the platform.
Cosmos DB's Request Unit model has a similar problem; throttling can occur well below a provisioned RU/s ceiling when a hot partition handles a disproportionate share of traffic. MongoDB Atlas ties compute tier to storage size, which can force a cluster upgrade and a larger bill, because data volume grew, not because query load did.
Model total cost of ownership before committing to a pricing structure, including provisioned vs. on-demand, index fan-out, and storage-to-compute coupling, rather than after the first invoice.
No. NoSQL databases are schema-flexible, not schema-free. The schema doesn't disappear; it moves from the database engine into application code, where it's enforced less consistently and is harder to see. Skipping modeling creates painful, hard-to-fix data problems later.
Not designing a schema early on tends to produce a system where data is inconsistent enough that queries, migrations, and even basic reporting become difficult. Data modeling isn't avoided in NoSQL; it's just done differently and needs to happen earlier.
Yes, though this varies by product and often by configuration. Today's DynamoDB and MongoDB support ACID transactions, and most NoSQL databases offer a spectrum of consistency options rather than one fixed guarantee. Eventual, session, bounded staleness, and strong consistency are typically available, with the choice usually made per operation or per read.
The confusion comes from NoSQL's early reputation as strictly eventually-consistent, which is no longer accurate for most major products. The question isn't "does this database support consistency" but "which consistency level does this specific read or write need," because stronger consistency usually costs latency and throughput.
No. Eventual consistency is a tradeoff that favors availability and latency over immediate agreement across replicas, not a defect. It's the right choice for data where a brief staleness window is harmless, such as a social media like count or a product view counter, and the wrong choice for data where it isn't, such as an account balance or inventory count immediately before checkout.
Most systems that use NoSQL databases mix consistency levels within the same application, tuning each read and write to the cost of staleness for that specific piece of data.
Single-table design is a DynamoDB model where multiple entity types are stored in one table, structured around the application's access patterns rather than around the entities themselves. It's widely considered the most difficult skill to learn in the DynamoDB ecosystem, largely because it requires knowing every access pattern the application will ever need before the table is designed, compared with the relational habit of modeling entities first and writing queries later.
That means changing or adding an access pattern after the fact is harder in a single-table design than in a relational schema, so the upfront modeling investment matters more than it does with SQL.
Managed services is less work, but it doesn't do all of it. Even with a fully managed database, teams still need to reason about partition design, capacity planning, replication behavior, and cost; the operational burden shrinks, but it doesn't disappear. Self-managed Cassandra, by contrast, is difficult enough to justify a dedicated team, which is a major reason teams migrate to managed alternatives or to systems that require less work.
The decision usually comes down to team size and lifecycle stage: a managed service's premium is easy to justify when it replaces a role you'd otherwise have to hire for, and harder to justify once you have the scale and expertise in-house.
Structured, relationship-heavy data with cascading updates, ad hoc analytical queries, or a need for joins across many entities is usually a poor fit for NoSQL. The conventional wisdom of starting with a relational database unless you have a reason not to means that NoSQL's benefits, such as horizontal scale, flexible schema, and low-latency key-based access, pay off only when the workload needs them.
The problem isn't "NoSQL is bad"; the problem is choosing NoSQL because it seems modern or scalable rather than because scale requirements and the way applications access the data call for it.
Not automatically. NoSQL databases can scale further and perform better for specific types of access, but that requires getting partition and key design right. A wrong partition key choice creates hot partitions that throttle performance no matter how much capacity is provisioned, and NoSQL's limited support for complex queries and joins makes certain operations slower than the equivalent SQL query, not faster.
The performance ceiling is higher with NoSQL for the right workload, but the floor is lower too: a poorly modeled NoSQL system underperforms a well-indexed relational database on the same hardware.
Vendor lock-in risk comes from proprietary APIs, query languages, and data-egress fees that make switching providers costly even when the underlying data model would translate. Open-source databases and products with multi-cloud deployment options reduce this risk because the same query language and data format work across providers, giving you negotiating leverage and an exit path if pricing or performance stops working for you.
This is worth considering at selection time, because the cost of switching only grows as more of the application becomes coupled to a vendor's proprietary features.
Multi-region active-active setups make conflict resolution a key design concern. When two regions accept writes to the same record simultaneously, the database needs a strategy for how to handle it, commonly last-writer-wins, which can discard a legitimate update, or more sophisticated approaches such as CRDTs. Replication lag can also produce read-after-write bugs, where a user's own write appears to have vanished because their next request was routed to a region that hasn't caught up yet. These setups typically carry a cost premium of 200%-300% over single-region deployments, in exchange for the availability and latency benefits of serving users from a nearby region.
Because problems here are easy to miss until they cause an incident, it's worth testing them, including inducing a split-brain condition, before relying on active-active in production.
Both approaches are common, and the right choice depends on how tightly your embeddings need to stay in sync with their source data. Keeping vector search inside your existing NoSQL database, which is an option in Cosmos DB and MongoDB Atlas, among others, keeps embeddings colocated with the records they describe, which makes it easier to keep the data up to date and avoids running a second system. Dedicated vector databases offer more specialized indexing and query performance for pure similarity search, but introduce an additional system to keep synchronized with your primary data store.
This is a fast-moving area, so the decision is worth revisiting as your scale and the way the application retrieves data become clearer, rather than settling it permanently at the prototype stage.
Common migration paths include moving from Postgres or SQL Server into DynamoDB or MongoDB, moving off MongoDB back to Postgres when data access turned out to be more relational than expected, or moving from DynamoDB or Cassandra to ScyllaDB for throughput. These migrations aren't drop-in replacements even between similar-looking NoSQL products: for example, moving to ScyllaDB requires NVMe storage rather than network-attached storage such as EBS. Otherwise, you get node overload errors under load.
Because these projects tend to run for multiple months and carry downtime and data-loss risk if planned poorly, validating infrastructure requirements and running a staged cutover, rather than a single flip, is the wiser course of action.
Aerospike Cloud
1. "Aerospike Cloud," Aerospike, https://aerospike.com/products/aerospike-cloud/ (undated marketing page, subject to revision, accessed September 9, 2026)
2. "Flexible storage," Aerospike Documentation, https://aerospike.com/docs/database/learn/architecture/hybrid-storage/
3. "Dream11 customer story," Aerospike, https://aerospike.com/resources/customer-stories/dream11-aerospike-customer-story/
4. "Aerospike 8 delivers the first real-time distributed ACID transaction database with high performance at scale," Aerospike, February 5, 2025, https://aerospike.com/press-release/aerospike-8-delivers-the-first-real-time-distributed-acid-transaction/
5. "Aerospike documentation," Aerospike, https://aerospike.com/docs/ (Developer SDK preview and Python SDK alpha designations, accessed September 9, 2026)
Amazon DynamoDB
6. Channy Yun, "AWS services scale to new heights for Prime Day 2025: key metrics and milestones," AWS News Blog, August 26, 2025, https://aws.amazon.com/blogs/aws/aws-services-scale-to-new-heights-for-prime-day-2025-key-metrics-and-milestones/
7. "Amazon DynamoDB global tables with multi-Region strong consistency is now generally available," AWS, June 30, 2025, https://aws.amazon.com/about-aws/whats-new/2025/06/amazon-dynamo-db-global-tables-multi-region-strong-consistency-generally-available/
8. "Overview of global tables," AWS Prescriptive Guidance, https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-global-tables/overview.html
9. "Amazon DynamoDB now supports real-time vector search," AWS, August 5, 2026, https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-dynamodb-vector-search/
10. "Constraints in Amazon DynamoDB," AWS Documentation, https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Constraints.html
11. "Amazon DynamoDB FAQs," AWS, https://aws.amazon.com/dynamodb/faqs/
Couchbase Capella
12. "Haveli Investments completes acquisition of Couchbase," PR Newswire, September 24, 2025, https://www.prnewswire.com/news-releases/haveli-investments-completes-acquisition-of-couchbase-302565846.html
13. "Supported cloud providers," Couchbase Capella documentation, https://docs.couchbase.com/cloud/clouds/cloud-providers.html
14. "Couchbase Capella release notes," Couchbase Capella documentation, https://docs.couchbase.com/cloud/release-notes/release-notes.html
15. "Announcing vector search and a whole lot more," Couchbase Blog, https://www.couchbase.com/blog/announcing-vector-search/
16. "Query data with SQL++," Couchbase Capella documentation, https://docs.couchbase.com/cloud/n1ql/query.html
17. "Manage your data," Couchbase Capella documentation, https://docs.couchbase.com/cloud/clusters/data-service/data-service.html
18. "Couchbase Capella advancements fuel development of adaptive applications; unlock greater DBaaS access for developers," Couchbase, September 3, 2024, https://investors.couchbase.com/news-releases/news-release-details/couchbase-capella-advancements-fuel-development
19. "Storage engines," Couchbase Server documentation, https://docs.couchbase.com/server/current/learn/buckets-memory-and-storage/storage-engines.html
20. Shivani Gupta, "Reduce TCO by 10x using Couchbase 7.1 for large multi-terabyte databases," Couchbase Blog, May 12, 2022, https://www.couchbase.com/blog/low-tco-with-couchbase/
21. "Magma: the next-generation document storage engine," Couchbase Blog, https://www.couchbase.com/blog/magma-next-gen-document-storage-engine/
22. "Transactions," Couchbase Server documentation, https://docs.couchbase.com/server/current/learn/data/transactions.html
23. "Understanding how transactions work in Cross Data Center Replications (XDCR)," Couchbase Blog, https://www.couchbase.com/blog/couchbase-xdcr-transactions/
24. "Couchbase introduces Capella AI Services to streamline development of agentic AI applications," Couchbase, December 2, 2024, https://www.couchbase.com/press-releases/couchbase-introduces-capella-ai-services-to-streamline-development-of-agentic-ai-applications/
25. "Couchbase Lite: embedded NoSQL database for offline-first apps," Couchbase, https://www.couchbase.com/products/lite/ (undated product page, accessed September 9, 2026)
26. "Couchbase Lite," Couchbase documentation, https://docs.couchbase.com/couchbase-lite/current/index.html
27. "AI Data Plane," Couchbase, https://www.couchbase.com/products/ai-services/ (accessed September 9, 2026)
DataStax Astra DB (now IBM)
28. "IBM officially closes acquisition of DataStax," Database Trends and Applications, May 28, 2025, https://www.dbta.com/Editorial/News-Flashes/IBM-Officially-Closes-Acquisition-of-DataStax-169711.aspx
29. "DataStax, an IBM company," IBM, https://www.ibm.com/products/datastax (accessed September 9, 2026)
30. "Astra DB in watsonx.data," IBM Documentation, https://www.ibm.com/docs/en/watsonxdata/saas?topic=infrastructure-astra-db-in-watsonxdata
31. "Astra Managed Clusters release notes," DataStax Documentation, https://docs.datastax.com/en/astra-db-classic/release-notes.html
32. "Vector concepts," Astra DB Serverless documentation, https://docs.datastax.com/en/astra-db-serverless/get-started/vector-concepts.html
33. "Astra DB Serverless database limits," DataStax Documentation, https://docs.datastax.com/en/astra-db-serverless/databases/database-limits.html
34. "Write consistency levels," DataStax CQL Documentation, https://docs.datastax.com/en/cql/astra/get-started/partials/write-consistency-levels-table.html
35. "Astra Managed Clusters database limits," DataStax Documentation, https://docs.datastax.com/en/astra-db-classic/database-limits.html
Google Cloud Bigtable
36. Bora Beran, "Celebrating 20 years of Bigtable with exciting announcements at Next," Google Cloud Blog, April 10, 2024, https://cloud.google.com/blog/products/databases/bigtable-enhancements-at-next24
37. "Bigtable: fast, flexible NoSQL," Google Cloud, https://cloud.google.com/bigtable (undated product page, accessed September 9, 2026)
38. Christopher Crosbie and Bora Beran, "Accelerate your analytics: new Bigtable SQL capabilities drive real-time insights," Google Cloud Blog, April 10, 2025, https://cloud.google.com/blog/products/databases/accelerate-your-analytics-with-new-bigtable-sql-capabilities
39. "Cloud Bigtable service level agreement (SLA)," Google Cloud, https://cloud.google.com/bigtable/sla
40. "Routing options," Bigtable documentation, https://cloud.google.com/bigtable/docs/routing
41. "Bigtable overview," Bigtable documentation, https://cloud.google.com/bigtable/docs/overview
42. "Customer-managed encryption keys (CMEK)," Bigtable documentation, https://cloud.google.com/bigtable/docs/cmek
43. "GoogleSQL for Bigtable overview," Bigtable documentation, https://cloud.google.com/bigtable/docs/googlesql-overview
44. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber, "Bigtable: a distributed storage system for structured data," OSDI '06: Seventh Symposium on Operating System Design and Implementation, Google Research, November 2006, https://research.google.com/archive/bigtable-osdi06.pdf
Microsoft Azure Cosmos DB
45. "Consistency levels in Azure Cosmos DB," Microsoft Learn, https://learn.microsoft.com/en-us/azure/cosmos-db/consistency-levels
46. "Azure Cosmos DB," Microsoft Azure, https://azure.microsoft.com/en-us/products/cosmos-db (undated product page, accessed September 9, 2026)
47. "High availability (reliability) in Azure Cosmos DB for NoSQL," Microsoft Learn, https://learn.microsoft.com/en-us/azure/reliability/reliability-cosmos-db-nosql
48. James Codella, "New vector search, full text search, and hybrid search features in Azure Cosmos DB for NoSQL," Azure Cosmos DB Blog, Microsoft, https://devblogs.microsoft.com/cosmosdb/new-vector-search-full-text-search-and-hybrid-search-features-in-azure-cosmos-db-for-nosql/
49. "What's new in Azure Cosmos DB for NoSQL at Microsoft Build 2025," Azure Cosmos DB Blog, Microsoft, May 2025, https://devblogs.microsoft.com/cosmosdb/whats-new-in-azure-cosmos-db-for-nosql-at-microsoft-build-2025/
50. "Azure Cosmos DB: becoming a search-native database," Azure Cosmos DB Blog, Microsoft, https://devblogs.microsoft.com/cosmosdb/azure-cosmos-db-becoming-a-search-native-database/
51. "Azure Cosmos DB documentation," Microsoft Learn, https://learn.microsoft.com/en-us/azure/cosmos-db/
MongoDB Atlas
52. "MongoDB Atlas," MongoDB, https://www.mongodb.com/products/platform/atlas-database (undated product page, accessed September 9, 2026)
53. "Transactions," MongoDB Manual, https://www.mongodb.com/docs/manual/core/transactions/
54. "Server Side Public License FAQ," MongoDB, https://www.mongodb.com/legal/licensing/server-side-public-license/faq
55. "Change a shard key," MongoDB Manual, https://www.mongodb.com/docs/manual/core/sharding-change-a-shard-key/
56. "Atlas changelog," MongoDB Docs, https://www.mongodb.com/docs/atlas/release-notes/changelog/
57. "Rethinking information retrieval in MongoDB with Voyage AI," MongoDB Blog, https://www.mongodb.com/company/blog/engineering/rethinking-information-retrieval-mongodb-with-voyage-ai
Oracle NoSQL Database Cloud Service
58. "NoSQL Database Cloud Service," Oracle, https://www.oracle.com/database/nosql/ (undated product page, accessed September 9, 2026)
59. "Features of Oracle NoSQL Database Cloud Service," Oracle Cloud Infrastructure Documentation, https://docs.oracle.com/en-us/iaas/nosql-database/doc/features-oracle-nosql-database-cloud-service.html
60. "NoSQL Database Cloud Service FAQ," Oracle, https://www.oracle.com/database/nosql-cloud-faq.html
61. "Oracle NoSQL Database Cloud Service limits," Oracle Documentation, https://docs.oracle.com/en/cloud/paas/nosql-cloud/fkdyw/
Redis Enterprise Cloud
62. "Redis Cloud," Redis documentation, https://redis.io/docs/latest/operate/rc/
63. "Licenses," Redis, https://redis.io/legal/licenses/
64. "Redis 8 is now GA, loaded with new features and more than 30 performance improvements," Redis Blog, https://redis.io/blog/redis-8-ga/
65. "What's new in two: March 2026 edition," Redis Blog, https://redis.io/blog/whats-new-in-two-march-2026-edition/
66. "Active-Active Redis," Redis Cloud documentation, https://redis.io/docs/latest/operate/rc/databases/configuration/active-active-redis/
67. "Active-Active geo-distributed Redis," Redis Software documentation, https://redis.io/docs/latest/operate/rs/databases/active-active/
68. "Announcing vector sets, a new Redis data type for vector similarity," Redis Blog, https://redis.io/blog/announcing-vector-sets-a-new-redis-data-type-for-vector-similarity/
69. "Redis Software release notes 8.0x," Redis documentation, https://redis.io/docs/latest/operate/rs/release-notes/rs-8-0-releases/
70. "Redis Software," Redis documentation, https://redis.io/docs/latest/operate/rs/
71. "Data types," Redis documentation, https://redis.io/docs/latest/develop/data-types/
ScyllaDB Cloud
72. "ScyllaDB X Cloud," ScyllaDB, https://www.scylladb.com/product/scylladb-xcloud/ (undated product page, accessed September 9, 2026)
73. "X Cloud clusters," ScyllaDB Cloud documentation, https://cloud.docs.scylladb.com/master/cloud-setup/cluster-types/xcloud-clusters.html
74. "Introducing ScyllaDB X Cloud: a (mostly) technical overview," ScyllaDB Blog, June 17, 2025, https://www.scylladb.com/2025/06/17/xcloud/
75. "ScyllaDB tablets: answering your top questions," ScyllaDB Blog, June 24, 2025, https://www.scylladb.com/2025/06/24/scylladb-tablets-answering-your-top-questions/
76. "Why we're moving to a source available license," ScyllaDB, December 18, 2024, https://www.scylladb.com/2024/12/18/why-were-moving-to-a-source-available-license/
77. "ScyllaDB shift to source-available licensing FAQs," ScyllaDB, https://www.scylladb.com/source-available-faq/
78. "Data distribution with tablets," ScyllaDB Manual, https://docs.scylladb.com/manual/branch-2025.1/architecture/tablets.html
79. "ScyllaDB: true elastic scale," ScyllaDB, https://www.scylladb.com/product/scylladb-tablets-elasticity/
80. "Vector search," ScyllaDB, March 27, 2026, https://www.scylladb.com/vector-search/
81. "Vector search," ScyllaDB Manual, https://docs.scylladb.com/manual/stable/features/vector-search.html
82. "Inside Tripadvisor's real-time personalization with ScyllaDB and AWS," ScyllaDB Blog, January 30, 2025, https://www.scylladb.com/2025/01/30/inside-tripadvisors-real-time-personalization-with-scylladb-aws/
For a deeper understanding and more insights, explore these additional resources.
See moreBlog
Blog
Blog
Blog