Our company is thinking of migrating from SQL Server to Amazon AuroraDB.

In SQL Server, there are AlwaysOn and Transactional Replication - two different things.

  1. AlwaysOn is utilized more for disaster recovery, it sends whole database to another cluster, providing database level protection. The data is sent directly with a transaction log redo thread. Microsoft AlwaysOn

  2. In Replication, data is first sent to a distribution database then to a subscriber. Replication allows for only certain tables to be sent, with different schema and indexes on subscriber, which can be different from Publisher. Microsoft Replication

Is AWS High Availability similar to MS AlwaysOn Disaster Recovery or Replication? It seems more similar to AlwaysOn.

If so, does it have a Replication type technology? We want to make schema changes on the subscriber. (add indexes, remove certain tables not required in reporting env)


  • Are you going to use MySQL or PostgreSQL compatibility in Aurora? – SQLRaptor Jun 1 '18 at 17:35
  • we are migrating from SQL Server into Aurora, did not know there was a choice between Aurora-MYSQL Compatibility version, and Aurora PostgreSQL version,I though Aurora was compatible with both – user129291 Jun 1 '18 at 17:39
  • You haven't tried it yet :-) docs.aws.amazon.com/AmazonRDS/latest/UserGuide/… - scroll down to AWS Management Console -> Launching an Aurora DB Cluster - and look at the bottom of the screenshot. you must pick compatibility of either PostgreSQL, MySQL 5.6, or MySQL 5.7 when creating a cluster. – SQLRaptor Jun 1 '18 at 17:55

AWS Aurora's replication is more akin to Always On Availability Group. The primary pushes storage changes to other replicas. You don't get to make schema changes on the subscriber.

More details are available in several re:Invent deep dive sessions.

  • Aurora is Master-Slave with no Schema differences (both on MySQL and PostrgreSQL) – eckes Jun 1 '18 at 19:37
  • @BlueLamp82 if you've ever tried to manage replication in a situation where other people can change the database schema, you'll understand why. It's a giant pain in the rear. Customers would be able to break replication easily, and then they'd think it's AWS's fault. – Brent Ozar Jun 2 '18 at 10:04

This may not have been the case when the question was asked but the docs now show a table that clearly answers this question.

enter image description here

So you can have a different schema in binlog replicas but not Aurora replicas.

As noted in a comment in the other answer this approach can have drawbacks if you intend to modify parts of the schema that are replicated from the master, but it can still have value as a simple/reliable/cheap extract and load mechanism where you could build adjacent schemas in a MySQL RDS replica.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy