As we have mentioned, some consider Flask a transitional or educational framework that will inevitably lead to Django. However, others have concluded that the reverse applies—that Flask, in the hands of a developer now familiar with the bottlenecks and exigencies of a Python web framework, provides all the necessary building blocks for a mature implementation, and that Django is the one doing the preliminary 'hand-holding'.
In response to the oft-leveled criticism that Flask requires bespoke solutions to challenges that come pre-solved in Django, we should note that user-generated GitHub repositories address such shortfalls in the majority of cases.
Where rapid prototyping is a priority for development teams that have no specialization in either framework, Django will get the project to market sooner, with a performance penalty that in most cases is trivial, except at the highest volumes of data turnover.
In this regard, however, much depends on the data architecture adopted. Because Django assumes a number of set pathways and workflows for your project, it can sometimes prove to be brittle if you need to depart from its models and paradigms for any reason.
The binding relationship Django maintains between business logic, views, and database operations can make it inflexible or cause performance issues at scale, unless these factors are anticipated at design time.
For a brand-new build centered around Create, Read, Update, Delete (CRUD) functionality, unburdened by the complexities of migration from previous projects, Django is an attractive choice, so long as the strictures of its ORM implementation suit your needs.
If your project requires a higher level of interactivity with other systems, and particularly if it must negotiate with legacy data architectures, the extra upfront development time entailed in using Flask is likely to bring long-term reward.
*All stats in this article current as of August 2019