Django o Supabase: por qué nuestro ERP y nuestras apps usan stacks distintos

En nuestra web pone “tecnología adaptada a cada proyecto”, y no es una frase de relleno. Si miras nuestros proyectos verás dos familias:

• Almeebar ERP: Django REST, Next.js, PostgreSQL y Docker.
• BIT Project, BIT Talents y el gestor de mantenimientos: React, TypeScript y Supabase.

Las dos acaban en PostgreSQL, pero la forma de llegar es muy distinta. Estos son los criterios que usamos para elegir.

La pregunta clave: ¿dónde vive la lógica de negocio?

Si la lógica es compleja, cambia a menudo y tiene consecuencias legales o económicas, la queremos en un backend propio. Un ERP calcula impuestos, genera asientos contables, aplica retenciones según el tipo de proveedor y envía registros a la AEAT. Son reglas con muchos casos especiales que tienen que estar en un único sitio, probadas a fondo y versionadas.

Django es muy bueno para eso: un ORM maduro, migraciones fiables, un sistema de permisos completo, un panel de administración que se obtiene casi gratis y un ecosistema enorme de librerías (también fiscales y contables).

Si la lógica es sobre todo guardar, listar, filtrar y compartir datos con permisos claros, un backend como servicio nos ahorra semanas. Un tablero de tickets, una plataforma de ofertas de empleo o un registro de órdenes de trabajo encajan aquí. Supabase nos da autenticación, una API generada a partir del esquema, almacenamiento de ficheros y actualizaciones en tiempo real desde el primer día.

Los criterios, uno a uno

Criterio	Nos inclina a Django	Nos inclina a Supabase
Lógica de negocio	Compleja, regulada, con muchos cálculos	Mayoritariamente CRUD con reglas de acceso
Procesos en segundo plano	Muchos y largos (colas, envíos, integraciones)	Pocos y cortos
Integraciones con terceros	Muchas, con protocolos variados (SOAP, ficheros, mTLS)	Pocas, sobre todo HTTP
Tiempo real	Opcional	Importante (tableros, notificaciones)
Tiempo hasta la primera versión	Puede ser más largo	Muy corto
Equipo	Perfil backend fuerte	Perfil frontend fuerte

Lo que nos gusta de cada uno (y lo que vigilamos)

Django. Lo mejor es tener control total: tests de dominio, transacciones explícitas y la posibilidad de desplegarlo donde queramos con Docker. A cambio, hay más piezas que mantener (servidor, colas, workers, autenticación) y la primera versión tarda más.

Supabase. Lo mejor es la velocidad y que la seguridad se define en la base de datos con Row Level Security: cada fila sabe quién puede leerla o modificarla. A cambio, hay que ser muy riguroso con esas políticas, porque un error en ellas expone datos. Además, cuando la lógica crece, hay que decidir con criterio qué va en funciones de base de datos y qué en funciones edge, para que no acabe repartida por todas partes.

Así se ve una política, por ejemplo en un tablero de tickets donde cada persona solo ve y crea los suyos:

alter table tickets enable row level security;

-- Cada persona solo ve sus tickets...
create policy "ver mis tickets" on tickets
  for select to authenticated
  using ( (select auth.uid()) = owner_id );

-- ...y solo puede crear tickets a su nombre.
create policy "crear mis tickets" on tickets
  for insert to authenticated
  with check ( (select auth.uid()) = owner_id );

Con RLS activada y sin políticas, nadie accede a nada: se deniega por defecto. El error peligroso es el contrario, una tabla a la que se les olvidó activar RLS, porque la API generada la deja expuesta. Por eso revisamos las políticas como si fueran código de producción: porque lo son.

El argumento que más pesa: la salida

Elegimos Supabase con tranquilidad por un motivo: por debajo es PostgreSQL. Los datos, el esquema y las políticas son estándar. Si un proyecto crece tanto que necesita un backend propio, la migración es razonable: se puede poner un servicio delante de la misma base de datos e ir moviendo lógica poco a poco, con el mismo patrón que contamos en Migrar un sistema sin cortar el servicio.

Lo que sí habría que reemplazar es lo que trae la plataforma: autenticación, almacenamiento y funciones edge. Y como Supabase es de código abierto, también puede autohospedarse.

Evitamos plataformas en las que el modelo de datos queda atrapado en un formato propietario.

En resumen

• ERP, facturación, contabilidad, integraciones con la administración → backend propio (en nuestro caso, Django).
• Herramientas de gestión, portales, apps internas con usuarios y permisos → Supabase y un frontend en React.
• En cualquier caso → PostgreSQL debajo, para no cerrarnos ninguna puerta.

No hay un stack mejor en abstracto, sino el que encaja con el problema, el equipo y el presupuesto de cada proyecto.

¿Estás decidiendo la arquitectura de tu próximo proyecto? Te ayudamos a definirla antes de escribir la primera línea.