I really enjoyed my journey with FastAPI and I'm truly grateful for what it brought to the open-source ecosystem. But over time, I couldn't help noticing certain decisions that made me increasingly skeptical and doubtful.
Then one day, I came across a relatively unknown framework called "Litestar". Without much expectation, I took a quick look at the documentation—then a deeper one—and had a bit of a “wow” moment. I realized, with genuine excitement:
Oh boy, this is what FastAPI should have been from the start!
Let me explain why I believe Litestar deserves to replace FastAPI in the long run.
📦 Litestar has everything FastAPI offers out of the box ...
Async support, routing, data validation, middleware, strong typing, dependency injection, OpenAPI documentation generation—you name it.
🔋 ... But with much more batteries included
I worked with Django for many years, and the first thing that hit me in the face when I tried FastAPI was how much I had to set up myself. That’s not necessarily a bad thing, as sometimes you do need full control over the implementation. But more often than not, you don’t.
When your needs are basic and you're using a framework, you expect that framework to provide the tools you need. Otherwise, you're just wasting time reinventing the wheel.
And that’s exactly what happened when I needed basic pagination with FastAPI. How can you call yourself “Fast - API” and not include a feature almost every API needs?
At that point, I had two choices:
- Use an external package,
- Build it myself.
Spoiler alert: neither is a good option :/ Let me explain.
❌ Using external packages?
Many external packages in the FastAPI ecosystem don’t feel very solid: often maintained by a single person, full of unanswered issues, with limited community support and clunky documentation. The moment you rely on one of these, you’re adding risk to your project. You can’t upgrade confidently, and sometimes you have to wait for third-party packages to catch up before FastAPI becomes usable again. That happened to me multiple times.
External packages also create fragmentation. If another FastAPI developer joins the project, he'll have to learn how every third-party library works, which increases the learning curve unnecessarily.
Plus, picking an external library is a time sink. You need to find all the options, read the docs, evaluate their quality, make sure they work well, check if the maintainer is still active—and so on.
To me, external packages make sense for very specific or advanced needs. But for basic functionality, the core framework should handle it. Otherwise, it ends up bloated from the outside instead of structured from the inside.
Unlike frameworks like Django (or Litestar, of course), FastAPI doesn’t seem designed to support external apps cleanly. There’s no plug-and-play mechanism, and it’s not obvious which third-party tools are actually installed in your project.
❌ Building it myself? (DIY)
Sure, it’s fun, rewarding, and you learn a lot along the way. But let’s be honest: if you need to be productive (because time is money),there’s absolutely no reason to build it yourself. This kind of basic feature should come with the framework.
You shouldn’t have to rely on your own logic and unit tests for such low-level technical bricks. You want something that just works, 100%, out of the box.
You might argue that in some percentage of projects, pagination needs to be custom. Fair enough. But having built-in pagination doesn’t prevent you from rolling your own. Frameworks like Django even let you subclass the default pagination to create your own version.
So, do you see the issue? Pagination is just one example—but the same thing happens with tons of other basic needs: caching, middleware, and so on.
External packages can be useful, but when they end up forming the core of your framework, then you're not really using a framework anymore. You're using a microframework. Something more like Flask. Using a microframework is totally valid, until you start implementing or adding features that a real framework should provide.
⭐️ Why is Litestar different?
Litestar takes a different approach. While it remains relatively small compared to a full-featured and highly opinionated framework like Django, it still provides plenty of built-in tools that are easy to plug into your project. These tools are entirely optional and don’t impose any strict architectural decisions. But if you choose to use them, you know they’ll integrate seamlessly. And you know you won’t run into compatibility issues when upgrading Litestar.
They even build tools like Polyfactory, which can be used with any framework—but naturally fit perfectly within the Litestar ecosystem, since they’re built by the same team.
As a front-end analogy, it reminds me of Vue.js: you can use tools like Vitest with any framework, but they’re designed to work perfectly with Vue.
🔧 What batteries are we talking about?
Just to name a few: caching, channels, SQLAlchemy integration, DTO helpers, guards, JWT support, HTMX integration, stores, and much more.
Let’s be honest: you’re probably going to need some of this for any serious project. So what do you prefer? Spending days reinventing the wheel? Or wasting time evaluating half-baked third-party packages with questionable maintenance?
🌱 FastAPI isn't written from the ground up
A lot of what you import from FastAPI actually comes from Starlette. While that might seem like a minor detail, the more your framework relies on external tools, the more you're dependent on their design choices, limitations, and release cycles.
As a developer, it's also much more straightforward when everything lives in the same codebase. If you've ever read Django's source code, you know how awesome it is to understand how the framework works just by reading it.
Litestar makes a point of implementing key components internally, to provide a coherent and consistent developer experience.
Even Pydantic (which is a great tool) is optional. Litestar’s validation layer can work entirely with plain dataclasses.
The one notable exception is SQLAlchemy, which Litestar does rely on. But building an ORM is extremely complex, and it's easy to understand why most frameworks choose not to reinvent that wheel. In fact, Django is one of the rare exceptions in the ecosystem to offer its own fully integrated ORM.
👩🏻⚖️ About governance
One key difference between FastAPI and Litestar is governance. If you’ve followed FastAPI’s growth over the years, you might remember some turbulent periods when the project's sole maintainer struggled to keep up with the influx of issues. Some important bugs and feature requests went unanswered for months, and the maintainer was unwilling to bring others on board to help. His rationale? That he needed to stay in control of everything to ensure the project stayed on the right path.
While understandable to some extent, this slowed development significantly and left FastAPI in a state that many wouldn’t consider truly production-ready—at least not without patching and wrapping things yourself.
Litestar, on the other hand, was built from day one with a team-based mindset. It currently has five active maintainers, and the team is expected to grow. That feels more professional, more sustainable, and far more future-proof.
More than that, Litestar actively encourages contributions in all forms. It’s a great ecosystem to contribute to, especially since there’s always room to build new batteries that benefit the community.
This team-driven approach also lowers the risk of harmful or short-sighted decisions being made (see my next point).
📀 SQLModel was a bad idea
In short, SQLModel is the FastAPI author’s attempt to merge SQL model definitions and data validation into a single object, essentially combining SQLAlchemy and Pydantic into one.
While I loved the concept at first, there’s no shortage of experienced developers explaining why this approach doesn’t work. As soon as a project grows beyond toy-level complexity, most of them end up switching back to plain SQLAlchemy. Want proof? Just search for "SQLModel" on the FastAPI subreddit.
You might think SQLModel is just an alternative way to do things—but here’s the catch: the FastAPI author removed official documentation about using plain SQLAlchemy. That feels like an arbitrary move, as if he were promoting his own work while ignoring legitimate criticism.
So now we have experienced developers avoiding SQLModel entirely, and beginners jumping into FastAPI without realizing SQLModel isn’t required—and may even cause problems down the line. Mixing persistence logic and validation just to save a few lines of code is an anti-pattern. And once again, this leads to fragmentation.
All of this made one thing very clear to me: building critical software on top of a one-person project is a risk.
Conclusion
So, is FastAPI bad? Absolutely not. But there are clear gaps in the system that prevent the framework from reaching its full potential, despite its large and growing community.
Litestar, in my view, has understood those shortcomings and responded with a more thoughtful solution: a framework built from the ground up, packed with the tools you actually need, guided by clean governance, sleek documentation, and solid, sustained traction on GitHub.
This project deserves far more attention. To me, it hits the sweet spot, right between the highly opinionated (and aging) Django, and a FastAPI that, despite its promises, has drifted down the wrong path.