Supabase para empresas en Chile: la nueva base para apps modernas

Hace cinco años, arrancar un proyecto de software empresarial significaba dos semanas armando infraestructura antes de escribir una sola línea de lógica de negocio. Provisionar una base de datos, configurar autenticación, montar un servicio de archivos, abrir puertos, definir roles, escribir middleware de permisos. Solo después de todo eso uno podía empezar a construir lo que el cliente realmente pidió.

Ese mundo cambió. Hoy las PyMEs y startups chilenas que están construyendo apps internas, MVPs SaaS o portales para clientes están eligiendo masivamente Supabase como la base de su stack. En este artículo explicamos qué es exactamente, qué problemas resuelve, cuándo conviene (y cuándo no), y cómo lo usamos típicamente en sintesia.cl para entregar software en días en vez de meses.

¿Qué es Supabase exactamente?

TL;DR: Supabase es una plataforma open-source que te entrega PostgreSQL gestionado + autenticación + storage + realtime + edge functions, todo conectado y listo para usar desde una sola consola.

La forma más fácil de entenderlo es: "Firebase, pero con una base de datos relacional de verdad y sin vendor lock-in". La promesa es que pasas de "necesito configurar el backend" a "ya tengo backend, ahora voy a construir features" en menos de una hora.

Bajo el capó es PostgreSQL real, con múltiples extensiones útiles disponibles (Supabase Postgres Extensions, consultado 26 may 2026): pgvector para IA, PostGIS para geolocalización, pg_cron para tareas programadas (este último disponible en plan Pro o superior). Encima Supabase agrega una capa de servicios gestionados que cubren los dolores que toda app empresarial moderna tiene.

Las 5 cosas que te da gratis cuando arrancas

El valor de Supabase no es uno solo, es la suma. Veamos cada pieza.

1. PostgreSQL real (no NoSQL)

A diferencia de Firebase (que usa Firestore, una base NoSQL documental), Supabase te entrega Postgres puro. Eso significa joins reales, transacciones ACID, vistas materializadas, triggers, funciones almacenadas, constraints, y todo el SQL que tu equipo ya conoce. Para apps empresariales con relaciones complejas (un cliente tiene muchas órdenes, una orden tiene muchos ítems, cada ítem un proveedor, etc.) esto no es un detalle: es la diferencia entre una arquitectura sostenible y una que se rompe a los seis meses.

2. Autenticación (email, OAuth, magic links)

Supabase Auth maneja registro/login con email + password, OAuth con Google, Microsoft, Apple, GitHub, LinkedIn y otros, magic links sin contraseña, y MFA por TOTP. Verificación de email, recuperación de contraseña, JWT firmados, refresh tokens, todo incluido. Reemplaza una capa de auth custom que normalmente implicaría varias semanas de desarrollo.

3. Storage de archivos

Sube archivos (PDFs, imágenes, videos, lo que sea) con un solo cliente SDK. Supabase Storage incluye URLs firmadas con expiración, transformación de imágenes on-the-fly (resize, formato, calidad), y políticas de acceso por bucket. Sirve los archivos vía CDN global. Para una app de gestión documental, fichas técnicas, comprobantes, contratos, esto reemplaza un proyecto S3 + Cloudfront completo.

4. Realtime (subscripciones a cambios)

Cualquier cambio en una tabla puede emitir eventos en tiempo real a los clientes conectados. Esto te permite hacer dashboards que se actualizan solos, sistemas de chat, notificaciones in-app, presencia ("Juan está viendo este ticket"), todo sin montar un broker WebSocket aparte. Es la diferencia entre una app "estática" y una experiencia que se siente moderna.

5. Row-Level Security (permisos a nivel de fila desde Postgres)

Esta es la pieza más subestimada. RLS te permite escribir políticas en SQL que dicen "un usuario solo puede ver sus propias órdenes" o "un admin de la empresa X solo ve clientes de la empresa X", y Postgres las aplica automáticamente en cada consulta, vengan de donde vengan. Eso elimina toda una capa de middleware de permisos y, más importante, blinda la seguridad: aunque el frontend tenga un bug, la base de datos no entrega datos que no debe.

Supabase vs Firebase: comparativa honesta

Ambas son plataformas BaaS (Backend-as-a-Service), pero la decisión depende de varios factores. Esta tabla resume las diferencias que realmente importan al elegir.

Criterio	Supabase	Firebase
Modelo de datos	Relacional (PostgreSQL)	Documental (Firestore NoSQL)
Querying	SQL completo, joins, agregaciones	Limitado, sin joins reales
Vendor lock-in	Bajo: open-source, autohospedable	Alto: APIs propietarias de Google
Costos a escala	Predecible (basado en cómputo/storage)	Por lecturas/escrituras (puede dispararse)
Deploy regional	South America (São Paulo) disponible	South America (São Paulo) disponible
Realtime	Cambios en tablas vía Postgres logical replication	Listeners de documentos
Auth	JWT estándar, integrable con tu stack	JWT propietario de Google
Stack frontend	Cualquiera (Next.js, React, Vue, Svelte, móvil nativo)	Idem, pero pensado para móvil primero

La regla práctica: si tu app tiene datos con relaciones (CRM, ERP, marketplace, gestión documental) Supabase casi siempre gana. Si es una app puramente móvil con datos planos (un chat simple, una app de notas) Firebase sigue siendo válido.

Casos típicos en empresas chilenas

En sintesia.cl usamos Supabase en cuatro escenarios principales:

• Portales internos: intranets de RR.HH., portales de proveedores, sistemas de tickets internos. Usuarios manejables (10–500), datos sensibles, RLS es crítico.
• MVPs SaaS: startups chilenas que validan una idea B2B. Necesitan multi-tenancy (cada cliente ve solo sus datos), auth con OAuth, y costos bajos hasta encontrar tracción.
• Dashboards operativos: reportes en tiempo real conectados al ERP o al organismo tributario. Realtime + Postgres + edge functions cubre el caso completo.
• Apps móviles para fuerza de venta: apps usadas por vendedores en terreno que sincronizan datos cuando hay conexión, con storage de fotos de productos o firmas de cliente.

Modelo de costos: cuánto te aguanta cada plan

Uno de los puntos fuertes de Supabase frente a competidores es la previsibilidad de costos. Tres planes principales relevantes para PyMEs:

Plan	Costo USD/mes	Aguanta hasta
Free	$0	50K MAU, 500 MB DB, 1 GB storage, 5 GB egress mensual. Proyectos pausan tras 7 días de inactividad; ideal para prototipos y MVPs en validación.
Pro	$25 + uso	100K MAU, 8 GB DB, 100 GB storage, backups diarios, $10 de compute credits incluidos. La mayoría de portales internos viven aquí.
Team	$599 + uso	SSO con SAML, soporte priorizado, SOC2 e ISO 27001, retención de backups por 14 días. Para empresas medianas con compliance.

Precios y límites verificados con el pricing oficial de Supabase al 26 de mayo de 2026. Los planes Pro y superiores facturan uso adicional (egress, MAU, compute) sobre los cupos incluidos.

Comparado con armar la misma stack en AWS (RDS + Cognito + S3 + API Gateway + Lambdas), Supabase concentra todos esos servicios en un único plan, lo que reduce la complejidad operativa y el tiempo de DevOps necesario para mantenerla. La comparación de costos depende del tráfico, región y configuración, por lo que conviene modelarla caso a caso.

Cuándo NO conviene Supabase (sé honesto)

No es la respuesta para todos los proyectos. Hay tres escenarios donde recomendamos otra cosa:

• Cargas masivas con tuneo Postgres muy fino. Si manejas decenas de millones de transacciones diarias y necesitas particionamiento custom, replicación específica o índices exóticos, vas a chocar con los límites del plan gestionado. En ese punto autohospedar Postgres en AWS RDS o Aurora te da más control.
• Regulación que exige datos en servidores chilenos. Supabase sirve desde São Paulo, no desde Chile. Si tu rubro (salud, banca, ciertos sectores públicos) exige residencia local de datos, hay que ir con un proveedor con presencia en Chile o autohospedar Supabase en una nube local. Vale la pena revisarlo en el contexto de la Ley 21.719 sobre protección de datos.
• Apps offline-first muy complejas. Si tu app necesita sincronización bidireccional avanzada con resolución de conflictos (estilo Linear o Figma), Supabase no te da eso out-of-the-box. Hay que sumar PowerSync o un layer de sync custom.

Cómo migrar a Supabase si ya tienes algo

Las tres rutas de migración más comunes que vemos en clientes chilenos:

• Desde Firebase: exportar Firestore a JSON, mapear documentos a tablas relacionales y migrar auth con un script que mantiene los UIDs. La duración varía mucho según volumen y complejidad del modelo de datos.
• Desde Heroku: si ya estás en Postgres, es prácticamente un pg_dump a pg_restore. La parte más larga es portar la lógica de auth.
• Desde servidor propio (VPS con PHP/MySQL): es la migración más profunda porque típicamente implica también reescribir el frontend. Recomendamos hacerla por módulos, no de un solo golpe.

Snippet: así se ve usar Supabase desde TypeScript

Para que quede claro lo simple que es trabajar con Supabase desde una app Next.js, este es un ejemplo de login con email y luego una consulta con permisos automáticos vía RLS:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
 process.env.NEXT_PUBLIC_SUPABASE_URL!,
 process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
)

// 1. Login con email + password
const { data: auth, error: authError } = await supabase.auth.signInWithPassword({
 email: '[email protected]',
 password: 'secret123'
})

if (authError) throw authError

// 2. Consulta de cotizaciones del usuario (RLS filtra automáticamente)
const { data: cotizaciones, error } = await supabase
 .from('cotizaciones')
 .select('id, cliente, monto_neto, estado, created_at')
 .eq('estado', 'pendiente')
 .order('created_at', { ascending: false })
 .limit(20)

// Maria solo ve sus propias cotizaciones, sin escribir un solo WHERE de seguridad.
// La política RLS en Postgres hace el filtro: auth.uid() = user_id

Eso es todo. Sin escribir endpoints REST, sin armar un servidor Express, sin middleware de auth. La política RLS en Postgres se ve así:

create policy "Usuarios ven sus propias cotizaciones"
 on cotizaciones for select
 using (auth.uid() = user_id);

Lo que sintesia.cl construye típicamente con Supabase

Cuando un cliente nos pide un portal interno, un CRM a medida o un dashboard operativo, Supabase es casi siempre la primera opción que evaluamos para el backend. Lo combinamos con Next.js + TypeScript en el frontend, Vercel para el deploy y, cuando hace falta IA en el flujo, agentes con Claude. Esta combinación es la que describimos con más detalle en nuestro post sobre Claude Code para empresas.

Un ejemplo es el portal interno con Supabase como backend completo, donde la mayor parte del esfuerzo se concentra en diseñar la lógica de negocio y las pantallas, en vez de resolver problemas de infraestructura.

Conclusión: Supabase es la nueva línea base

Hace cinco años un MVP empresarial empezaba con dos semanas de plumbing. Hoy esa decisión es difícil de justificar: hay una plataforma open-source, con costos predecibles, Postgres real, seguridad robusta y deploys en minutos. Para una buena parte de los proyectos B2B que vemos en Chile (CRMs, portales, dashboards, MVPs SaaS), Supabase es la respuesta correcta.

El resto sigue necesitando arquitecturas custom, pero ese es un caso a evaluar con cuidado, no la regla.

Fuentes y referencias

• Supabase — Pricing oficial (consultado 26 may 2026)
• Supabase — Documentation
• Supabase — Postgres Extensions Overview (pgvector, pg_cron, PostGIS y más de 50 extensiones)
• Supabase — Available Regions (incluye sa-east-1 São Paulo)
• Supabase — Auth (email, OAuth, magic links, MFA)
• Supabase — Storage (CDN, URLs firmadas, transformación de imágenes)
• PostgreSQL — Row Security Policies (RLS)
• Supabase — JavaScript/TypeScript SDK reference

Nota: precios, límites y features de proveedores cloud cambian con frecuencia. Información verificada al 26 de mayo de 2026 — recomendamos validar contra la documentación oficial al implementar.