Rebase frente a Appwrite
Los dos te dan auth, una base de datos, almacenamiento, funciones y tiempo real detrás de una API. La diferencia es la base de datos. La de Appwrite pertenece a la plataforma: llegas a ella a través de la API de Appwrite, y su opción de SQL nativo viene sin la plataforma. Rebase genera la API, el SDK tipado y un panel de administración sobre un Postgres que es tuyo, y hace cumplir el acceso en la propia base de datos.
La plataforma o SQL — o las dos cosas
Dónde duele
Appwrite 2.0 ejecuta TablesDB sobre PostgreSQL por defecto, con columnas de relación y transacciones. Pero la base de datos es de Appwrite: crea y gestiona el esquema, llegas a los datos por su API de consultas, REST o GraphQL en lugar de SQL, y no hay ninguna forma documentada de apuntarlo a las tablas de una base de datos que ya tienes. Appwrite Cloud vende ahora también PostgreSQL nativo con SQL completo — que su propia documentación describe sin ninguna capa de Appwrite de por medio. Eliges entre la plataforma y la base de datos.
Qué hace Rebase en su lugar
Rebase genera la plataforma encima de un Postgres que es tuyo, así que no hay nada entre lo que elegir.
- Apúntalo a una base de datos existente y deduce las colecciones de las tablas que ya están ahí.
- La API generada y psql leen las mismas tablas, así que las herramientas de BI y los procesos ETL siguen funcionando.
- Cuando la API generada no basta, escribe el join o la vista en SQL.
Permisos en el servidor, o en la base de datos
Dónde duele
El modelo de permisos de Appwrite es bueno: leer, crear, actualizar y borrar sobre tablas y filas, para cualquier visitante, usuarios con sesión, un usuario, un equipo, un rol de equipo o una etiqueta, cerrado por defecto y respetado en tiempo real. Pero lo impone el servidor de Appwrite, así que protege las peticiones que pasan por ese servidor. Una clave de API de servidor con los scopes adecuados se lo salta por completo, y el PostgreSQL nativo de Cloud no tiene nada de eso.
Qué hace Rebase en su lugar
Rebase compila las reglas de acceso a seguridad a nivel de fila de Postgres, así que se cumplen llegue la consulta por donde llegue.
- Las reglas se declaran en la colección, en TypeScript, y llegan a la base de datos como políticas reales.
- Una tabla sin RLS no se sirve, y una clave de API nunca se salta una política.
- Las suscripciones en tiempo real se entregan bajo las mismas políticas que cualquier otra lectura.
Una consola para desarrolladores, o un panel de administración para tu equipo
Dónde duele
La consola de Appwrite es una buena herramienta para desarrolladores: un editor de tablas, importación y exportación CSV, logs y, desde la 2.0, un explorador de la API y una terminal para la CLI. No está hecha para la gente que lleva el negocio. No hay formularios propios ni vistas de flujo de trabajo, nada que alguien de soporte o de contenidos reconozca como su herramienta — así que ese panel sigue siendo un proyecto que construyes tú sobre el SDK.
Qué hace Rebase en su lugar
Rebase genera Rebase CMS, un panel de administración en React, desde la misma definición de colección que la API.
- Tablas tipo hoja de cálculo, formularios y tableros kanban, generados desde el esquema.
- Se le puede dar a gente no técnica sin miedo, porque las políticas están en la base de datos.
- Sustituye cualquier parte con tus propios componentes React.
No cambies
Cuándo quedarte en Appwrite
Cuando tu app es Flutter, Swift o Kotlin: Appwrite tiene SDKs de cliente oficiales para los tres, y el SDK tipado de Rebase es solo TypeScript. Cuando quieres notificaciones push y SMS, decenas de proveedores OAuth o funciones en Python, Go o Dart desde la misma plataforma — Appwrite trae todo eso y Rebase no. Y cuando nadie fuera de ingeniería va a abrir el back office y nada salvo tu app va a leer nunca los datos, una base de datos a la que no llegas directamente no es un coste que vayas a notar.
Rebase y Appwrite, respondido
¿Puedo pasar un proyecto de Appwrite a Rebase?
Sí, pero es una migración y no un cambio de conexión, porque la base de datos de Appwrite pertenece a Appwrite aunque corra sobre PostgreSQL. Las filas salen por su API y entran en tablas de Postgres que defines tú — casi siempre una a una, porque TablesDB ya son tablas, filas y columnas, y las columnas de relación pasan a ser claves foráneas. Los usuarios, los archivos y las funciones son implementaciones de Appwrite, así que se trasladan o se reescriben en vez de conectarse.
Appwrite ya funciona sobre PostgreSQL. ¿Qué sigue siendo distinto?
A quién obedece la base de datos. Un Appwrite 2.0 autoalojado usa PostgreSQL por defecto, pero Appwrite crea el esquema, comprueba los permisos en su propio servidor y expone los datos por su API de consultas, REST y GraphQL, no por SQL. El PostgreSQL nativo de Appwrite Cloud te da SQL — y a cambio, ni SDKs de Appwrite ni permisos de la plataforma. Rebase es las dos cosas a la vez: la API, el SDK tipado y el panel de administración se generan sobre tablas que también puedes abrir en psql, bajo la misma seguridad a nivel de fila.
¿Cubre Rebase las funciones de autenticación de Appwrite?
La mayoría, con huecos que conviene nombrar. Rebase trae email y contraseña, magic links, códigos de un solo uso por email, sesiones anónimas, multifactor TOTP, claves de API con alcance y doce proveedores OAuth y OIDC — o tu propio adaptador delante de Auth0, Clerk o Firebase Auth. Appwrite tiene bastantes más proveedores OAuth, inicio de sesión por teléfono y SMS, y email o SMS como segundo factor. Ninguno de los dos trae SAML integrado para tus usuarios finales. Lo que aporta Rebase es dónde viven los usuarios: una tabla en tu propio Postgres contra la que las políticas y las consultas pueden hacer join.
¿Cuándo es Appwrite la mejor opción?
Cuando tu app es Flutter, Swift o Kotlin: Appwrite tiene SDKs de cliente oficiales para los tres, y el SDK tipado de Rebase es solo TypeScript. Cuando quieres notificaciones push y SMS, decenas de proveedores OAuth o funciones en Python, Go o Dart desde la misma plataforma — Appwrite trae todo eso y Rebase no. Y cuando nadie fuera de ingeniería va a abrir el back office y nada salvo tu app va a leer nunca los datos, una base de datos a la que no llegas directamente no es un coste que vayas a notar.
¿Tiene Rebase funciones, almacenamiento y mensajería como Appwrite?
Funciones y almacenamiento, sí; mensajería, solo por email. Rebase tiene funciones en TypeScript montadas como rutas de la API, tareas cron, trabajos en segundo plano con reintentos y almacenamiento de archivos en disco local, cualquier servicio compatible con S3 o Google Cloud Storage. Envía email transaccional por SMTP, pero no tiene notificaciones push ni SMS, y sus funciones son solo TypeScript, mientras que las de Appwrite corren en más de una docena de lenguajes.
¿Tengo que autoalojar Rebase?
No. Si lo autoalojas, son tuyos los datos, el código y la máquina en la que corre — es el modo por defecto y está plenamente soportado. O despliega el mismo proyecto en Rebase Cloud, que hoy está en producción con clientes reales y se abre por tandas mientras está en beta privada, con precio por recurso y no por usuario. Tu código es idéntico en ambos casos; el hosting es un destino de despliegue, no una bifurcación.
No te fíes de nuestra palabra.
La comparación que importa es la que ejecutas tú. Apunta Rebase a una base de datos Postgres que ya tengas y mira cómo aguanta al lado de Appwrite.