DOMINICODE

Tag: Supabase

  • Neon vs Supabase: comparación técnica honesta (2026)

    Neon vs Supabase: comparación técnica honesta (2026)

    Hace unos meses estaba arrancando un proyecto nuevo. Stack limpio, decisiones por tomar. Y en cuestión de minutos tuve el debate de siempre en el canal de decisiones técnicas: ¿Neon o Supabase?

    Los dos son Postgres. Los dos tienen free tier. Los dos aparecen en casi cualquier lista de "stack moderno para SaaS". Y los dos hacen cosas completamente distintas.

    Este post es la Neon vs Supabase comparación técnica que me hubiera ahorrado dos horas de lectura de docs.

    Qué es cada uno en una línea

    Neon: Postgres serverless puro con branching de base de datos y scale-to-zero.

    Supabase: Plataforma BaaS construida sobre Postgres — incluye Auth, Storage, Realtime y Edge Functions en un solo sitio.

    La diferencia de fondo: Neon es una base de datos. Supabase es un backend completo que usa Postgres como motor.

    Tabla comparativa

    Criterio Neon Supabase
    Tipo Postgres serverless BaaS completo sobre Postgres
    Scale-to-zero Sí, nativo No en producción (pausa en free tier)
    Branching de DB Sí, copy-on-write instantáneo Solo Pro+ (beta); provisiona DB nueva + migraciones
    Auth nativo No Sí (JWT, OAuth, Magic Link)
    Storage nativo No Sí (S3-compatible)
    Realtime No Sí (WebSockets sobre Postgres)
    Edge Functions No Sí (Deno runtime)
    Free tier DB 0.5 GB, 100 CU-h 500 MB, pausa tras 7 días idle
    Plan de pago Desde ~$19/mes (usage-based) $25/mes (Pro, todo incluido)
    ORM compatible Cualquiera (Drizzle, Prisma, pg) Cliente JS/TS propio + cualquier ORM
    Tipado auto-generado Via ORM Sí, con supabase gen types
    Adquirida por Databricks (2025, ~$1B) Independiente

    Arquitectura de Neon vs Supabase: la diferencia que más importa

    Neon separa compute y storage. Cuando no hay peticiones, el compute se apaga solo — y cuando llega la primera query, arranca en milisegundos. El storage usa copy-on-write, lo que hace que crear una rama de base de datos sea instantáneo y casi sin coste.

    Supabase no funciona así. Tu base de datos corre en una instancia dedicada. Si estás en el free tier, Supabase pausa el proyecto tras 7 días sin actividad. En Pro, la instancia corre siempre — pagas compute 24/7 aunque tu app esté durmiendo.

    Para proyectos en producción con tráfico real, esto no es necesariamente un problema. Para proyectos con muchos entornos (staging, feature branches, demos de clientes), la diferencia de coste es brutal.

    Branching: por qué Neon gana en CI/CD

    Esta es la feature que más me ha cambiado el flujo de trabajo.

    Con Neon puedes crear una rama de base de datos por PR. Misma estructura, mismos datos (o un subconjunto). La rama vive mientras dura el PR y desaparece al hacer merge. No hay que mantener un entorno de staging contaminado con datos de otras features. Si tienes un pipeline con code review automático antes del merge, tienes el flujo completo en el post sobre agentic code review con Claude Code.

    # Crear una rama de DB para una PR concreta
neon branches create --name feature/payment-refactor --parent main

    Supabase también tiene branching, pero funciona diferente: aprovisiona una base de datos nueva, ejecuta tus migraciones y carga el seed. Es más lento y consume más recursos. Para un equipo pequeño o un proyecto personal, puede ser suficiente. Para un pipeline de CI/CD que crea y destruye entornos constantemente, Neon gana por goleada.

    SDK y DX: dos filosofías distintas

    Supabase tiene un cliente JS/TS que abstrae casi todo. Queries, auth, storage, realtime — todo desde el mismo objeto.

    // Supabase: cliente unificado con tipado auto-generado
import { createClient } from '@supabase/supabase-js'
import type { Database } from './database.types' // generado con supabase gen types

const supabase = createClient<Database>(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_ANON_KEY!
)

const { data, error } = await supabase
  .from('products')
  .select('id, name, price')
  .eq('active', true)

    Neon apuesta por Postgres nativo. Usas tu ORM de siempre — Drizzle, Prisma, o pg directo — contra un connection string estándar. Sin abstracciones propias, sin vendor lock-in de cliente.

    // Neon: Drizzle sobre el driver serverless de Neon
import { neon } from '@neondatabase/serverless'
import { drizzle } from 'drizzle-orm/neon-http'
import { products } from './schema'
import { eq } from 'drizzle-orm'

const sql = neon(process.env.DATABASE_URL!)
const db = drizzle(sql)

const activeProducts = await db
  .select({ id: products.id, name: products.name, price: products.price })
  .from(products)
  .where(eq(products.active, true))

    Si ya tienes un ORM configurado en tu proyecto, migrar a Neon es cambiar el connection string. Con Supabase, el cliente propio es más cómodo para proyectos nuevos pero añade una dependencia específica a la plataforma.

    Precios Neon vs Supabase: cuándo cada modelo tiene sentido

    Neon (usage-based):

    • Free: $0 — 100 CU-horas, 0.5 GB storage
    • Launch: ~$19/mes — $0.106/CU-hora, $0.35/GB storage
    • Scale: desde ~$701/mes — con SLA e HIPAA incluidos

    Supabase (plataforma flat + overages):

    • Free: $0 — 500 MB DB, 50K MAU, 1 GB storage (pausa tras 7 días idle)
    • Pro: $25/mes — 8 GB DB, 100K MAU, Auth + Storage + Edge Functions incluidos
    • Team: $599/mes — SSO, SOC 2

    Para un proyecto con tráfico irregular o muchos entornos temporales, el modelo de Neon puede salir significativamente más barato. Para un SaaS en crecimiento que necesita Auth + Storage + DB y quiere una sola factura, el Pro de Supabase a $25 es imbatible en relación precio/funcionalidad.

    Precios verificados en junio 2026. Consulta las páginas oficiales de Neon y Supabase para tarifas actualizadas — los modelos usage-based cambian con frecuencia.

    Cuándo elegir Neon

    • Quieres Postgres puro sin opiniones sobre tu stack de auth o storage.
    • Tu pipeline de CI/CD se beneficia de tener una rama de DB por PR.
    • Tienes cargas de trabajo variables o intermitentes — el scale-to-zero te ahorra dinero real.
    • Ya tienes Drizzle o Prisma configurado y no quieres añadir un cliente propio.
    • Estás construyendo agentes de IA que necesitan provisionar bases de datos efímeras. La arquitectura serverless de Neon (y el respaldo de Databricks) la convierte en la opción natural para cargas de trabajo agénticas — incluidos los pipelines donde el agente lee un ticket, implementa y despliega de forma autónoma, como los que explico en el post sobre automatizar el proceso de desarrollo con IA.

    Cuándo elegir Supabase

    • Necesitas Auth desde el día uno — OAuth, magic link, JWT — sin montar Clerk ni Auth.js.
    • Tu proyecto necesita file storage y no quieres gestionar un bucket S3 por tu cuenta.
    • Quieres Realtime (subscripciones en tiempo real) sin añadir Redis ni WebSockets propios.
    • Valoras tener un solo proveedor para DB + Auth + Storage con una sola factura.
    • El free tier te basta para empezar y no te molesta que el proyecto se pause tras 7 días idle.

    Edge cases que nadie menciona

    Supabase no hace scale-to-zero en producción. Esto es intencionado — una instancia siempre activa garantiza latencia consistente. Pero si tienes 10 entornos de staging o un proyecto que duerme la mayor parte del tiempo, estás pagando compute en vacío.

    Neon no tiene Auth ni Storage nativos. Si los necesitas, tienes que añadirlos tú: Clerk, Better Auth, Auth.js para autenticación; Cloudflare R2, AWS S3 o Uploadthing para ficheros. No es un problema técnico, pero sí es trabajo de integración que con Supabase viene resuelto de fábrica.

    El branching de Supabase requiere CLI y configuración previa. No es tan plug-and-play como en Neon. Si quieres branching en Supabase, necesitas tener migraciones bien organizadas desde el principio.

    FAQ

    ¿Puedo usar Drizzle con Supabase?
    Sí. Supabase es Postgres estándar — puedes conectar cualquier ORM con el connection string del proyecto. El cliente propio de Supabase es opcional, no obligatorio.

    ¿Neon tiene Realtime o Auth?
    No de forma nativa. Puedes añadir LISTEN/NOTIFY de Postgres para eventos básicos, pero no hay un sistema de auth ni storage integrado. Para eso necesitas otra capa.

    ¿El scale-to-zero de Neon afecta a producción?
    Depende de tu configuración. El cold start de Neon suele estar por debajo de 500ms en condiciones normales. Para la mayoría de apps es aceptable. Si tienes requisitos de latencia muy estrictos, puedes configurar un mínimo de compute activo en el plan de pago.

    ¿Qué pasa con la adquisición de Neon por Databricks?
    Databricks compró Neon en 2025 por aproximadamente $1B. La apuesta es que los agentes de IA van a necesitar provisionar bases de datos efímeras a escala. Para el usuario, de momento se traduce en mejoras de precios — el storage bajó de $1.75 a $0.35/GB-mes. El roadmap a largo plazo aún está por verse.

    ¿Puedo migrar de Supabase a Neon (o al revés) más adelante?
    La base de datos en sí migra sin problema — es Postgres estándar en los dos casos. El trabajo real está en reemplazar el cliente de Supabase (auth, storage, realtime) si decides cambiar. Si usas Drizzle o Prisma desde el principio, cambiar el connection string es trivial.

    La decisión no es técnica en el fondo — es de qué quieres gestionar tú y qué quieres que gestione la plataforma. Si quieres Postgres puro con control total y branching en CI/CD, Neon. Si quieres un backend completo sin ensamblar piezas, Supabase.

    Ninguna de las dos es la respuesta correcta en abstracto. Ambas son la respuesta correcta para el problema adecuado.

    Si en tu proyecto estás usando IA para construir features o automatizar flujos, en el curso Construye con IA trabajamos exactamente con este tipo de decisiones de arquitectura — desde la elección de herramientas hasta el producto en producción.

    Si quieres profundizar en cómo tomar este tipo de decisiones de arquitectura en proyectos reales — con IA en el loop — en Dominicode Labs tenemos proyectos completos con el stack detallado y la justificación técnica detrás de cada decisión.

    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Implementación de @supabase/server para Edge Functions Seguras

    Implementación de @supabase/server para Edge Functions Seguras

    npm install @supabase/server@latest npx skills add supabase/server — Cambia cómo piensas la seguridad y la infraestructura de tus Edge Functions

    Tiempo estimado de lectura: 4 min

    • Reduce boilerplate: @supabase/server entrega SupabaseContext por petición y primitives para evitar repetir validación de JWT, clientes anon/admin y CORS.
    • Seguridad declarativa: auth modes visibles por ruta ({ auth: ‘user’ }, ‘secret’, ‘none’, etc.) que simplifican auditorías.
    • Automatización para equipos: npx skills add supabase/server añade conocimiento a agentes para migraciones y scaffolds fiables.

    Hoy no es sobre instalar una dependencia. Es sobre cambiar cómo piensas la seguridad y la infraestructura de tus Edge Functions. Si ejecutas npm install @supabase/server@latest y luego npx skills add supabase/server, obtienes dos cosas: una librería que elimina el boilerplate y una “skill” para agentes de código que conoce la API, los patrones y las rutas de migración. Esto no es marketing; es ingeniería que reduce errores y acelera migraciones.

    Resumen rápido (lectores con prisa)

    Qué es: Un paquete que entrega SupabaseContext preconfigurado por petición y una skill para agentes.

    Cuándo usarlo: Al migrar o crear Edge Functions que requieran autenticación, roles o admin operations.

    Por qué importa: Reduce código repetido y errores; hace la seguridad declarativa.

    Cómo funciona: Wrapper middleware (withSupabase) o primitivas (createSupabaseContext) que validan auth y exponen clientes y claims.

    Qué hace la instalación (breve)

    npm install @supabase/server@latest

    Instala el paquete que crea un SupabaseContext preconfigurado por petición.

    npx skills add supabase/server

    Entrega ese contexto a agentes como Claude Code o Codex, para que puedan generar migraciones y scaffolds fiables.

    Fuentes y documentación

    Qué obtienes realmente: contextos y patrones repetibles

    Instalar @supabase/server no es solo añadir un helper: introduces un patrón consistente. El núcleo es el SupabaseContext que te dan los wrappers como withSupabase:

    • ctx.supabase: cliente con scope de usuario (respeta RLS)
    • ctx.supabaseAdmin: cliente con service role (operaciones privilegiadas)
    • userClaims / jwtClaims: identidad verificada
    • authMode: cómo se autenticó la petición

    Ejemplo mínimo (edge handler compatible con cualquier runtime)

    import { withSupabase } from 'npm:@supabase/server'

export default {
  fetch: withSupabase({ auth: 'user' }, async (req, ctx) => {
    const { data } = await ctx.supabase.from('todos').select()
    return Response.json(data)
  }),
}

    Eso es todo. Declaras auth y recibes contexto. Si la petición no tiene token válido, el middleware corta la ejecución antes de tocar tu lógica.

    Modos de autenticación: explícitos y visibles

    La seguridad deja de ser código disperso y pasa a ser una declaración:

    • { auth: 'user' } — solo usuarios con JWT válido
    • { auth: 'none' } — webhooks y health checks
    • { auth: 'secret' } — server-to-server con clave secreta
    • { auth: 'publishable' } — publishable key
    • { auth: ['user', 'secret'] } — acepta JWT o secret key

    Ventaja práctica: el modelo de seguridad de una función es legible en una línea. Auditar políticas, cumplir requisitos de cumplimiento o revisar riesgo queda mucho más simple.

    Migrar a JWT asimétricos sin dolor

    Antes de @supabase/server, migrar a las nuevas claves asimétricas significaba instalar jose, montar JWKS, exponer nuevos secretos y actualizar función por función. Con este paquete la validación asimétrica y la resolución de JWKS se gestionan internamente. Resultado: menos oportunidades de equivocarte y menos código repetido.

    Cuando necesitas control fino: createSupabaseContext y las primitivas

    No todo el mundo usa el wrapper. Si necesitas flujo imperativo o respuestas personalizadas, existe createSupabaseContext:

    import { createSupabaseContext } from 'npm:@supabase/server'

export default {
  fetch: async (req) => {
    const { data: ctx, error } = await createSupabaseContext(req, { auth: 'user' })
    if (error) return Response.json({ error: error.message }, { status: error.status })

    const { data } = await ctx.supabase.from('todos').select()
    return Response.json(data)
  },
}

    Y si tu arquitectura es aún más compleja (MCP servers, adaptadores personalizados) las primitivas core están disponibles: createAdminClient, createContextClient, resolveEnv, verifyAuth — las mismas funciones que alimentan los adaptadores oficiales.

    Hono y adaptadores: patrón simple para frameworks

    Hono fue el primer adaptador oficial. Un ejemplo con Hono muestra lo limpio que queda:

    import { withSupabase } from '@supabase/server/adapters/hono'
import { Hono } from 'hono'

const app = new Hono()
app.get('/todos', withSupabase({ auth: 'user' }), async (c) => {
  const { supabase } = c.var.supabaseContext
  const { data } = await supabase.from('todos').select()
  return c.json(data)
})
export default { fetch: app.fetch }

    El adaptador inyecta supabaseContext en c.var y lista. Si necesitas otro framework, busca un adaptador o usa las primitivas core.

    Agentes y automatización: por qué añadir la “skill” es útil

    npx skills add supabase/server le da a un agente el conocimiento de la API y patterns. Eso permite prompts robustos:

    • “Analyze all Edge Functions and plan a migration to @supabase/server”
    • “Scaffold a Hono REST API with per-route auth for todos”
    • “Create an admin Edge Function that accepts user or secret auth and logs audits”

    Si tu equipo usa agentes para refactorizaciones o scaffolding, esta skill reduce la tasa de alucinaciones y acelera entregas.

    Criterio práctico para equipos técnicos

    • Empieza migrando endpoints críticos: aquellos con manipulación de roles o auditoría.
    • Sustituye shared utilities por withSupabase o createSupabaseContext: menos código repetido, menos errores.
    • Usa modes combinados (['user','secret']) para endpoints mixtos (frontend + cron jobs).
    • Revisa variables de entorno: SUPABASE_PUBLISHABLE_KEYS y SUPABASE_SECRET_KEYS en lugar de keys singulares.
    • Prueba con agentes para migraciones masivas, pero añade revisión humana.

    Conclusión

    npm install @supabase/server@latest y npx skills add supabase/server no son trucos de productividad; son una inversión en consistencia y seguridad. Si gestionas Edge Functions, adoptar este patrón reduce la superficie de error, acelera auditorías y libera tiempo para construir la lógica que realmente importa. Revisa la documentación en Documentación general y el repositorio en Repositorio Supabase para empezar.

    Dominicode Labs

    Para equipos que automatizan migraciones y workflows con agentes, una referencia práctica y recursos adicionales están disponibles en Dominicode Labs. Integrar estas prácticas con pipelines de automatización puede acelerar adopciones y reducir errores humanos.

    FAQ

    ¿Qué hace exactamente @supabase/server?

    Entrega un SupabaseContext preconfigurado por petición que incluye clientes (usuario y admin), claims y el modo de autenticación. También ofrece primitivas para escenarios imperativos o adaptadores de framework.

    ¿Necesito cambiar todas mis funciones para usarlo?

    No necesariamente. Puedes migrar endpoints críticos primero y sustituir utilidades compartidas por los wrappers o primitivias según prioridades del equipo.

    ¿Cómo maneja la validación de JWT asimétricos?

    La validación asimétrica y la resolución de JWKS se gestionan internamente por el paquete, evitando tener que instalar y montar jose y JWKS manualmente en cada función.

    ¿Qué diferencia hay entre withSupabase y createSupabaseContext?

    withSupabase es un wrapper middleware que inyecta contexto automáticamente y corta ejecución si la auth falla. createSupabaseContext es una primitiva imperativa útil cuando necesitas control fino sobre la respuesta o flujo.

    ¿La skill para agentes reemplaza la revisión humana?

    No. La skill reduce la tasa de alucinaciones y acelera la generación de migraciones y scaffolds, pero se recomienda revisión humana antes de despliegues críticos.

    ¿Dónde encuentro más documentación y ejemplos?

    Consulta la Documentación general y el Repositorio Supabase para ejemplos, adaptadores y guías de migración.

  • Guía para migrar funciones Edge y simplificar autenticación en Supabase

    Guía para migrar funciones Edge y simplificar autenticación en Supabase

    npm install @supabase/server@latest y npx skills add supabase/server: guía práctica para migrar Edge Functions, Hono y agentes IA

    Tiempo estimado de lectura: 4 min

    • Reduce boilerplate de autenticación gracias a un modelo declarativo y SupabaseContext por petición.
    • Automatiza migraciones con agentes usando npx skills add supabase/server para dar contexto y patrones a agentes de código.
    • Flujo incremental y seguro: withSupabase para la mayoría de endpoints; primitives o createSupabaseContext para casos complejos.
    • Soporta rotación de claves y despliegues controlados con variables plurales y canary deploys.

    Introducción

    npm install @supabase/server@latest y npx skills add supabase/server son las dos acciones que debes ejecutar si quieres adoptar el nuevo flujo de trabajo de Supabase: un paquete que elimina el boilerplate de autenticación y un “skill” que da contexto a agentes de código. En las primeras líneas: estos comandos son el punto de partida para migrar funciones Edge, automatizar refactors con agentes y levantar APIs Hono seguras en minutos.

    Resumen rápido (lectores con prisa)

    Instala @supabase/server para obtener contexto de autenticación y clientes por petición. Añade el skill supabase/server para que agentes de código puedan identificar y actualizar inicializaciones antiguas. Usa withSupabase para la mayoría de endpoints; recurre a primitives o createSupabaseContext para casos compuestos.

    npm install @supabase/server@latest — qué instala y qué te da

    Instalar @supabase/server provoca algo más que añadir una dependencia: introduce un modelo declarativo para control de acceso y un SupabaseContext listo para usar. Tras la instalación obtienes primitives y wrappers que:

    • Verifican JWT asimétricos sin jose/JWKS manual.
    • Inicializan dos clientes por petición: ctx.supabase (usuario, respeta RLS) y ctx.supabaseAdmin (service role).
    • Inyectan userClaims, jwtClaims y authMode en el contexto.
    • Ofrecen withSupabase (wrapper), createSupabaseContext (imperativo) y primitives en @supabase/server/core.

    Documentación oficial: Documentación oficial y repo: Repositorio en GitHub

    npx skills add supabase/server — por qué lo necesitas si usas agentes

    npx skills add supabase/server alimenta a herramientas como Claude Code, Codex o Cursor con la superficie de la API, patrones de adaptadores y rutas de migración. Resultado práctico: un agente puede escanear tu repo, identificar inicializaciones antiguas, reemplazarlas por withSupabase y migrar claves a las nuevas variables sin equivocarse.

    Prompts útiles (ejemplos que puedes dar al agente):

    • “Analyze all Edge Functions and plan a full migration to use the new API keys with @supabase/server”
    • “Scaffold a Hono REST API with CRUD for todos using per-route auth”
    • “Create an Edge Function that accepts user or secret auth, reads profile with RLS and writes audit logs with admin client”

    Plan de migración: pasos prácticos y ordenados

    1. Auditoría rápida

    Busca patrones repetidos (creación de clientes, verificación JWT, _shared/*.ts).

    2. Añade la dependencia e instala el skill

    Ejecuta los comandos:

    npm install @supabase/server@latest
npx skills add supabase/server

    3. Sustitución incremental

    • Reemplaza inicializaciones manuales por withSupabase({ auth }) en funciones individuales.
    • Para funciones multifunción, usa createSupabaseContext o primitives (verifyAuth, createContextClient).

    4. Variables de entorno

    Cambia a formas plurales si es necesario: SUPABASE_PUBLISHABLE_KEYS y SUPABASE_SECRET_KEYS (soporta rotación). Valida inyección en plataformas (Supabase CLI, Vercel, Cloudflare).

    5. Test y rollout

    • Tests unitarios sobre handlers con contexto mockeado.
    • Canary deploy para funciones críticas.

    6. Limpieza

    • Elimina utilidades compartidas de verificación JWT (ya no necesarias).
    • Actualiza docs internas y runbooks.

    Ejemplo rápido: Hono + withSupabase (CRUD /todos)

    El adaptador Hono inyecta el contexto en c.var.supabaseContext:

    import { withSupabase } from '@supabase/server/adapters/hono'
import { Hono } from 'hono'

const app = new Hono()

app.get('/todos', withSupabase({ auth: 'user' }), async (c) => {
  const { supabase } = c.var.supabaseContext
  const { data } = await supabase.from('todos').select()
  return c.json(data)
})

export default { fetch: app.fetch }

    Per-route auth es explícito y visible en la firma: mantenimiento y auditoría mucho más sencillos.

    Edge Function protegida con operaciones admin (patrón recomendado)

    Cuando necesitas dual-mode auth (usuario o secret) y escribir logs de auditoría:

    • Declara auth: ['user','secret'].
    • Usa ctx.supabase para lecturas que respetan RLS.
    • Usa ctx.supabaseAdmin para escribir auditoría o tareas privilegiadas.

    Si necesitas control imperativo sobre errores, usa createSupabaseContext:

    import { createSupabaseContext } from 'npm:@supabase/server'

const { data: ctx, error } = await createSupabaseContext(req, { auth: ['user','secret'] })
if (error) return Response.json({ error: error.message }, { status: error.status })

    Recomendaciones prácticas y criterios técnicos

    • Prioriza withSupabase para la mayoría de endpoints: claridad y seguridad por defecto.
    • Usa primitives solo cuando debas combinar múltiples auth en una función o manipular headers de forma estricta.
    • Aprovecha npx skills para automatizar auditoría y migración; reduce errores humanos en refactors masivos.
    • Mantén tests que mockeen SupabaseContext para evitar dependencia de la red en unit tests.
    • Revisa el repo y docs oficiales para edge-cases y actualizaciones: Repositorio en GitHub y Documentación oficial

    Conclusión

    Instalar @supabase/server y añadir el skill cambia la ergonomía del backend: elimina la repetición, reduce superficie de ataque y hace tus funciones Edge predecibles para humanos y agentes por igual. Empieza migrando funciones críticas con canary deploys, automatiza el resto con el skill y conserva primitives para los casos realmente especiales. El resultado: menos fontanería, más foco en la lógica que aporta valor.

    Mención: Dominicode Labs

    Si estás planificando automatizaciones o migraciones con agentes, puede resultar útil ver recursos y experimentos aplicados a workflows y agentes. Más información y proyectos relacionados en Dominicode Labs.

    FAQ

    Respuesta: Instalar @supabase/server introduce un modelo declarativo de control de acceso y un SupabaseContext por petición, con clientes ctx.supabase y ctx.supabaseAdmin, verificación de JWT asimétrica y utilidades como withSupabase y createSupabaseContext.

    Respuesta: npx skills add supabase/server aporta la superficie de la API y patrones a agentes de código, permitiendo que escaneen repos, identifiquen inicializaciones antiguas y automaticen refactors de forma segura.

    Respuesta: Cambia a variables plurales como SUPABASE_PUBLISHABLE_KEYS y SUPABASE_SECRET_KEYS para soportar rotación. Valida la inyección en plataformas como Supabase CLI, Vercel o Cloudflare antes del despliegue.

    Respuesta: Usa withSupabase por defecto para claridad y seguridad. Emplea createSupabaseContext o primitives cuando necesites combinar múltiples modos de auth en una sola función o manipular headers de forma estricta.

    Respuesta: Escribe tests unitarios que mockeen el SupabaseContext para evitar llamadas de red. Realiza canary deploys para funciones críticas antes del rollout completo.

    Respuesta: Sí: una vez migradas las funciones a @supabase/server, las utilidades compartidas de verificación JWT que replican lógica ya gestionada por el paquete dejan de ser necesarias y pueden eliminarse tras validar el comportamiento.

  • Supabase vs Firebase: Eligiendo el BaaS adecuado para tu proyecto

    Supabase vs Firebase: Eligiendo el BaaS adecuado para tu proyecto

    Supabase vs. Firebase: ¿Cuál elegir para tu backend as a service?

    Tiempo estimado de lectura: 3 min

    • Idea clave: Elige según el modelo de datos: SQL (Supabase) para relaciones y garantías; NoSQL (Firestore) para prototipado móvil rápido.
    • Idea clave: Seguridad y control de acceso difieren: RLS en la base de datos (Supabase) vs Security Rules (Firebase).
    • Idea clave: Costes y facturación: Firebase cobra por operación; Supabase por recursos.
    • Idea clave: Integración con IA y automatizaciones favorece a Supabase (pgvector, n8n).

    Tabla de contenidos

    Resumen rápido (lectores con prisa)

    Supabase es una capa sobre PostgreSQL: relaciones nativas, transacciones ACID y RLS, ideal para SaaS y pipelines de IA. Firebase (Firestore) es NoSQL documental: esquema flexible, sync offline y prototipado móvil rápido. Elige por modelo de datos, seguridad y previsibilidad de costes.

    Supabase vs. Firebase: núcleo técnico (aplica esto primero)

    La decisión parte del tipo de datos y consultas que necesitas.

    PostgreSQL (Supabase): relaciones y garantías

    Supabase es una capa sobre PostgreSQL. Eso significa:

    • Relaciones nativas, transacciones ACID y JOINs eficientes.
    • Extensiones útiles: pgvector para embeddings, PostGIS para geo.
    • Seguridad posible a nivel de fila (RLS).

    Ejemplo real:

    SELECT o.id, p.name
FROM orders o
JOIN products p ON o.product_id = p.id
WHERE o.user_id = auth.uid();

    Docs: Docs

    Ventaja práctica: modelas un SaaS con integridad (facturas, permisos, inventario) sin duplicar datos.

    Firestore (Firebase): documentos y prototipado rápido

    Firestore es NoSQL documental:

    • Esquema flexible, sincronización realtime y offline excelente para móviles.
    • Consultas simples y rápidas sobre documentos planos.
    • Para relaciones complejas, debes desnormalizar (duplicar), lo que complica actualizaciones.

    Docs: Docs

    Ventaja práctica: lanzar un MVP móvil con colaboración offline y sync en minutos.

    Seguridad y control de acceso: RLS vs Security Rules

    La seguridad no es “activar un switch”; es dónde y cómo se evalúa.

    Supabase: Row Level Security (RLS)

    Supabase: Row Level Security (RLS) en la base de datos. Políticas SQL que se ejecutan en la DB, auditable y portable.

    Ejemplo:

    CREATE POLICY "users_can_view_their_rows"
  ON profiles
  FOR SELECT
  USING (auth.uid()::uuid = user_id);

    Docs: Docs

    Conclusión: RLS es más robusto y seguro en aplicaciones con requisitos estrictos de control de acceso.

    Firebase: Security Rules

    Firebase: Security Rules, DSL propietario que controla acceso desde Firestore. Funciona, pero es menos estándar y puede volverse difícil de testear en reglas complejas.

    Docs: Docs

    Costes y riesgo de facturas inesperadas

    Modelo de facturación es crítico para startups.

    Firebase (Firestore)

    Cobro por operación (lecturas/escrituras/eliminaciones). El free tier es generoso, pero una consulta ineficiente puede disparar costes.

    Pricing: Pricing

    Supabase

    Modelo por recursos (CPU/RAM/storage). Más predecible; puedes poner límites de gasto y escalar infra.

    Pricing: Pricing

    Regla práctica: si esperas picos de lectura o patrones impredecibles, Supabase suele ser más manejable económicamente; Firebase favorece cargas constantes y apps móviles con lecturas optimizadas.

    Integraciones con automatización e IA (importante para Dominicode)

    Supabase

    Se integra directamente con herramientas como n8n (nodo Postgres) y soporta pgvector para almacenar embeddings y hacer búsquedas vectoriales. Ideal para pipelines de IA y agentes que necesitan acceso rápido a vectores.

    Firebase

    Requiere usar SDK/Admin o REST; funciona, pero añade capa extra en automatizaciones low-code.

    Si vas a construir agentes que consulten memoria vectorial o pipelines de automatización, Supabase acelera la implementación.

    Experiencia de desarrollo y time-to-market

    Firebase: SDKs maduros para iOS/Android/Web, documentación amplia y ejemplos para prototipado rápido.

    Supabase: dashboard claro, APIs auto-generadas y funciones edge (Deno). Mejor para equipos que prefieren SQL y TypeScript.

    Ambos son productivos; la diferencia es la calidad de la arquitectura que quieres conservar cuando el proyecto crezca.

    Decisión práctica: checklist para elegir

    Elige Supabase si

    • Tu dominio tiene relaciones complejas y necesitas integridad de datos.
    • Quieres evitar vendor lock-in y mantener portabilidad.
    • Planeas integrar IA (embeddings) o automatizaciones con n8n.
    • Necesitas costes predecibles al escalar.

    Elige Firebase si

    • Vas a lanzar un MVP móvil con sincronización offline/realtime.
    • Necesitas iterar esquema sin migraciones durante fases tempranas.
    • Prioriza velocidad de prototipo sobre la portabilidad a largo plazo.

    Conclusión

    No hay “mejor” universal: hay mejor para tu dominio. Si tu app es un SaaS, panel administrativo o parte de un stack de automatización/IA, empieza por Supabase. Si necesitas lanzar rápido una app móvil con syncing offline y no te preocupa el vendor lock-in, Firebase acelera el camino.

    Ambas plataformas son sólidas; decide por el modelo de datos y la previsibilidad de costes, no por la moda.

    Para proyectos que combinan automatización, agentes y pipelines de IA, considera herramientas y recursos adicionales en Dominicode Labs como continuación lógica de la integración entre infraestructuras y workflows.

    FAQ

    ¿Por qué elegir Supabase si necesito integridad de datos?

    Porque Supabase se basa en PostgreSQL, que ofrece relaciones nativas, transacciones ACID y JOINs eficientes, lo que facilita modelar dominios con integridad (facturas, permisos, inventario) sin duplicar datos.

    ¿Cuándo es mejor Firebase para un MVP móvil?

    Cuando necesitas sincronización offline/realtime y velocidad de prototipo: Firestore proporciona SDKs maduros y sync offline que permiten lanzar rápidamente con colaboración en tiempo real.

    ¿Cómo afectan los modelos de facturación a startups?

    Firebase cobra por operaciones (lecturas/escrituras/eliminaciones), lo que puede generar facturas inesperadas con consultas ineficientes. Supabase factura por recursos (CPU/RAM/storage), ofreciendo previsibilidad y control de costes al escalar.

    ¿Puedo usar embeddings con Supabase?

    Sí. Supabase soporta extensiones como pgvector para almacenar embeddings y realizar búsquedas vectoriales, lo que facilita pipelines de IA y agentes que requieren memoria vectorial.

    ¿Es RLS realmente más seguro que Security Rules?

    RLS se ejecuta en la base de datos, es auditable y portable, lo que lo hace más robusto para requisitos estrictos de control de acceso en comparación con Security Rules, que es un DSL propietario aplicado en Firestore.

    ¿Cómo afecta la desnormalización en Firestore al mantenimiento?

    La desnormalización requiere duplicar datos para modelar relaciones complejas, lo que complica actualizaciones y mantenimiento a medida que la aplicación crece.