Executive Summary
Choose an operational database by its data model, who will run it, how it accepts writes in more than one region, and the license. Every platform here runs transactions; they differ on those four.
An operational database stores and changes the records an application works on: orders, accounts, bookings, payments. IBM states that online transactional processing (OLTP) enables the real-time execution of large numbers of database transactions by large numbers of people, typically over the internet. IBM states that the defining characteristic of an OLTP database transaction is its atomicity: a transaction either succeeds as a whole or fails, and cannot remain in a pending or intermediate state.
Four decisions separate the platforms. The first is the data model: relational tables, JSON documents, or key-value. The second is who operates the database: your own team, or a cloud provider’s managed service that takes over backups, patching and failover. The third is how the database handles writes in more than one region: one writer region with read copies, several regions accepting writes with conflict resolution, or several regions accepting writes under one consistent order. The fourth is the license, which has changed for some engines in recent releases.
Platforms that accept writes in several regions at once do it in different ways. Section 3 lists the platforms whose own documentation describes active-active or multi-region writes, and what each says about conflicts and consistency.
What an Operational Database Does, and Why the Choice Lasts
IBM states that OLTP is optimized for executing online database transactions, for frontline workers or for customer self-service applications such as online banking, e-commerce and travel reservations. IBM notes that OLTP systems often serve as a source of information for OLAP systems.
Schemas, stored procedures, drivers and the skills of the people who run it all tie an organization to an engine. A move between engines means rewriting code that depends on one SQL dialect, retesting every transaction and running two databases during the cutover.
A managed database service takes over the infrastructure, not the database design. AWS states that Amazon RDS is a managed database service that runs IBM Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle Database and PostgreSQL, and manages backups, software patching, automatic failure detection and recovery. AWS states that under the Amazon RDS shared responsibility model, Amazon RDS hosts the software components and infrastructure, while the customer is responsible for query tuning and owns monitoring and tuning. Google describes Cloud SQL as a fully managed relational database service for MySQL, PostgreSQL, and SQL Server. Google states that Cloud SQL handles backups, high availability and failover, network connectivity, export and import, maintenance and updates, monitoring, and logging. Schema design, indexing and slow queries stay with your team or with a database services firm you hire. Decide who will do that work before you compare platforms.
Licenses changed for several engines. Cockroach Labs states that all versions of CockroachDB from the release date of 24.3.0 onward, including patch fixes for versions 23.1-24.2, are made available under the CockroachDB Software License. For Redis / Valkey, Redis states that starting with Redis 8, users may select one of three license options to use Redis Open Source: RSALv2, SSPLv1, or AGPLv3. The PostgreSQL project states that PostgreSQL is free and open source and highly extensible: users can define their own data types, build custom functions and write code in different programming languages without recompiling the database. Read the license of the version you will run, and of any version you may upgrade to, before you build on it.
Which Database Platforms Support Active-Active, Multi-Region Writes?
An active-active database accepts writes in more than one region at the same time. A single-writer database sends every write to one primary region and copies the changes to the others. The difference matters when a region fails, and when users on two continents both need fast writes.
Platforms that accept writes in several regions take one of two approaches to the same record changed in two places. Some resolve the conflict after the fact, so for a short time two regions can return different values. Others agree on one order of writes before they confirm a write, which keeps every region consistent and adds latency to each write.
Several platforms describe several regions accepting writes, with conflicts resolved after the write. AWS describes Amazon DynamoDB global tables as a fully managed, multi-Region, and multi-active database feature, in which any global table replica can serve reads and writes. AWS states that global tables support two consistency modes: multi-Region eventual consistency (MREC) and multi-Region strong consistency (MRSC). Microsoft states that Azure Cosmos DB multi-region write accounts can't be configured for strong consistency, and that the region being written to responds immediately after Azure Cosmos DB replicates the data locally, while replicating it globally asynchronously. Microsoft states that in a multi-region-write database account with two or more regions, the first region where the account is created is the hub region, and writes that arrive in satellite regions are quorum committed in the local region, then sent to the hub region for conflict resolution asynchronously. Redis states that its Active-Active geo-distributed topology is achieved by implementing CRDTs (conflict-free replicated data types) in Redis Enterprise, using a global database that spans multiple clusters, called a conflict-free replicated database or CRDB. Redis states that a CRDB offers local latency on read and write operations, regardless of the number of geo-replicated regions and their distance from each other. Couchbase states that a bidirectional topology is created by implementing two unidirectional replications, in opposite directions, between two clusters. Couchbase states that XDCR provides options for conflict resolution, based on either sequence number or timestamp. Couchbase states that in Version 7.0 it made XDCR a commercial-only feature of Enterprise Edition. The Apache Cassandra project describes Cassandra as an open-source, distributed NoSQL database that implements a partitioned wide-column storage model with eventually consistent semantics. The Apache Cassandra project lists full multi-primary database replication and global availability at low latency among the design objectives of Apache Cassandra.
Distributed SQL platforms keep one order of writes across regions. AWS describes Amazon Aurora DSQL as a serverless, distributed relational database service for transactional workloads, whose active-active architecture provides 99.99% single-Region and 99.999% multi-Region availability. AWS states that both Regional endpoints of a multi-Region peered cluster present a single logical database and are available for concurrent read and write operations with strong data consistency. Google states that Spanner multi-region configurations are available with the Spanner Enterprise Plus edition. Google states that in a multi-region configuration the quorum (read-write) replicas are spread across more than one region, so applications get faster reads in more places at the cost of a small increase in write latency. Cockroach Labs states that a survival goal dictates how many simultaneous failures a database can survive, and that table locality determines how CockroachDB optimizes access to a table’s data. Cockroach Labs states that table localities can be global, regional by table, or regional by row, and that multi-region databases are configured by default to survive zone failures, with zone or region as the survival goals. Oracle describes Oracle Globally Distributed AI Database as a single logical database that automatically distributes and replicates data across nodes, regions, and countries. Oracle describes Raft replication and an Active-Active-Active distributed database architecture, designed for mission-critical applications, that enable failover within seconds.
Other platforms keep one writer region or one writer per data partition, or offer several writers through a separate replication product or within one cluster. AWS states that an Aurora global database consists of one primary AWS Region where data is written and up to 10 read-only secondary AWS Regions. MongoDB states that Atlas Global Clusters use zones, where each zone supports write and read operations from geographically local shards. MongoDB states that Atlas deploys the primary replica set member for the shards associated with a zone in a designated region, and that clients can issue write operations only to the primary. Oracle states that GoldenGate enables active-active read/write capabilities across multiple regions. MySQL documentation states that in multi-primary mode no member has a special role, and any compatible member is set to read/write mode when joining the group and can process write transactions, even if they are issued concurrently. MySQL documentation states that Group Replication is an eventual consistency system: while traffic is flowing, transactions can be externalized on some members before others, creating the possibility of stale reads.
Ask each vendor what a read in one region returns while a write in another region is in flight, how a conflict is resolved, and which edition and regions the feature needs.
| One writer region, read copies elsewhere | Several writer regions, conflicts resolved after the write | Several writer regions, one consistent order | |
|---|---|---|---|
| Where writes go | The primary region only | The nearest region | Any region in the configuration |
| What a read returns | The latest write in the primary; a slightly older copy elsewhere | The local copy, which can briefly differ from other regions | The latest committed write in every region |
| Same record changed in two regions | Cannot happen: one writer | Resolved by a rule such as last writer wins, a sequence number or a timestamp | One write commits first; the other waits or retries |
| Write latency | Low in the primary region; remote writes travel to it | Low in every region | Higher, because regions agree on each write |
| When a region fails | Promote a secondary region | Other regions keep accepting writes | Remaining regions keep accepting writes if a quorum survives |
How do you evaluate Operational Database Platforms?
Start with the data model. Relational tables with foreign keys suit orders, ledgers and anything joined across entities. Document databases store a record and its nested parts as one JSON document, which suits data whose shape changes often. Key-value stores answer lookups by key at very low latency and are often a cache beside the main database.
Check transaction guarantees in writing. Ask which isolation level is the default, which levels are available, and what the application must do when a transaction is retried. Google states that at serializable isolation Spanner provides external consistency: the system behaves as if all transactions run sequentially, even though Spanner runs them across multiple servers and possibly multiple datacenters.
Compatibility decides migration cost. An engine that speaks another engine’s wire protocol lets you keep drivers and most SQL, but extensions and stored procedures may differ. Microsoft states that Azure Database for PostgreSQL runs the community version of PostgreSQL, which provides full application compatibility and requires minimal refactoring to migrate an existing PostgreSQL application. Microsoft states that Azure SQL Managed Instance has near 100% compatibility with the latest Enterprise Edition SQL Server Database Engine.
High availability and recovery come next: automatic failover within a region, backups with point-in-time restore, and a tested plan for losing a whole region. Ask each vendor for the recovery point and recovery time it supports, in writing, for the configuration you will buy.
Check extensibility, and where else the engine can run. The PostgreSQL project states that PostgreSQL runs on all major operating systems, has been ACID-compliant since 2001, and has add-ons such as the PostGIS geospatial database extender. Google describes AlloyDB Omni as a downloadable edition of AlloyDB designed to run in your data center, on your laptop, at the edge, and in any cloud.
Security and operations close the list: encryption at rest and in transit, customer-managed keys, auditing, private networking, and the monitoring you get without extra tools.
| Capability | What it does | Buyer translation |
|---|---|---|
| Data model | Tables, JSON documents, key-value, or several in one engine | Whether your data and queries fit without workarounds |
| Transactions and isolation | ACID guarantees and the default isolation level | What the application must handle: retries, stale reads, conflicts |
| Compatibility | Wire protocol and SQL dialect of a known engine | How much code changes in a migration, and whether you can move again |
| High availability | Replicas and automatic failover within a region | Downtime when a server or zone fails |
| Multi-region | Read copies or writes in other regions | Behavior when a region fails, and write latency for distant users |
| Operations | Backups, patching, upgrades, monitoring | Who does each task: the service or your team |
| License | Open source, source-available or commercial terms | What you may run, modify and offer as a service |
Vendors in Operational Database Platforms
Representative vendors include Amazon Aurora & DynamoDB, CockroachDB, Google AlloyDB & Cloud Spanner, Microsoft SQL Server / Azure SQL, MongoDB Atlas, MySQL, Aurora MySQL & HeatWave, Oracle Database (Oracle AI Database) and PostgreSQL: managed RDS, Cloud SQL, Azure DB. The list is alphabetical, is not a ranking, and is not for sale. How we choose vendors
The approaches below follow two questions: who owns the engine, and how does it scale writes? Two platforms share each of the first three approaches. Ask every vendor to confirm in writing which features are in the edition and region you are quoted.
Commercial relational databases come from vendors that sell licenses and run their own clouds. Oracle states that Oracle AI Database 26ai replaces Oracle Database 23ai, and that features in 23ai are also available in 26ai. Oracle states that Oracle AI Database runs across OCI, AWS, Microsoft Azure, and Google Cloud. Microsoft describes Azure SQL Database as a fully managed platform as a service (PaaS) database engine that handles most database management functions, such as upgrading, patching, backups, and monitoring, without user involvement.
Open-source relational engines run anywhere, and every major cloud sells them as a managed service. The PostgreSQL project describes PostgreSQL as an open source object-relational database system whose origins date back to 1986, as part of the POSTGRES project at the University of California at Berkeley. Oracle describes MySQL Community Edition as a freely downloadable version that is available under the GPL license. Oracle describes MySQL HeatWave as a massively parallel, in-memory query accelerator for analytics and mixed workloads that requires no changes to existing applications. Oracle states that MySQL HeatWave can be deployed on Oracle Cloud Infrastructure (OCI), Amazon Web Services (AWS), or Microsoft Azure. On May 14, 2025, Databricks announced its intent to acquire Neon, a serverless Postgres company. Neon states that it has been part of the Databricks Platform since May 2025. Neon describes Lakebase Postgres as a serverless Postgres database that scales and branches with your app.
The cloud providers also build their own databases. AWS describes Amazon Aurora as a fully managed relational database engine that is compatible with MySQL and PostgreSQL. Google describes AlloyDB as a fully managed database service that automates administrative tasks such as backups, replication, patching, and capacity management. Their multi-region options are described in the multi-region section above.
A document database as a managed service stores JSON documents and runs on several clouds. MongoDB describes MongoDB Atlas as a fully managed cloud database service that automates provisioning, backups, scaling, and performance optimization. MongoDB states that Atlas supports multi-region and multi-cloud deployments in over 125 regions across AWS, Azure, and Google Cloud.
Distributed SQL spreads one relational database across servers and regions. Cockroach Labs states that by default CockroachDB executes all transactions at SERIALIZABLE, the strongest ANSI transaction isolation level, which permits no concurrency anomalies. Its multi-region settings and license are described above, and its prices below.
Two platforms outside the table appear in the multi-region and license sections above. One is Couchbase Capella: Couchbase describes Capella as the fully managed cloud service for Couchbase, the same engine as Couchbase Server, run on AWS, Google Cloud, and Azure. The other is Redis / Valkey: The Valkey project describes Valkey as an open source (BSD) key/value datastore that supports workloads such as caching and message queues, can act as a primary database, and is backed by the Linux Foundation.
| Vendor | Approach | Where it fits |
|---|---|---|
| Amazon Aurora & DynamoDB | Cloud provider’s own databases, relational and key-value | MySQL- and PostgreSQL-compatible Aurora; multi-active DynamoDB global tables; Aurora DSQL |
| Google AlloyDB & Cloud Spanner | Cloud provider’s own databases, relational and key-value | Managed AlloyDB, also as AlloyDB Omni; Spanner multi-region in Enterprise Plus |
| Microsoft SQL Server / Azure SQL | Commercial relational database, on premises and on every major cloud | Licensed per 2-core pack; Azure SQL Database and Managed Instance as managed services |
| Oracle Database (Oracle AI Database) | Commercial relational database, on premises and on every major cloud | Release 26ai; runs on OCI, AWS, Azure and Google Cloud; distributed and active-active options |
| CockroachDB | Distributed SQL, self-hosted or as a service | Serializable by default; survival goals per database; CockroachDB Software License |
| MongoDB Atlas | Document database as a managed service | Runs on AWS, Azure and Google Cloud; Free, Flex and Dedicated tiers |
| MySQL, Aurora MySQL & HeatWave | Open-source relational engine, self-run or managed by a cloud provider | Community Edition under the GPL; HeatWave on OCI, AWS and Azure |
| PostgreSQL: managed RDS, Cloud SQL, Azure DB | Open-source relational engine, self-run or managed by a cloud provider | Free and open source; managed by AWS, Google and Microsoft |
Eight platforms across five approaches; the first three approaches have two each. The approaches were set first and the platforms selected for each, keeping those this guide already covered. A row is not for sale. Couchbase Capella and Redis / Valkey are covered in the multi-region section. Many other databases compete for operational workloads, and any database vendor can present its own case in the Spotlight below.
How much should you budget for Operational Database Platforms?
Operational databases are priced in four ways: a license per core or server, a subscription for support, a managed service billed by the hour for compute plus storage, or a serverless service billed by use. Backups, replicas in other regions and data transfer between regions are billed separately on most managed services, so compare quotes that include them.
Commercial engines publish license prices. Microsoft lists SQL Server 2022 Enterprise at $15,123 and Standard at $3,945 per 2 core pack, as open no-level prices in US dollars, with the Developer and Express editions free. Microsoft states that the Azure SQL Database Hyperscale service tier has no SQL license fee and scales up to 128 TB. Oracle states that Oracle AI Database 26ai Free, offered absolutely free, lets you use up to 2 CPUs, 2 GB of RAM, and 12 GB of storage.
Open-source engines have no license fee for the engine itself. Support subscriptions, managed services and the staff who run the database are the cost.
Managed services bill compute by the hour. MongoDB lists Atlas Free at $0/hour, Flex at $0.011/hour (up to $30/month) and Dedicated at $0.08/hour (starts at $56.94/month). Cockroach Labs lists Cockroach Continuum Standard at $0.092 and Mission Critical at $0.162 per vCPU-hour, at rates for AWS us-east-1. Cockroach Labs states that all CockroachDB Cloud deployments automatically have a valid Enterprise license, that the paid Enterprise license allows use of all CockroachDB features, and that Enterprise Free offers the same functionality free of charge for businesses below an annual revenue limit.
Multi-region configurations multiply the bill: each region holds replicas, and writes between regions add transfer charges. Price the single-region and multi-region configurations separately before you decide whether you need writes in more than one region.
| Model | You are charged for | Grows with | Where it goes wrong |
|---|---|---|---|
| License per core or server | Each licensed core or server, plus client licenses in some models | Cores and servers | Virtual machines resized without relicensing |
| Support subscription | A yearly fee for support and paid features of an open-source engine | Servers or cores | Paid features adopted without budget for the subscription |
| Managed service by the hour | Compute per hour, storage per GB, backups | Instance size and number of replicas | Replicas and test instances left running |
| Serverless or consumption | Requests, compute used and storage | Traffic and data | An unbounded query or a traffic spike |
| Multi-region | Replicas in each region and transfer between them | Regions and write volume | Writes replicated to regions that only needed reads |
How long does implementation take for Operational Database Platforms?
Most of a database migration is testing, not copying data. Schema conversion, stored procedures, drivers and a cutover window set the schedule. Plan backward from the cutover date and replay production traffic against the new platform before you move.
Inventory schemas, stored procedures, extensions, drivers and the queries that matter most. Record current recovery point and recovery time targets, and decide whether the application needs writes in more than one region.
Convert the schema and procedural code, load a full copy of production data, and set up continuous replication from the old database so the copy stays current.
Replay a day of production queries at peak rate, force a failover, restore to a point in time, and for multi-region designs write the same record from two regions. Compare results and latency with the old database.
Stop writes, let replication catch up, switch the application and keep the old database read-only until the new one has run through a month-end or peak period. Then tune indexes and instance sizes on real traffic.
What should you ask vendors about Operational Database Platforms?
Ask each vendor to answer in writing and to demonstrate on a copy of your schema and data.
-
Must more than one region accept writes for the same data?Yes Shortlist platforms from section 3, and decide between conflict resolution and one consistent order.No A single-writer database with read copies or a standby region costs less and is simpler to run.
-
Do you have staff to patch, back up and fail over the database?Yes Running an open-source engine yourself is an option; price the people next to the licenses.No Shortlist managed services, and decide who will own query tuning and schema design.
-
Is the application already written for one engine?Yes Compare that engine’s managed services and compatible engines before a rewrite.No Choose the data model first, then the engine.