What is Django and why it remains a great decision
Published on 2026-09-12 by frfrand
Un framework que trae todo resuelto: ORM, migraciones, panel de administración y seguridad por defecto. Qué gana y qué cuesta elegirlo, y en qué casos conviene otra cosa.
Django is a Python web framework that was born in 2005 in the newsroom of a newspaper, to publish news quickly. That heritage explains a lot about its character: it’s built so a small team can get something complete live without debating every piece.
The philosophy: batteries included
There are two schools of frameworks. One gives you the minimum and you choose each component. The other gives you everything decided and you write your application on top of it.
Django is clearly of the second kind. It comes with the ORM, migrations, authentication, the permissions system, the admin panel, templates, form validation, and a bunch of security protections enabled by default.
That means less freedom in decisions that, honestly, most projects don’t need to make. And it means the project you start today will look like someone else’s, which is a huge advantage when a new person joins the team.
What really saves time
The ORM. You describe your data as Python classes and Django talks to the database for you. You don’t write SQL for common cases, although you can when needed.
Migrations. You change a model, run a command, and Django generates the file that updates the database. That file is versioned with the code, so the production database and your teammate’s end up the same. It’s one of the best-solved things in the ecosystem.
The admin panel. This is the one that most surprises those coming from elsewhere. From your models, Django generates a functional back office: listing, searching, filtering, creating, editing, with per-user permissions.
It’s not for end users; it’s for the team to manage data without building screens. Many projects survive months with this panel as their only internal interface.
Security by default. Protection against CSRF, automatic escaping in templates to prevent HTML injection, parameterized queries that prevent SQL injection, proper password hashing. All turned on by default. It’s hard to overstate how valuable this is in a project without a dedicated security person.
What it costs
It’s opinionated. If you want to do things your way, you’ll fight it. The correct way to work with Django is to accept its conventions.
The ORM hides the SQL. It’s convenient until a query becomes slow. The classic problem is N+1: you iterate over a list and for each item, another query fires. It’s fixed with select_related and prefetch_related, but first you have to notice it—and for that, you need to know how to inspect the SQL it generates.
It’s synchronous by tradition. Django has had async support for several versions, but much of the ecosystem still thinks synchronously. For thousands of simultaneous open connections (websockets, for example), there are more natural tools.
When to choose it
It fits very well when there is a data model with real relationships, when an admin panel is needed, when the team is small, and when the project is expected to last. This is the case for most business applications.
It fits poorly if you're building a minimal API with just two endpoints, if the core of the system is real-time, or if you're not going to use a relational database.
How to put it into production
Django does not serve itself. The standard setup consists of three components: nginx in front as a reverse proxy, an application server (Gunicorn or uWSGI) running your code, and Django inside.
And a warning that applies throughout the article: DEBUG set to False in production. With DEBUG enabled, any error shows the visitor the full traceback, including paths, configuration, and code snippets. This is the most common information leak in the entire ecosystem.
In ArduMaker, a Django project is deployed from GitHub like any other repository: build on the server, systemd service for Gunicorn, and nginx with the domain and certificate already resolved.