Arquitectura híbrida: Lo mejor de los dos mundos con Supabase y Spring Boot

Publicado el 14 January 2026

tiempo de lectura : 12 minutes

En lugar de elegir entre la simplicidad de Supabase y la potencia de Spring Boot, ¿por qué no combinar ambos? Descubre una arquitectura híbrida que aproveche lo mejor de cada tecnología.

El Falso Dilema de la Arquitectura Moderna

Cuando se construye una aplicación moderna con un frontend estático, a menudo nos encontramos frente a una opción binaria:

  • Apostarlo todo a una solución Backend-as-a-Service(Supabase, Firebase) - simple pero limitada

  • Construir un backend completo(Spring Boot, Node.js) - poderoso pero complejo

Esta elección es un falso dilema. La arquitectura híbrida propone una tercera vía: usar cada tecnología donde sobresale.

Visión Arquitectónica

La Arquitectura Tradicional: Monolítica

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Arquitectura Tradicional" {
  actor Utilisateur as user
  component "Frontend" as frontend #LightBlue
  component "Backend monolítico" as backend #LightCoral {
    [Authentification]
    [CRUD]
    [Logique Métier]
    [Jobs]
    [APIs Tierces]
  }
  database "Base de datos" as db #LightGray

  user --> frontend
  frontend --> backend : Todas las solicitudes
  backend --> db
}

note right of backend
Todo pasa por el backend
incluso las operaciones simples
⚠️ Punto único de congestión
⚠️ Complejidad desde el inicio
⚠️ Acoplamiento fuerte
end note
@enduml

En este enfoque, incluso las operaciones más simples (lectura de un artículo, creación de un comentario) deben transitar por tu backend. Pagas el costo de la complejidad desde el primer día.

La arquitectura BaaS : Todo delegado

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Arquitectura BaaS Pura" {
  actor Utilisateur as user
  component "Frontend" as frontend #LightBlue
  cloud "Supabase / Firebase" as baas #LightGreen {
    [Auth]
    [Database]
    [Storage]
    [Edge Functions]
  }

  user --> frontend
  frontend --> baas : Todas las operaciones
}

note right of baas
Desarrollo rápido
Sin servidor que gestionar
⚠️ Limitado para lógica compleja
⚠️ Bloqueo del proveedor
⚠️ Edge Functions limitadas
end note
@enduml

Al contrario, delegar todo a un BaaS resulta atractivo al principio, pero muestra rápidamente sus límites cuando la lógica de negocio se complica.

La Arquitectura Híbrida: Separación de Responsabilidades

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

actor Utilisateur as user #LightBlue

package "Capa Frontend" {
  component "Sitio Estático JBake" as frontend #SkyBlue
}

package "Capa Simple (Supabase)" #LightGreen {
  component "Autenticación" as auth
  component "CRUD Básico" as crud
  component "Almacenamiento de Archivos" as storage
  component "Tiempo Real" as realtime
}

package "Capa de Negocio (Spring Boot)" #Coral {
  component "Lógica Compleja" as logic
  component "Orquestación" as orchestration
  component "Tareas Programadas" as jobs
  component "Integraciones" as integrations
}

database "PostgreSQL Compartido" as db #LightGray

user --> frontend

frontend --> auth : OAuth2, JWT
frontend --> crud : Artículos, Perfiles
frontend --> storage : Imágenes, Archivos
frontend --> realtime : Notificaciones

frontend --> logic : Cálculos, Informes
frontend --> orchestration : Flujos de trabajo
logic --> integrations : Stripe, APIs
orchestration --> db
jobs --> db

crud --> db
auth --> db

note bottom of db
**Una única fuente de verdad**
Compartida entre Supabase y Spring Boot
end note

note right of auth
Gratis hasta 50k usuarios
Configuración en unos pocos clics
OAuth2 multi-proveedores
end note

note right of logic
Activado solo si es necesario
Kotlin + Coroutines
Transacciones complejas
end note
@enduml

La arquitectura híbrida separa claramente las responsabilidades según la complejidad y la naturaleza de las operaciones.

Principios de Diseño

Principio 1: Empezar simple, evolucionar inteligentemente

@startuml
skinparam backgroundColor #FEFEFE

rectangle "**Fase 1 : MVP**" #LightGreen {
  component "JBake + Supabase" as mvp
  note right
✓ Desarrollo en días
✓ Costo : 0€
✓ Validación concepto
  end note
}

rectangle "**Fase 2 : Crecimiento**" #LightYellow {
  component "JBake + Supabase\n+ Spring Boot (opcional)" as growth
  note right
✓ Lógica de negocio emerge
✓ Primeros trabajos planificados
✓ Integraciones de terceros
  end note
}

rectangle "**Fase 3 : Escala**" #LightCoral {
  component "Arquitectura Completa" as scale
  note right
✓ Orquestación compleja
✓ Rendimientos optimizados
✓ Caché distribuido
  end note
}

mvp -down-> growth : Cuando la complejidad\nlo justifique
growth -down-> scale : Optimización\ncontinue
@enduml

No construyas Spring Boot si no lo necesitas.Empiece con Supabase, añada Spring Boot cuando la complejidad lo justifica.

Principio 2 : Separación por naturaleza de la operación

@startmindmap
skinparam backgroundColor #FEFEFE
* Operaciones\nAplicativas

left side

** Operaciones Simples\n(Supabase)
***_ CRUD Estándar
****_ Lectura
****_ Creación
****_ Actualización
****_ Supresión
***_ Autenticación
****_ Iniciar sesión/Logout
****_ OAuth2
****_ Gestión de sesión
***_ Almacenamiento
****_ Cargar archivos
****_ CDN automático
***_ Tiempo real
****_ WebSocket
****_ Notificaciones

right side

** Operaciones Complejas\n(Spring Boot)
***_ Lógica de negocio
****_ Cálculos complejos
****_ Reglas de negocio
****_ Validaciones avanzadas
***_ Orquestación
****_ Multi‑servicios
****_ Transacciones distribuidas
****_ Patrones Saga
***_ Tareas Programadas
****_ Informes periódicos
****_ Sincronizaciones
****_ Limpiezas
***_ Integraciones
****_ Pagos (Stripe)
****_ APIs terceras
****_ Servicios ML/AI

@endmindmap

Principio 3 : Una única fuente de verdad

@startuml
skinparam backgroundColor #FEFEFE

database "PostgreSQL" as db #LightGray {
  package "Esquema: auth (Supabase)" #LightGreen {
    [users]
    [sessions]
    [identities]
  }

  package "Esquema: public (Compartido)" #SkyBlue {
    [articles]
    [comments]
    [profiles]
  }

  package "Esquema: negocio (Spring Boot)" #Coral {
    [orders]
    [payments]
    [reports]
  }
}

component "Supabase" as supabase #LightGreen
component "Spring Boot" as spring #Coral

supabase -down-> users : ¡Gestiona!
supabase -down-> sessions : Gestiona
supabase -down-> articles : Accede
supabase -down-> comments : Accede
supabase -down-> profiles : Accede

spring -down-> articles : Accede
spring -down-> profiles : Accede
spring -down-> orders : Gestiona
spring -down-> payments : Gestiona
spring -down-> reports : Gestiona

note right of db
**Ventajas :**
• Sin sincronización compleja
• JOINs posibles entre tablas
• Coherencia garantizada
• Migraciones unificadas
end note
@enduml

Al compartir la misma instancia de PostgreSQL, Supabase y Spring Boot trabajan en los mismos datos sin sincronización compleja.

Orquestación de los flujos

Flujo 1: Autenticación centralizada

@startuml
skinparam backgroundColor #FEFEFE
autonumber

actor "Usuario" as user
participant "JBake" as jbake
participant "Supabase Autenticación" as auth
participant "Spring Boot" as spring
database "PostgreSQL" as db

== Authentification ==
user -> jbake : Clique "Conectarse"
jbake -> auth : Redirigir OAuth2 (Google/GitHub)
auth -> user : Pantalla de consentimiento
user -> auth : Permite
auth -> auth : Genera JWT
auth -> jbake : Devuelve JWT + token de actualización
jbake -> jbake : Almacena tokens (sessionStorage)

== Accès aux Ressources ==
group Opération Simple (CRUD)
  user -> jbake : Crea un artículo
  jbake -> db : POST con JWT
  note right: Supabase Seguridad a nivel de fila\ncomprueba el JWT automáticamente
  db -> jbake : Artículo creado
end

group Opération Complexe (Métier)
  user -> jbake : Generar un informe
  jbake -> spring : POST /api/reports\ncon JWT
  spring -> spring : Valida JWT Supabase
  spring -> spring : Extracción reclamaciones (user_id, roles)
  spring -> db : Consultas complejas
  spring -> jbake : Informe generado
end

note over auth, spring
**El JWT es universal**
Válido por Supabase y Spring Boot
No double autenticación
end note
@enduml

Punto claveUn solo proceso de autenticación, un solo JWT, utilizable en todas partes.

Flujo 2: Orquestación de un proceso de negocio complejo

@startuml
skinparam backgroundColor #FEFEFE
autonumber

actor "Cliente" as user
participant "JBake" as jbake
participant "Spring Boot" as spring
participant "Supabase BD" as supadb
participant "Stripe API" as stripe
participant "Servicio de Inventario" as inventory
participant "Servicio de Correo" as email
database "PostgreSQL" as db

user -> jbake : Haz el pedido
jbake -> spring : POST /api/orders/create

== Orchestration Spring Boot ==
spring -> db : BEGIN TRANSACTION

par Vérifications Parallèles
  spring -> inventory : Verificar stock
  inventory -> spring : Stock OK
else
  spring -> db : Verificar perfil del cliente
  db -> spring : Cliente verificado
end

spring -> stripe : Crear Payment Intent
stripe -> spring : Intent creado (ID: pi_xxx)

spring -> db : Crear Order (status: PENDING)
db -> spring : Orden creada

spring -> stripe : Confirmar pago
stripe -> spring : Pago confirmado

spring -> db : Actualizar pedido (estado: PAID)
spring -> inventory : Decrementar stock
spring -> db : COMMIT TRANSACTION

par Notifications Asynchrones
  spring -> email : Confirmación de correo electrónico
else
  spring -> supadb : Insertar notificación
  note right: Notificación en tiempo real\nvia Supabase Realtime
end

spring -> jbake : Pedido confirmado
jbake -> user : Mostrar confirmación

note over spring
**Responsabilidades Spring Boot :**
• Transacción ACID
• Orquestación multi‑servicios
• Reversión automática si error
• Gestión de casos límite
end note
@enduml

Lo que Spring Boot aporta: Orquestación fiable de procesos complejos que involucran varios sistemas con garantía transaccional.

Flujo 3: Trabajos Programados y Sincronizaciones

@startuml
skinparam backgroundColor #FEFEFE

participant "Programador\n(Spring Boot)" as scheduler
participant "Reporte Servicio" as report
participant "PostgreSQL" as db
participant "Externo API" as api
participant "Correo Servicio" as email
participant "Supabase Almacenamiento" as storage

== Job Quotidien : 2h00 ==
activate scheduler
scheduler -> report : Desencadena la generación del informe

activate report
report -> db : Obtener datos\nde las últimas 24h
db -> report : Conjunto de datos

report -> report : Cálculos y Agregaciones
report -> report : Generación PDF

report -> storage : Subir PDF
storage -> report : URL publique

report -> email : Envía a los administradores\ncon enlace PDF
deactivate report

== Job Hebdomadaire : Domingo 3:00
scheduler -> report : Sincronización externa

activate report
report -> api : Obtener datos externos
api -> report : Nuevos datos

report -> db : Actualización de tablas
report -> db : Limpieza de datos obsoletos
deactivate report

== Job Mensuel : 1º del mes ==
scheduler -> report : Facturación

activate report
report -> db : Lista clientes activos
report -> report : Cálculo de importes
report -> api : Generación de facturas (Stripe)
report -> email : Envío de facturas
deactivate report

deactivate scheduler

note right of scheduler
Imposible solo con Supabase
Edge Functions no adaptadas
para trabajos largos y recurrentes
end note
@enduml

Lo que Spring Boot aporta: Trabajos programados fiables con gestión de estado, reintento automático y ejecución garantizada.

Matriz de Decisión

¿Cuándo usar Supabase?

@startuml
skinparam backgroundColor #FEFEFE

start

:Nouvelle fonctionnalité à implémenter;

if (CRUD simple ?) then (oui)
  :✅ **Supabase**;
  stop
else (non)
  if (Authentification ?) then (oui)
    :✅ **Supabase Auth**;
    stop
  else (non)
    if (Upload fichiers ?) then (oui)
      :✅ **Supabase Storage**;
      stop
    else (non)
      if (Temps réel ?) then (oui)
        :✅ **Supabase Realtime**;
        stop
      else (non)
        if (Row Level Security\nsuffisante ?) then (oui)
          :✅ **Supabase + Policies**;
          stop
        else (non)
          :⚠️ **Considérer Spring Boot**;
          #Coral:Passer à l'arbre\nde décision Spring Boot;
          stop
        endif
      endif
    endif
  endif
endif

@enduml

¿Cuándo usar Spring Boot?

@startuml
skinparam backgroundColor #FEFEFE

start

:Nouvelle fonctionnalité complexe;

if (Orchestration\nmulti-services ?) then (oui)
  :✅ **Spring Boot**;
  stop
else (non)
  if (Transaction ACID\ncritique ?) then (oui)
    :✅ **Spring Boot**;
    stop
  else (non)
    if (Job planifié ?) then (oui)
      :✅ **Spring Boot Scheduler**;
      stop
    else (non)
      if (Intégration API\ntierce complexe ?) then (oui)
        :✅ **Spring Boot**;
        stop
      else (non)
        if (Calculs lourds\n> 10 secondes ?) then (oui)
          :✅ **Spring Boot**;
          stop
        else (non)
          if (Cache distribué\nnécessaire ?) then (oui)
            :✅ **Spring Boot + Redis**;
            stop
          else (non)
            :⚠️ **Probablement Supabase**;
            #LightGreen:Revenir à l'arbre\nde décision Supabase;
            stop
          endif
        endif
      endif
    endif
  endif
endif

@enduml

Ejemplos de Arquitectura por Tipo de Proyecto

Blog / Portafolio

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Blog Personal - 95% Supabase" {
  component "JBake" as jbake #SkyBlue

  package "Supabase (Gratis)" #LightGreen {
    [Auth: OAuth2 Google]
    [Articles (CRUD)]
    [Commentaires]
    [Images (Storage)]
    [Notifications Realtime]
  }

  package "Spring Boot (Opcional)" #LightCoral {
    [Newsletter Mensuelle]
    note bottom: Trabajo programado únicamente
  }

  database "PostgreSQL" as db

  jbake --> [Auth: OAuth2 Google]
  jbake --> [Articles (CRUD)]
  jbake --> [Commentaires]
  jbake --> [Images (Storage)]
  jbake --> [Notifications Realtime]

  [Articles (CRUD)] --> db
  [Commentaires] --> db
  [Newsletter Mensuelle] --> db
}

note bottom of "Spring Boot (Opcional)"
**Spring Boot no obligatorio**
Newsletter puede ser gestionada
por un servicio externo (Mailchimp)
end note
@enduml

Veredicto: 100% Supabase es más que suficiente.

Aplicación SaaS

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Application SaaS - Arquitectura Híbrida" {
  component "JBake / React" as frontend #SkyBlue

  package "Supabase" #LightGreen {
    [Auth Multi-tenant]
    [Profils Utilisateurs]
    [Données Simples]
    [Storage Documents]
  }

  package "Spring Boot" #Coral {
    [Facturation (Stripe)]
    [Analytics Avancées]
    [Rapports Mensuels]
    [Quotas & Limites]
    [Webhooks Stripe]
  }

  cloud "Servicios Externos" {
    [Stripe API]
    [SendGrid Email]
  }

  database "PostgreSQL Compartido" as db

  frontend --> [Auth Multi-tenant]
  frontend --> [Profils Utilisateurs]
  frontend --> [Données Simples]
  frontend --> [Facturation (Stripe)]
  frontend --> [Analytics Avancées]

  [Auth Multi-tenant] --> db
  [Profils Utilisateurs] --> db
  [Données Simples] --> db

  [Facturation (Stripe)] --> db
  [Facturation (Stripe)] --> [Stripe API]
  [Analytics Avancées] --> db
  [Rapports Mensuels] --> db
  [Rapports Mensuels] --> [SendGrid Email]
  [Webhooks Stripe] ..> [Stripe API] : Écoute
}

note right of "Spring Boot"
**Necesario para :**
• Gestión de suscripciones
• Facturación recurrente
• Cuotas dinámicas
• Analíticas complejas
• Webhooks fiables
end note
@enduml

Veredicto: Arquitectura híbrida necesaria. Supabase para lo esencial, Spring Boot para la parte crítica (pagos, facturación).

e‑commerce

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Comercio electrónico - 70% Spring Boot" {
  component "Tienda (JBake/React)" as frontend #SkyBlue

  package "Supabase" #LightGreen {
    [Auth Clients]
    [Catalogue Produits\n(lecture seule)]
    [Images Produits]
  }

  package "Spring Boot (Corazón del negocio)" #Coral {
    [Gestion Commandes]
    [Paiements Stripe]
    [Gestion Stock]
    [Calcul Frais Port]
    [Génération Factures]
    [Synchronisation ERP]
    [Emails Transactionnels]
  }

  cloud "Integraciones" {
    [Stripe]
    [Transporteur API]
    [ERP Externe]
  }

  database "PostgreSQL" as db

  frontend --> [Auth Clients]
  frontend --> [Catalogue Produits\n(lecture seule)]
  frontend --> [Gestion Commandes]

  [Auth Clients] --> db
  [Catalogue Produits\n(lecture seule)] --> db

  [Gestion Commandes] --> db
  [Paiements Stripe] --> [Stripe]
  [Gestion Stock] --> db
  [Calcul Frais Port] --> [Transporteur API]
  [Génération Factures] --> db
  [Synchronisation ERP] --> [ERP Externe]
  [Synchronisation ERP] --> db
}

note right of "Spring Boot (Corazón del negocio)"
Spring Boot esencial :
• Transacciones críticas
• Orquestación compleja
• Integraciones múltiples
• Cumplimiento legal
• Trabajos de sincronización
end note
@enduml

VeredictoSpring Boot indispensable. Supabase solo para auth y catálogo.

Estrategia de Migración Progresiva

@startuml
skinparam backgroundColor #FEFEFE

|Semaine 1-2|
start
:Crear proyecto Supabase;
:Configurar Auth (Google, GitHub);
:Definir esquema PostgreSQL inicial;
:Implementar CRUD básico sobre JBake;
:Desplegar MVP en GitHub Páginas;
note right
**Entregable :** Aplicación funcional
**Costo:** 0€
**Tiempo:** 1-2 semanas
end note

|Semaine 3-4|
:Observar uso real;
:Limitaciones del identificador;

|Décision|
if (Logique complexe\némerge ?) then (non)
  |Supabase|
  :Continuar con Supabase solo;
  :Agregar Edge Functions si es necesario;
  stop
else (oui)
  |Spring Boot|
  :Crear proyecto Spring Boot;
  :Configurar validación JWT Supabase;
  :Migrar lógica compleja a Spring Boot;
  note right
Migración selectiva
Solo lo que es complejo
  end note
endif

|Semaines suivantes|
:Desplegar Spring Boot (Cloud Run, EC2);
:Conectar a PostgreSQL Supabase;
:Implementar los primeros trabajos planificados;
:Incorporar APIs terceras;

stop

note right
Arquitectura híbrida final
Supabase + Spring Boot
en perfecta armonía
end note
@enduml

Costos y consideraciones operacionales

Estructura de Costos

@startuml
skinparam backgroundColor #FEFEFE

package "Costos Mensuales Estimados" {

  rectangle "Fase MVP\n(0-1000 users)" #LightGreen {
    [JBake (GitHub Pages): 0€]
    [Supabase: 0€]
    [Spring Boot: N/A]
    note bottom: Total: 0€/mois
  }

  rectangle "Fase Crecimiento\n(1k-10k users)" #LightYellow {
    [JBake (GitHub Pages): 0€]
    [Supabase: 0€]
    [Spring Boot (Cloud Run): 20-50€]
    [PostgreSQL (si séparé): 0-30€]
    note bottom: **Total: 20-80€/mois**
  }

  rectangle "Fase Escalan(10k-100k users)" #LightCoral {
    [JBake (Netlify Pro): 19€]
    [Supabase Pro: 25€]
    [Spring Boot (instances multiples): 100-300€]
    [Redis Cache: 20-50€]
    [Monitoring: 20€]
    note bottom: **Total: 184-414€/mois**
  }
}

note right of "Fase Escalan(10k-100k users)"
En esta etapa, los ingresos justifican ampliamente los costos
end note
@enduml

Responsabilidades Operativas

@startuml
skinparam backgroundColor #FEFEFE

package "Quién Gestiona Qué ?" {

  rectangle "Gestionado por Supabase (0 esfuerzo)" #LightGreen {
    [Authentification]
    [Base de données]
    [Backups automatiques]
    [Scaling automatique]
    [Monitoring DB]
    [Sécurité DB]
  }

  rectangle "Gestionado por GitHub (0 esfuerzo)" #SkyBlue {
    [Hébergement site statique]
    [HTTPS/SSL]
    [CDN global]
    [Déploiement automatique]
  }

  rectangle "Para Gestionar (Spring Boot)" #LightCoral {
    [Déploiement application]
    [Monitoring APM]
    [Logs centralisés]
    [Scaling horizontal]
    [Mises à jour sécurité]
  }
}

note bottom of "Para Gestionar (Spring Boot)"
Minimizable con:
• Cloud Run (serverless)
• Kubernetes (si necesario)
• Servicios gestionados (RDS, etc.)
end note
@enduml

Conclusión: El Equilibrio Perfecto

La arquitectura híbrida Supabase + Spring Boot no es un compromiso, es unasinergia.

Los principios a retener

@startmindmap
skinparam backgroundColor #FEFEFE
* Arquitectura\nHíbrida

** Comenzar Simple
***_ MVP con Supabase
***_ 0€ de coste inicial
***_ Validación rápida

** Evolucionar inteligentemente
***_ Agregar Spring Boot\nsi es necesario
***_ Migración progresiva
***_ Sin una reforma total

** Aprovechar las Fuerzas
***_ Supabase: Simplicidad
***_ Spring Boot: Potencia
***_ PostgreSQL: Fuente única

** Minimizar la Complejidad
***_ Sin sincronización
***_ Sin duplicación
***_ Arquitectura clara

** Optimizar los costos
***_ Gratis al principio
***_ Escalado progresivo
***_ ROI evidente

@endmindmap

¿Cuándo elegir esta arquitectura?

✅ Esta arquitectura es ideal si:

  • Quieres arrancar rápidamente (MVP en días, no en meses)

  • Anticipas un crecimiento de la complejidad del negocio

  • Quieres minimizar los costos iniciales

  • Te gusta PostgreSQL y quieres una única fuente de verdad

  • Ustedes aprecian Kotlin y las Corrutinas para el código de negocio

  • Quieres evitar el vendor lock-in total

�❌ Esta arquitectura NO es adecuada si :

  • Tu proyecto es simple y lo seguirá siendo (blog personal → 100% Supabase es suficiente)

  • Ya tienes una stack backend establecida que dominas

  • Prefiere un monolito tradicional

  • Necesitas .NET, Python, u otro lenguaje backend

Visión General Final

@startuml
skinparam backgroundColor #FEFEFE

package "Arquitectura Híbrida Completa" {

  actor "Usuarios" as users

  rectangle "Frontend (Estático)" #SkyBlue {
    [JBake / GitHub Pages]
    note right: Gratis, CDN global
  }

  rectangle "Backend Simple (Supabase)" #LightGreen {
    [Auth OAuth2]
    [CRUD APIs]
    [Storage]
    [Realtime]
    note right
Gratuito hasta 50k usuarios
Cero configuración del servidor
    end note
  }

  rectangle "Backend de Negocio (Spring Boot)" #Coral {
    [Orchestration]
    [Jobs Planifiés]
    [Intégrations]
    [Transactions]
    note right
Activado solo si es necesario
    end note
  }

  database "PostgreSQL\nFuente Única de Verdad" as db #LightGray

  users --> [JBake / GitHub Pages]

  [JBake / GitHub Pages] --> [Auth OAuth2]
  [JBake / GitHub Pages] --> [CRUD APIs]
  [JBake / GitHub Pages] --> [Storage]
  [JBake / GitHub Pages] --> [Realtime]
  [JBake / GitHub Pages] --> [Orchestration]

  [Auth OAuth2] --> db
  [CRUD APIs] --> db
  [Orchestration] --> db
  [Jobs Planifiés] --> db
  [Intégrations] --> db
}

note bottom of db
**Una sola base, dos consumidores**
• Supabase para lo simple
• Spring Boot para lo complejo
• No se requiere sincronización
end note

@enduml

Lo mejor de los dos mundos

Esta arquitectura le da :

🚀 La velocidad de Supabase

  • Inicio en horas, no en semanas

  • Autenticación OAuth2 en unos pocos clics

  • APIs REST generados automáticamente

  • Cero configuración de servidor

💪 La potencia de Spring Boot

  • Kotlin y Coroutines para código asíncrono elegante

  • Orquestación de procesos de negocio complejos

  • Trabajos programados confiables

  • Transacciones ACID garantizadas

  • Ecosistema Spring completo

💰 La Economía Progresiva

  • 0€ para empezar y validar

  • Costos que siguen el crecimiento

  • No hay sobreingeniería prematura

🎯 La Flexibilidad Arquitectónica

  • Migración progresiva sin rediseño

  • Añadir Spring Boot solo si es necesario

  • Sin vendor lock-in total

  • Arquitectura evolutiva

Para ir más lejos

Recursos Técnicos

Documentación Supabase :

Documentación Spring Boot :

Artículos Complementarios :

  • Seguridad de las APIs con JWT

  • Optimización del rendimiento de PostgreSQL

  • Patrones de migración progresiva

  • Manejo de errores en arquitectura distribuida

Casos de uso reales

Esta arquitectura híbrida se utiliza con éxito en :

  • SaaS B2BAutenticación Supabase, facturación Spring Boot

  • marketplaces: Catálogo Supabase, transactions Spring Boot

  • Plataformas de contenido: Artículos Supabase, analítica Spring Boot

  • Herramientas internasCRUD Supabase, workflows Spring Boot

Checklist de Arranque

Fase 1 - Fundamentos (Semana 1)

  • Crear cuenta Supabase - [ ] Configurar proyecto PostgreSQL - [ ] Activar Autenticación (Google, GitHub) - [ ] Definir esquema inicial - [ ] Configurar la seguridad a nivel de fila - [ ] Probar APIs desde JBake

Fase 2 - MVP (Semana 2-3)

  • Implementar páginas principales - [ ] Integrar autenticación OAuth2 - [ ] Crear formularios CRUD - [ ] Configurar Storage para archivos - [ ] Desplegar en GitHub Pages - [ ] Probar en condiciones reales

Phase 3 - Evolución (Según necesidades)

  • Identificar necesidades de lógica compleja - [ ] Crear proyecto Spring Boot si es necesario - [ ] Configurar validación JWT Supabase - [ ] Conectar a PostgreSQL Supabase - [ ] Migrar funcionalidades complejas - [ ] Implementar trabajos programados - [ ] Desplegar Spring Boot (Cloud Run, etc.)

Antipatrones a evitar

No hacer:

  • Duplicar los datos entre Supabase y Spring Boot

  • Crear dos bases de datos PostgreSQL separadas

  • Codificar la autenticación usted mismo

  • Usar Spring Boot para un CRUD sencillo

  • sobrediseñar desde el principio

  • Ignorar Row Level Security de Supabase

✅ Hacer mejor :

  • Compartir una única base de datos PostgreSQL

  • Dejar que Supabase gestione la autenticación

  • Utilizar Spring Boot solo para la complejidad

  • Empezar simple, evolucionar gradualmente

  • Explotar las fortalezas de cada tecnología

  • Asegurar con RLS a nivel de base de datos

Perspectivas de Evolución

Adición de Nuevas Capacidades

@startuml
skinparam backgroundColor #FEFEFE

rectangle "Arquitectura actual" #SkyBlue {
  [JBake]
  [Supabase]
  [Spring Boot]
}

rectangle "Evoluciones posibles" #LightYellow {

  package "Performance" {
    [Redis Cache]
    [CDN pour Assets]
    [PostgreSQL Replicas]
  }

  package "Monitoreo" {
    [Grafana]
    [Prometheus]
    [Sentry]
  }

  package "CI/CD" {
    [GitHub Actions]
    [Tests Automatisés]
    [Déploiement Continu]
  }

  package "Funcionalidades" {
    [Search (ElasticSearch)]
    [Queue (RabbitMQ)]
    [Event Sourcing]
  }
}

[Spring Boot] .down.> [Redis Cache] : Peut ajouter
[Spring Boot] .down.> [Queue (RabbitMQ)] : Peut ajouter
[Spring Boot] .down.> [Search (ElasticSearch)] : Peut ajouter

[Supabase] .down.> [PostgreSQL Replicas] : Peut ajouter

note bottom
Arquitectura extensible
Cada adición es independiente
No se requiere una refactorización global
end note
@enduml

Escalado Horizontal

Cuando su aplicación crece, la arquitectura híbrida escala naturalmente :

Supabase:

  • escala automáticamente hasta millones de operaciones

  • Réplicas de lectura para rendimiento de lectura

  • Point-in-time recovery para seguridad

Spring Boot :

  • Múltiples instancias detrás de balanceador de carga

  • Diseño sin estado facilita el escalado horizontal

  • Kubernetes para orquestación si es necesario

PostgreSQL :

  • Particionamiento para tablas voluminosas

  • Pooling de conexiones (PgBouncer)

  • Sharding si realmente necesario (raro)

Testimonios arquitectónicos

Startup SaaS (50k usuarios)

_ Empezamos con Supabase al 100%. Con 5k usuarios, agregamos Spring Boot solo para la facturación de Stripe y los informes mensuales. Un año después, el 80% de nuestras operaciones sigue pasando por Supabase. Spring Boot gestiona solo la parte crítica. Esta separación nos permitió escalar sin rediseño. _

Plataforma E-learning (10k usuarios)

_ La autenticación OAuth2 de Supabase nos ha ahorrado 3 semanas de desarrollo. Las APIs autogeneradas gestionan todo nuestro catálogo de cursos. Spring Boot solo se utiliza para los certificados PDF y los correos de progreso. Arquitectura simple, mantenible y escalable. _

Marketplace B2B (3k usuarios)

_ Spring Boot gestiona las transacciones entre compradores y vendedores (crítica). Supabase gestiona todo lo demás: perfiles, mensajería en tiempo real, documentos. El hecho de que compartan la misma base de datos PostgreSQL nos evita cualquier sincronización compleja. Mejor elección arquitectónica que hayamos hecho. _

Síntesis : Un Paradigma Arquitectónico Moderno

La arquitectura híbrida Supabase + Spring Boot representa un nuevo paradigma:la especialización arquitectónica.

@startuml
skinparam backgroundColor #FEFEFE

rectangle "Paradigma antiguo" #LightCoral {
  card "Todo en el Backend" {
    [Auth]
    [CRUD]
    [Logique Métier]
    [Jobs]
    [Storage]
    [Realtime]
  }
  note bottom
Complejidad máxima
desde el día 1
  end note
}

rectangle "Nuevo paradigma" #LightGreen {
  card "Supabase\n(Commodité)" {
    [Auth]
    [CRUD Simple]
    [Storage]
    [Realtime]
  }

  card "Spring Boot\n(Différenciation)" {
    [Logique Métier]
    [Jobs]
    [Intégrations]
  }

  note bottom
Complejidad progresiva
añadida solo si es necesario
  end note
}

[Ancien Paradigme] -right-> [Nouveau Paradigme] : Évolution

@enduml

El principio fundamental :No construyas lo que ya existe como servicio. Concéntrate en lo que diferencia tu aplicación.

La regla del 80/20

En la mayoría de las aplicaciones :

  • 80% de las operacionesson CRUD estándar → Supabase

  • 20% de las operacionesnecesitan de la lógica de negocio → Spring Boot

Esta regla natural justifica la arquitectura híbrida.

@startuml
skinparam backgroundColor #FEFEFE

package "Distribución de Operaciones" {

  rectangle "80% - Operaciones Estándar" #LightGreen {
    [Lecture de données]
    [Création d'entités]
    [Mise à jour simple]
    [Suppression]
    [Upload fichiers]
    [Authentification]

    note bottom: Gestionado por Supabase
  }

  rectangle "20% - Lógica de Negocio" #Coral {
    [Calculs complexes]
    [Workflows multi-étapes]
    [Transactions critiques]
    [Intégrations tierces]
    [Jobs planifiés]

    note bottom: Gestionado por Spring Boot
  }
}

note right
Su tiempo de desarrollo concentrado en el 20 % que diferencia su producto
end note
@enduml

Conclusión Final

La arquitectura híbrida no es un compromiso técnico, es unadecisión estratégica.

Le permite:

  • �✅ Iniciar rápidamente con un MVP funcional

  • ✅ Validar su mercado sin una inversión pesada

  • �✅ Evolucionar progresivamente cuando la complejidad lo exija

  • �✅ Controlar tus costos en cada paso

  • ✅ Aprovechar lo mejor de cada tecnología

  • �✅ Evitar la sobre-ingeniería prematura

  • �✅ Conservar la flexibilidad para el futuro

Ella representa :

  • 🎯Pragmatismo: Cada tecnología en la que destaca

  • 🚀velocidad: Tiempo de comercialización mínimo

  • 💰EconomíaCostos alineados con el valor

  • 🔮EscalabilidadArquitectura que crece contigo

  • �🛡️robustezServicios probados y confiables

Tu próximo paso

Si esta arquitectura te habla, aquí tienes por dónde comenzar:

  1. Crear una cuenta Supabase(gratuito)

  2. Define tu esquema de datos mínimo

  3. Configura la autenticación OAuth2

  4. Cree su primera página JBake que consume la API

  5. Despliega en GitHub Pages

Tendrás un MVP funcional enunos días.

Spring Boot llegará naturalmente cuando lo necesites. No antes.

La arquitectura híbrida es el arte de construir exactamente lo que se necesita, cuando se necesita.

Buen desarrollo ! 🚀

Comparte este artículo si crees que puede ayudar a otros desarrolladores a tomar las decisiones arquitectónicas correctas.

Artículos relacionados

HyperFrames-Gradle: Convertir AsciiDoc a video MP4
31 May 2026
Auditoría de mi consumo LLM: SQLite, OpenCode, Ollama Cloud, y por qué mi suscripción Pro está revolucionando el mercado mundial
18 May 2026
La arquitectura “Plugin independiente + raíz consumidora”: ¿por qué mis builds de Gradle se duplican?
14 May 2026
El Knowledge Graph como motor de recomendación: cómo maté los « artículos conexos » cronológicos
12 May 2026