opomba,
Dostop do te strani zahteva pooblastilo. Poskusite se vpisati alispremeniti imenike.
Dostop do te strani zahteva pooblastilo. Poskusite lahko spremeniti imenike.
This article compares operational database services on Amazon Web Services (AWS) and Azure. It covers relational databases and non-relational data stores for document, key-value, wide-column, graph, and in-memory workloads.
For data integration, data lakes, data warehouses, stream processing, and business intelligence, see Analytics services on Azure and AWS.
Amazon RDS and Azure relational database services
Amazon Relational Database Service (Amazon RDS) provides managed relational database engines. Azure provides managed services for several corresponding engines:
- Azure SQL Database
- Azure Database for MySQL
- Azure Database for PostgreSQL
- SQL Database in Microsoft Fabric
You can also run SQL Server on Azure Virtual Machines. For Oracle workloads, evaluate Oracle AI Database@Azure and Oracle software on Azure infrastructure based on engine, support, and migration requirements.
Don't select a service based only on engine compatibility. Compare availability and disaster recovery requirements, scaling model, maintenance control, network isolation, authentication, extension support, migration downtime, and pricing.
Non-relational database services
AWS and Azure provide non-relational services for distinct data models. A compatible API doesn't guarantee feature or operational parity. Before migration, compare partitioning, consistency, transactions, indexing, query behavior, change streams, global distribution, throughput units, and client-driver compatibility.
Azure Cosmos DB supports multiple APIs and data models. Create a separate account for each API, and use the same API for all access to the data in that account. Azure also provides Azure DocumentDB for MongoDB-compatible, vCore-based document workloads and Azure Managed Instance for Apache Cassandra for managed open-source Cassandra clusters.
For in-memory caching and temporary data, Azure Managed Redis provides a managed service based on Redis Enterprise. Don't use it as the authoritative persistent database for a workload.
Service comparison
| Data model or capability | AWS service | Azure service | Selection guidance |
|---|---|---|---|
| Managed relational database | Amazon RDS | Azure SQL Database, Azure Database for MySQL, or Azure Database for PostgreSQL | Select by database engine first. Then compare high availability, read replicas, scaling, maintenance, extensions, and migration support. |
| Serverless relational database | Amazon Aurora Serverless | Azure SQL Database serverless or SQL Database in Microsoft Fabric | These services use different scaling and billing models. SQL Database serverless can automatically scale compute and pause during inactivity. SQL Database in Fabric consumes shared Fabric capacity and integrates operational data with Fabric analytics. |
| Key-value and document database | Amazon DynamoDB | Azure Cosmos DB for NoSQL | Both services distribute data by partition key and provide change streams. Their consistency, indexing, query, transaction, capacity, and pricing models differ. Plan application and data-model changes instead of assuming API compatibility. |
| MongoDB-compatible document database | Amazon DocumentDB | Azure DocumentDB or Azure Cosmos DB for MongoDB | Azure DocumentDB uses a vCore model and the MongoDB wire protocol. Azure Cosmos DB for MongoDB provides a distributed, request-unit or vCore-based service. Validate supported MongoDB versions, commands, extensions, scaling, and migration tooling. |
| Wide-column database | Amazon Keyspaces for Apache Cassandra | Azure Cosmos DB for Apache Cassandra or Azure Managed Instance for Apache Cassandra | Use Cosmos DB for Apache Cassandra when you want a managed Azure Cosmos DB service with Cassandra protocol compatibility. Use Managed Instance when you need managed open-source Cassandra clusters and greater engine-level compatibility. |
| Graph database | Amazon Neptune | Azure Cosmos DB for Apache Gremlin | Neptune supports property graph and RDF workloads. Cosmos DB for Gremlin supports the property graph model and Gremlin query language. RDF and SPARQL workloads require another design. |
| Table data | Amazon DynamoDB | Azure Table Storage or Azure Cosmos DB for Table | Use Table Storage for basic key-attribute storage. Use Cosmos DB for Table when you need globally distributed throughput, multiple consistency options, and Azure Cosmos DB capabilities. |
| In-memory cache and temporary data store | Amazon ElastiCache | Azure Managed Redis | Use Azure Managed Redis for caching, sessions, messaging, and other low-latency temporary-data patterns. Keep authoritative data in a persistent database. |
| Durable Redis-compatible database | Amazon MemoryDB | No direct equivalent | Amazon MemoryDB is designed as a durable primary database. Azure Managed Redis is a cache and temporary data store. On Azure, evaluate Azure Cosmos DB or another persistent database as the system of record, with Azure Managed Redis as an optional cache. |
| Database migration | AWS Database Migration Service | Azure Database Migration Service | Support varies by source, target, and online or offline migration mode. Verify the current supported Azure migration scenarios before you select a tool. |
Migration considerations
Database migration requires more than moving data. Inventory engine features, stored procedures, extensions, indexes, consistency assumptions, partition keys, transaction boundaries, change-data-capture dependencies, and operational processes. Test application behavior and performance against the target service before cutover.
If you plan to migrate an AWS workload to Azure, see Migrate databases from Amazon Web Services to Azure and its example migration scenarios.
Related resources
- Understand Azure data store models
- Migrate an application from DynamoDB to Azure Cosmos DB
- Compare Azure SQL deployment options
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
Principal author:
- Yuri Baijnath | Senior Cloud Solution Architect Manager
Other contributor:
- Richard Fitzgerald | Senior Cloud Solution Architect
To see non-public LinkedIn profiles, sign in to LinkedIn.