Postgres local sin Docker con Tinbase

En pocas palabras: Tinbase permite correr Postgres 17 real sin Docker mediante un binario de ~58 MB: según dev.to (28/09/2026), en una MacBook Air M1 de 8 GB baja el consumo de RAM de ~1,6 GB (stack Docker de Supabase) a ~100 MB, y el arranque en frío pasa de 45 a 2,5 segundos.

Tinbase es un binario de unos 58 MB que corre Postgres 17 real sin Docker: según el review publicado en dev.to el 28 de septiembre de 2026, en una MacBook Air M1 de 8 GB baja el consumo de RAM del stack Docker de Supabase (~1,6 GB) a ~100 MB, y el arranque en frío pasa de 45 segundos a 2,5 segundos.

Tinbase es un backend open source bajo licencia MIT que implementa el mismo contrato que supabase-js (REST, Auth, Realtime y Storage) sobre una base de datos Postgres real, con tres motores posibles: nativo, PGlite (Postgres compilado a WASM) o pg-mem en JavaScript puro. No es un producto de Supabase ni un reemplazo oficial: lo mantiene un equipo independiente y hoy está en fase alpha, pensado para desarrollo local, no para producción.

¿Qué problema resuelve correr Postgres local sin Docker?

El problema es el consumo de recursos del stack Docker de Supabase en máquinas con RAM limitada. El review en dev.to midió que en una MacBook Air M1 de 8 GB los 12 contenedores de supabase start ocupan cerca de 1,6 GB de RAM en reposo y tardan 45 segundos en levantar desde cero. Para un workshop, una laptop compartida o un pipeline de CI que crea y destruye entornos todo el tiempo, ese costo se siente rápido.

“Trabajo en Tinbase. Es MIT y no está afiliado a Supabase”, aclaró la propia autora en el posteo, dejando el disclosure por escrito antes de mostrar un solo comando.

Tinbase no toca la arquitectura de Supabase: reimplementa el contrato de sus APIs sobre un solo proceso. El resultado, según la misma fuente, es un binario que arranca en ~2,5 segundos en frío y ~800 ms en caliente, con ~100 MB de RAM en reposo. El proyecto replica el contrato de supabase-js sin ser un reemplazo oficial del producto de Supabase.

¿Cómo instalar y arrancar Postgres local sin Docker con Tinbase?

Instalar Tinbase es un solo comando: en macOS y Linux, curl -fsSL https://tinbase.dev/install.sh | sh descarga el binario; en Windows se baja el .exe desde la página de releases del repositorio en GitHub. No hay que instalar Node, npm ni Docker en la máquina destino.

• Instalación: corré el script (o el .exe en Windows) y confirmá la versión con tinbase --version; el review de dev.to registra la 0.9.4.
• Arranque: tinbase start --data-dir ~/tinbase-data levanta el servidor en http://localhost:8080 y expone Postgres en postgresql://postgres@localhost:5432/postgres.
• Verificación: corré psql postgresql://postgres@localhost:5432/postgres -c 'select version();'. Tiene que devolver PostgreSQL 17.1, no PGlite ni SQLite con un adaptador de protocolo Postgres encima.

¿Y si no querés instalar nada en el sistema? El sitio oficial también ofrece npx tinbase start, que baja el paquete de npm y lo corre al vuelo sin instalación previa.

¿Tinbase funciona con supabase-js sin cambiar código?

Sí: alcanza con cambiar dos variables de entorno, SUPABASE_URL y SUPABASE_ANON_KEY, para que un proyecto con supabase-js apunte a Tinbase en vez de al Supabase hosteado. El código de la app queda intacto.

Ponele que tu app ya usa supabase.auth.signInWithPassword() y una policy RLS como projects_tenant_scope que filtra proyectos por tenant_id. Contra Tinbase, auth.uid() resuelve igual que en el Supabase hosteado: si la policy pasa en local, pasa en producción, según la fuente. Lo mismo aplica a las suscripciones realtime con channel().on('postgres_changes', ...), que corren sobre una implementación en Go del protocolo de Supabase Realtime, y a las edge functions, que Tinbase ejecuta en un V8 embebido (no un subproceso de Deno) con un cold start de ~15 ms.

Por default vienen habilitadas seis extensiones de Postgres: pgvector (embeddings), pg_trgm (búsqueda difusa), pg_stat_statements (profiling de queries), unaccent, pgcrypto y uuid-ossp. Cualquier otra se instala como en cualquier Postgres, con create extension.

¿Cómo migrar un proyecto Supabase existente a Tinbase?

La migración son tres comandos: exportar el dump con la CLI de Supabase, importarlo en Tinbase y verificar las tablas con psql. No hay reescritura de esquema.

• Dump: supabase db dump --file dump.sql --data-only=false exporta esquema y datos del proyecto Docker existente.
• Import: tinbase import --file dump.sql carga ese dump en la instancia local.
• Chequeo: psql ... -c '\dt' confirma que las tablas llegaron.

El detalle que conviene mirar antes de comprometer tiempo a esto es que tinbase import no falla en silencio: si el dump usa extensiones o hooks que Tinbase todavía no soporta, imprime un warning por cada uno. Eso convierte la migración en un proceso de dos pasos reales: primero correr el import y leer la lista de warnings, después decidir si esas piezas faltantes son bloqueantes para tu proyecto o si podés vivir sin ellas en el entorno local. Antes de migrar algo que importe, la matriz de compatibilidad de la documentación oficial es la referencia para chequear ese punto sin sorpresas.

¿Cuándo conviene migrar y cuándo no? Criterios de decisión

Cruzando lo que reporta el review con lo que documentan el sitio oficial y el repositorio, hay cuatro preguntas que ordenan la decisión antes de tocar nada:

• ¿Cuánta RAM tiene la máquina donde se desarrolla? En equipos de 16 GB o más, la diferencia entre 1,6 GB y 100 MB de RAM en reposo probablemente no se sienta en el día a día. En laptops de 8 GB compartidas (workshops, bootcamps, máquinas viejas del equipo), esos ~1,5 GB extra sí compiten con el editor, el navegador y el resto de las herramientas abiertas.
• ¿Con qué frecuencia se crean y destruyen entornos? Un desarrollador que levanta el stack una vez a la mañana y lo deja corriendo todo el día no gana mucho con un boot de 2,5 s contra uno de 45 s. Un pipeline de CI que arranca y tira la base en cada job, sí: ahí los 42 segundos de diferencia se multiplican por la cantidad de corridas diarias.
• ¿El equipo usa el dashboard de Supabase Studio como herramienta de trabajo diaria? Si alguien del equipo edita datos, revisa policies RLS o corre SQL a mano desde la interfaz visual todos los días, ese hábito de trabajo pesa más que el ahorro de RAM. Las fuentes se contradicen sobre en qué versión exacta llegó el Studio de Tinbase, así que conviene probarlo antes de dar por sentado que ya cubre ese flujo.
• ¿El proyecto depende de Storage con transformación de imágenes al vuelo? Si el resize o crop en el servidor es parte del producto, Tinbase no lo tiene: es I/O de archivos plano. Ese punto no es negociable hoy.

Ejemplo hipotético (a modo de ilustración, no un caso real reportado en las fuentes): un equipo que dicta un workshop de fin de semana con diez laptops de 8 GB prestadas, donde cada alumno tiene que levantar el backend de cero varias veces durante la jornada. Ahí los cuatro criterios apuntan en la misma dirección: RAM limitada, entornos que se recrean todo el tiempo, nadie va a tocar el dashboard porque el foco es el código de la app, y no hay transformación de imágenes en el ejercicio. Ese perfil de uso es, según los propios números de las fuentes, el que más se beneficia del cambio. El mismo razonamiento, aplicado a un equipo que ya tiene su Docker Supabase corriendo hace meses sin quejas de RAM y que usa el Studio a diario, da la conclusión contraria: no hay urgencia por migrar.

¿Cuáles son los límites de Tinbase frente a Docker Supabase?

El límite más citado es el dashboard. Según el review de dev.to, al momento de la prueba Tinbase todavía no tenía un equivalente al Supabase Studio local (aunque el sitio oficial y el repo de GitHub sí anuncian un Studio embebido en la ruta /_/, así que conviene chequear en qué versión quedó disponible antes de descartar la opción por este motivo).

Storage tampoco hace transformaciones de imagen al vuelo: es I/O de archivos plano, sin el pipeline de resize o crop que tiene el Storage hosteado de Supabase.

Si tu equipo ya está cómodo con el setup de Docker y la RAM no es un problema, no hay nada urgente para arreglar. Tinbase gana en laptops con 8 GB, workshops, entornos de demo y pipelines de CI que levantan y bajan bases todo el día.

Docker Supabase vs. Tinbase: comparación de recursos

Opción	Instalación	Memoria bajo carga	Arranque en frío	Motor
Supabase local (Docker)	2.291 MB	1.626 MB	~45 s	Postgres real, 12 contenedores
Tinbase (nativo)	36 MB	100 MB	–	Postgres 17 real embebido
Tinbase (binario único)	92 MB	66 MB	–	Postgres 17 real
PocketBase (referencia)	30 MB	24 MB	–	SQLite, API distinta a supabase-js

Los números de instalación y memoria bajo carga son del benchmark publicado en tinbase.dev, medido en Apple Silicon con macOS 15; ese benchmark no desglosa el arranque en frío por motor. El dato de ~100 MB de RAM en reposo que reporta dev.to viene de una prueba distinta, en una M1 Air de 8 GB con carga real de trabajo, así que las cifras no son directamente comparables entre sí, pero la diferencia de orden de magnitud frente a Docker se sostiene en ambas mediciones.

¿Qué está confirmado sobre Tinbase y qué todavía no?

• Confirmado: es código abierto bajo licencia MIT, en el repositorio tinbase/tinbase en GitHub.
• Confirmado: corre Postgres 17 real en el motor nativo, verificable con select version(); vía psql.
• Confirmado: el proyecto está en fase alpha, según el propio README de GitHub (“Alpha — not production-ready yet”).
• No confirmado: si el dashboard Studio en /_/ ya está disponible en la versión estable o sigue en desarrollo; las fuentes se contradicen en este punto.
• No confirmado: el rendimiento en proyectos grandes de producción, un escenario que el propio proyecto desaconseja por ahora.

Errores comunes al pasar a Postgres local sin Docker con Tinbase

• Asumir que reemplaza al Supabase Studio local: según dev.to todavía no había dashboard equivalente al probarlo. Confirmá la versión antes de descartar Docker por este motivo.
• Migrar sin leer los warnings de tinbase import: si el proyecto usa extensiones no soportadas, el comando avisa; ignorarlo puede dejar funcionalidad rota sin que se note al toque.
• Usarlo en producción: el propio repositorio lo marca como alpha, no listo para producción. Es para desarrollo local, prototipos y CI.
• Confundir el motor WASM con el nativo: PGlite corre en cualquier lado pero su heap WASM ronda los 575-650 MB y no baja bajo carga, mientras el motor nativo usa una fracción de eso.

Preguntas Frecuentes

¿Cómo correr Postgres local sin usar Docker?

Con Tinbase, corriendo el script de instalación y después tinbase start --data-dir ~/tinbase-data, que levanta Postgres 17 real en postgresql://postgres@localhost:5432/postgres sin contenedores ni Docker Desktop de por medio.

¿Qué es Tinbase y para qué sirve?

Tinbase es un backend open source bajo licencia MIT que replica el contrato de supabase-js (REST, Auth, Storage, Realtime) en un solo binario con Postgres real. Sirve para desarrollo local, workshops y CI, donde el stack Docker de Supabase pesa demasiado.

¿Tinbase reemplaza a Supabase por completo?

No. El propio proyecto se declara no afiliado a Supabase y aclara que replica el contrato de su SDK sin ser un reemplazo oficial. Está en fase alpha y todavía no cubre funciones como las transformaciones de imagen de Storage.

¿Cuánta RAM consume Postgres local con Tinbase comparado con Docker?

Según el benchmark oficial de tinbase.dev, el motor nativo usa unos 100 MB de memoria bajo carga y el binario único unos 66 MB, contra los 1.626 MB que consume el stack Docker de Supabase con sus 12 contenedores.

¿Cómo migrar un proyecto existente de Supabase a Tinbase?

Exportando el proyecto con supabase db dump --file dump.sql --data-only=false e importándolo con tinbase import --file dump.sql. Si hay extensiones no soportadas, el propio comando avisa con un warning en vez de fallar de golpe.

Conclusión

Correr Postgres local sin Docker dejó de ser una promesa: Tinbase lo resuelve con un binario que arranca en segundos y consume una fracción de la RAM del stack de contenedores. Para laptops chicas, workshops o pipelines de CI que levantan bases todo el día, el ahorro de tiempo y memoria está documentado con números concretos en las fuentes citadas.

Ahora bien, no conviene subirlo a producción todavía. El propio proyecto se declara alpha, y el dashboard equivalente al Supabase Studio local sigue siendo un punto gris entre lo que promociona el sitio oficial y lo que encontró la autora del review. Si tu equipo depende del dashboard o de las transformaciones de imagen de Storage, seguí con Docker por ahora y probá Tinbase primero en un proyecto de prueba, antes de migrar algo que importe.

Fuentes

• Sitio oficial de Tinbase – benchmark, features y documentación
• Repositorio de Tinbase en GitHub – código fuente, CLI y estado alpha
• Running Real Postgres Locally Without Docker (with Tinbase) – review en dev.to