FastAPI is rising fast with true async support.
Django is steadily moving in the same direction.
Most teams are leaving Flask behind.
So why did we still choose Flask in 2026 ?
Because trends and benchmarks don’t build systems, teams do. And the right framework is the one that fits both the service and the people building it.
Is Flask still a reasonable choice in 2026?
Short answer: it depends on what you’re building.
In our case, we’re running a microservice architecture with multiple backend services. One of the newer additions was a reporting service — and this service had very different requirements compared to our core APIs.
This wasn’t a service users hit constantly. Because of that, cost efficiency mattered.
There was no real reason to keep a service running 24/7 for something that’s only accessed occasionally.
What we didn’t need
- Massive async concurrency for high-throughput APIs
- Ultra-low latency at the millisecond level
- A steep learning curve
What we actually needed
Predictable, stable behavior
Simple code that’s easy to read and reason about
A framework that works well with serverless and AWS services
Something the team could adopt and maintain quickly
That’s where Flask started to make more sense than newer, more complex alternatives.
1) Simplicity
For this service, simplicity wasn’t a “nice to have” — it was a requirement.
In flask, If you know Python, you can read the code and understand what’s happening without learning a new mental model or framework-specific abstractions.
If something happens in a Flask application, it’s usually because you explicitly wrote it.
In more opinionated frameworks, new engineers may follow built-in conventions without fully understanding them, which can sometimes lead to unexpected behavior.
2) Database flexibility (why Django didn’t fit)
Django is designed with relational databases as its primary data store, and its ORM is tightly coupled to that model.
While Django can work alongside NoSQL databases, they are typically used as secondary data stores, not the primary one.
With Flask, we didn’t have to fight the framework. We could integrate DynamoDB directly using plain Python and keep full control over how data was stored and accessed.
This flexibility allowed us to design the data layer around our needs, instead of reshaping our architecture to fit the framework.
3) In-process analytics (Why FastAPI didn’t fit)
Our reporting data is stored in Amazon S3 as Parquet files. Every day, we update these files and use them to generate reports when users request them.
To query this data, we use Apache DataFusion from within the service.
This workload is a mix of:
I/O-bound operations (reading data from S3)
CPU-bound operations (aggregations and calculations)
Because of this, a fully async framework didn’t give us a clear advantage. Async works best when the workload is mostly waiting on I/O, but in our case, heavy computation is a big part of the process.
Flask’s simple, multi-threaded execution model worked well for this balance. It allowed us to keep the data processing logic inside the service without introducing extra complexity.
4) Use AWS ecosystem
Our reporting service is deeply integrated with AWS services. We rely on Amazon S3, Amazon DynamoDB, and other AWS components for storage, configuration, and monitoring.
In Python, the official way to work with AWS is boto3.
The important detail here is that boto3 is synchronous. While there are async alternatives, they are not fully supported, don’t cover all services, and can introduce edge cases that are harder to debug in production.
For us, stability mattered more than forcing everything to be async.
Using Flask with boto3 meant:
Official SDK support
Predictable behavior
Easier debugging when things go wrong
Instead of building async workarounds around the AWS SDK, we chose a framework that works naturally with the tools we already depend on.
5) Serverless first, containers later
Because the reporting service isn’t part of our core, always on user flow, running dedicated servers didn’t make much sense.
Most users see reports:
once a week
or once a month
Keeping a service running 24/7 for that usage pattern would have been unnecessary overhead.
So we decided to run the service on AWS Lambda.
Flask worked well in this setup:
Cold starts were acceptable for our use case and reduced further through health checks
The request–response model stayed simple
As a microframework, Flask has a faster startup time
Easy integration with AWS services
Just as importantly, this decision didn’t lock us in.
If usage grows in the future or reporting becomes more critical, we can move the same service to containers on Amazon ECS with minimal changes. The application code doesn’t need a major rewrite.
That flexibility mattered to us.
Flask allowed us to start small, keep costs low, and still leave the door open for scaling later — without overengineering from day one.
Final thoughts
Choosing a framework in 2026 isn’t about following trends or chasing benchmarks. It’s about understanding the nature of the service, the team building it, and the real constraints in production.
The takeaway is simple:
The “best” framework isn’t the one everyone is talking about.
It’s the one your team can build, scale, operate, and maintain with confidence.
For us, even in 2026, we can choose Flask.
Top comments (0)