Making sense of Docker Compose overrides

How to use overrides to enable environmental differences

While building a new application recently, our data team decided they were keen on using Amazon Aurora with the MySql interface as the data store.

This was a perfect choice. Aurora is a powerful database service from AWS with a distributed, fault-tolerant, self-healing storage system that auto-scales instantly, as well as lightning fast performance (Amazon claims Aurora is up to 5x faster than traditional MySql).

However, this created a conundrum. For our production system, Aurora made perfect sense. For our developers and testers, however, the return on investment for each of us to have our own Aurora instance was just not there. Not only were there cost implications, there was the issue of managing these developer and test databases, which was an overhead our Ops team was not prepared to take on board.

Luckily for us, Aurora is designed with either a MySql or PostgreSQL interface, meaning that as long as our developers and testers were using a local MySql database for local development and testing, there would be no reason the new API code wouldn’t work just as well when pointed at our production Aurora database as when pointed at their own local databases.