First, let me get this out of the way: this is not a Django vs Phoenix post. We at Cheesecake Labs believe polyglotism is good; it gives us options. Since the beginning, we’ve mostly been a Django shop for backend services and will continue to be for many years to come. It is a stable, fully-fledged and widely adopted framework that’s used to power a shocking amount of large applications, including many client projects that we’ve developed over the years.
Automated database migrations have been a convenient way of dealing with schema changes for a long time in Django. It’s been only 3 years since migrations have been incorporated into Django but South had been the de-facto solution since 2008.
The same way an ORM allows us to forget about SQL when writing queries to the database, migrations make sure we don’t write a single ‘ALTER TABLE’ in our schema changes. Some may argue that’s bad: we “lose control” over a critical part of our infrastructure, we don’t know how to write SQL anymore when needed, we’re not sure how that operation is really translated into SQL, etc, etc. Ok, these points are actually valid. However, Django migrations module is more than just a way of automatically generating and applying SQL statements, it’s also a transparent API to write your own database changes in Python. It comes with wheels for those who need it (or trust enough) and tools for those who like to get their hands dirty.
When we think about the process of developing an MVP, what we have in mind is to create great value in a short period of time, avoiding complexities and solving problems in the simplest way possible.
Then, on a beautiful sunny summer day, the Project Manager comes up and says:
“We need to create an MVP for a chat system in just one month!”