Rowy Review 2026: análisis completo del backend low-code para Firestore

Firebase le da a una aplicación casi todo: autenticación, almacenamiento de archivos, base de datos y funciones serverless. Lo que no da es una forma razonable de mirar los propios datos y corregirlos a mano. En cuanto un proyecto supera el “hola mundo”, el editor de Firestore en la consola de Google Cloud se vuelve una tortura: los documentos se abren de uno en uno, la edición masiva es imposible y no querrías que un redactor o un agente de soporte entrara allí.

Rowy intenta resolver exactamente eso. Es un backend low-code de código abierto que muestra tus colecciones de Firestore como una hoja de cálculo normal, al estilo Airtable, y permite escribir lógica de servidor en TypeScript desde el navegador, en la misma pantalla. Los datos siguen en tu propio proyecto de Google Cloud, no en el SaaS de un tercero.

En este análisis veremos cómo está construido Rowy, qué puede hacer en 2026, dónde duele y si 12 dólares por usuario es un precio justo — o si conviene ir directamente a alternativas autoalojadas.

Qué es Rowy

Rowy es una interfaz web sobre Firebase y Google Cloud. La arquitectura es simple: Rowy no almacena tus datos. Se conecta a tu proyecto de GCP, lee las colecciones de Firestore y las renderiza como tabla. Cada acción —editar una celda, subir un archivo, lanzar una función— se ejecuta en nombre de tu proyecto, no a través de un intermediario de Rowy.

De ahí se derivan dos consecuencias:

1. La propiedad de los datos es total. Eliges la región de almacenamiento, asumes el RGPD y pagas a GCP las lecturas y el tráfico. Rowy nunca se convierte en encargado del tratamiento.
2. El costo tiene dos partes —la suscripción a Rowy y la factura de Google Cloud—. Con poco volumen la segunda suele entrar en la capa gratuita, pero nunca desaparece.

El producto existe en dos formas: la aplicación alojada en rowy.io y un repositorio abierto en GitHub que puedes desplegar en tu propio proyecto. El equipo declara más de 30.000 usuarios y unas 6.800 estrellas en GitHub. Un matiz importante: el repositorio se trasladó a la organización buildship-ai y la última actividad en el código abierto es de finales de 2024; el foco del equipo está ahora en BuildShip.

Merece mención BuildShip, la plataforma low-code para APIs, tareas programadas y flujos de trabajo que el mismo equipo impulsa como producto aparte. Es su respuesta a “necesitamos trabajos en segundo plano, no solo datos”, y muestra hacia dónde va toda la línea: de la tabla con funciones a un constructor de backend completo.

Ventajas y desventajas

Lo que convence

• Una hoja de cálculo en lugar de la consola de Firestore. Ordenar, filtrar, operaciones masivas, pegar desde el portapapeles: todo lo que el editor nativo lleva años sin tener.
• Más de 30 tipos de campo y campos derivados que se recalculan solos cuando cambian los datos de origen.
• Cloud Functions dentro de la interfaz. TypeScript en la misma página que los datos, con acceso a cualquier paquete npm.
• Tus datos en tu proyecto de GCP. Sin migración y sin dependencia si abandonas la plataforma.
• Capa gratuita sin límites de funciones ni de llamadas a la API. Es raro: la mayoría de la competencia limita justo eso.
• Control de acceso para quienes no programan. Roles por campo y auditoría por fila: quién cambió qué y cuándo.
• Código abierto. Puedes leer, bifurcar y modificar el código; la licencia no bloquea el uso comercial.

Lo que molesta

• Dependencia absoluta de Firestore. Si usas PostgreSQL, MySQL o Supabase, esta no es tu herramienta y no hay forma de sortearlo.
• Requiere un proyecto de Google Cloud con facturación activa para funciones y varias integraciones: trámite extra para equipos pequeños.
• Un solo proyecto en el plan gratuito. El segundo proyecto ya implica Pro, y Pro se cobra por usuario.
• El producto se está desplazando hacia BuildShip. La atención de ingeniería se fue al producto nuevo y el changelog lo refleja: menos versiones del núcleo.
• La interfaz está sobrecargada. Un recién llegado ve decenas de campos, extensiones y ajustes y pasa la primera media hora haciendo clic sin entender nada.
• Sin cliente móvil. Solo navegador.

Funciones en detalle

La tabla de datos

La pantalla principal es una cuadrícula muy parecida a Airtable. Las columnas corresponden a campos del documento de Firestore y las filas a documentos. Hay tipos desde cadenas y números hasta archivos, imágenes, referencias a otras colecciones, coordenadas, JSON, arrays y fechas con zona horaria.

Todo lo que falta en la consola funciona aquí: selección de rangos con pegado desde Excel, duplicar filas, edición con doble clic, búsqueda en la colección, filtros con varias condiciones y vistas guardadas. Las colecciones grandes tienen paginación y renderizado virtualizado, así que la tabla no se congela con decenas de miles de documentos.

Los campos derivados son el héroe silencioso. El caso clásico es un campo total recalculado a partir de price × qty en cada cambio. La lógica vive en la configuración del campo y no repartida entre cliente y servidor, lo que reduce mucho la desincronización típica de los proyectos de Firestore.

Los campos de acción son botones dentro de una fila que invocan tu función: el patrón “un clic para confirmar un pedido / enviar un correo / reconstruir un índice” que ahorra horas a los equipos de operaciones.

Cloud Functions

Rowy permite escribir cloud functions en TypeScript en un editor Monaco integrado, con resaltado, autocompletado y cualquier paquete npm. Una función se asocia a una colección y a un disparador: documento creado, actualizado, eliminado o invocado manualmente desde un campo de acción.

En la práctica es el argumento más fuerte de Rowy. En un proyecto Firebase normal, añadir un disparador implica montar el entorno local, instalar la CLI de Firebase, escribir la función en un repositorio aparte, desplegarla y acordarse de volver a desplegar. En Rowy el ciclo es: abrir la colección, añadir la función, guardar. Para tareas como “enviar un correo cuando cambia el estado” o “registrar esto en una tabla analítica”, el ciclo corto se amortiza rápido.

Hay límites. La depuración es más débil que en un despliegue clásico —sin ejecución local ni puntos de interrupción—, así que se depura por logs. Las dependencias se gestionan con package.json en la interfaz: cómodo para una o dos librerías, caótico con diez funciones compartiendo módulos.

Webhooks y extensiones

Los webhooks traen datos de fuera: un formulario del sitio, un evento de la pasarela de pago, la respuesta de una API externa. Rowy entrega una URL, tú envías un POST con JSON y aparece un documento en la colección. Es la forma más rápida de conectar una landing con la base de datos sin servidor propio.

Las extensiones envían datos hacia fuera: SendGrid para correo, Slack y WhatsApp para avisos, Algolia y Typesense para búsqueda de texto completo. Cada una se configura con unos pocos campos y funciona como suscripción en segundo plano a los cambios de la colección.

Un flujo que probamos de principio a fin: un lead del formulario llega al webhook → el documento entra en leads → un campo derivado lo puntúa por tamaño de empresa → una función envía el correo con SendGrid y el aviso a Slack → Algolia indexa el registro para la búsqueda del panel. Todo en una pantalla y sin una línea de código de infraestructura.

Permisos y auditoría

Clave para los equipos: las personas que no programan acceden a los datos sin obtener poderes extra. Los roles se definen por tabla y por campo: un redactor puede cambiar status pero no price. La auditoría por fila (quién creó, quién actualizó, marcas de tiempo) está en la capa gratuita; la auditoría por campo y las copias de seguridad son de Business.

Una limitación: la gestión de usuarios pasa por Firebase Auth, así que Rowy no sustituye un SSO corporativo. Si tu política exige entrar solo con Okta, esto es un bloqueo: habrá que conectar Firebase con un proveedor externo por separado.

Precios

• Base — 0 $. Un proyecto, colecciones y registros ilimitados, cloud functions ilimitadas, llamadas a la API ilimitadas sin límite de tasa, más de 30 tipos de campo, importación y exportación CSV/TSV/JSON, auditoría por fila, roles, acceso a la comunidad de Discord.
• Pro — 12 $ por usuario al mes (10% de descuento con pago anual). Proyectos ilimitados, búsqueda de texto completo, exportación de más de 10.000 filas, filtros avanzados, clonar código entre proyectos, tope duro de facturación de GCP, soporte por correo. Un mes de prueba gratis.
• Business — a medida. Todo lo de Pro más dominio propio, soporte prioritario, versionado de datos, auditoría por campo, copias de seguridad automáticas y formularios.

El detalle que muchos pasan por alto: 12 $ no es la factura completa. Los cargos de Google Cloud van aparte. En un proyecto pequeño suelen quedarse en cero —Firestore tiene una capa gratuita generosa en lecturas y escrituras y Cloud Functions da 2 millones de invocaciones al mes—, pero colecciones activas y disparadores frecuentes la suben, y nadie la vigila por ti. En Pro conviene activar el tope de facturación de GCP de inmediato.

La economía es sencilla: si Rowy le ahorra a un desarrollador un día de trabajo en un panel de administración, o le quita a un ingeniero la rutina de corregir datos, los 12 $ se amortizan al instante. Un desarrollador en solitario puede llevar un proyecto en producción con la capa Base gratuita.

Cómo lo probamos

Desplegamos Rowy sobre un proyecto de prueba en Firebase con una colección de pedidos (unos 12.000 documentos, 18 campos, con referencia a una colección de clientes y un array de líneas de pedido) y observamos tres cosas: velocidad de la interfaz, comportamiento de las funciones y facilidad de uso para alguien no técnico.

Instalación. El asistente web lo resuelve: inicio de sesión con Google, selección de proyecto, asignación de roles a la cuenta de servicio e inicialización de las colecciones de Rowy. La primera puesta en marcha lleva unos diez minutos, la mayor parte en facturación e IAM más que en el producto.

La tabla. Con 12.000 documentos la interfaz siguió ágil: desplazamiento fluido y filtros con un retraso perceptible pero tolerable, porque cada consulta va a Firestore y se factura como lecturas. Pegar 200 filas de CSV terminó sin errores pero tardó bastante más que una hoja local: es el precio del modelo serverless, no un fallo de Rowy. Editar en masa un campo en 500 documentos exigió varios intentos: parte del lote chocó con los límites de operaciones por lote de Firestore.

Funciones. Un disparador por cambio de estado que enviaba correo con SendGrid funcionó al segundo guardado: la primera versión falló por un paquete ausente, porque las dependencias se añaden a mano en package.json. Después, estable. Los logs se leen en la interfaz, pero confirman que la depuración es el punto débil: sin emulador local, el ciclo de guardar y mirar el log cansa.

Alguien no técnico. Un redactor sin formación técnica aprendió los filtros y la edición de campos en unos 20 minutos: probablemente la mejor señal del producto. Las restricciones por campo funcionaron como se esperaba: un campo prohibido simplemente no es editable.

Conclusión de la prueba: Rowy sí elimina la rutina alrededor de Firestore, pero no convierte Firebase en una base relacional ni hace magia con las operaciones masivas.

Alternativas

• Airtable — más bonito y sencillo, pero los datos viven en Airtable y no contigo, y los precios por equipo escuecen. Rowy gana en propiedad de los datos y lógica de backend.
• Retool — más fuerte en herramientas internas (formularios, paneles, decenas de componentes), pero no es un CMS de datos ni un reemplazo del panel de Firestore. A menudo se complementan.
• NocoDB y Baserow — frontends de hoja de cálculo de código abierto para bases SQL (PostgreSQL, MySQL). Si tu stack no es Firebase, mira ahí.
• Un panel propio con React Admin — flexible y gratis, pero semanas de trabajo y mantenimiento eterno. Rowy sale más barato mientras las tareas sean estándar.

Para quién es

Cómpralo si: usas Firebase/Firestore, tienes datos operativos (pedidos, leads, catálogo, usuarios) que se editan con regularidad y, sobre todo, si personas no técnicas necesitan acceso sin construir un panel a medida. Buena señal: ya te descubres abriendo la consola de GCP para corregir un campo y perdiendo cinco minutos en una tarea de cinco segundos.

No lo compres si: tu base no es Firestore; necesitas SSO corporativo de serie; planeas analítica pesada y ETL masivo —para eso están BigQuery y herramientas especializadas—. Piéntalo dos veces si te importa la previsibilidad del producto: el foco del equipo se movió hacia BuildShip.

El caso intermedio es una startup que empezó en Firebase y migra poco a poco a PostgreSQL. Rowy no ayuda: no facilita la migración y queda inútil después. Como base de administración a largo plazo solo tiene sentido si Firestore seguirá siendo la base principal uno o dos años.

Veredicto

Rowy es una herramienta estrecha y muy bien afilada. No intenta ser una plataforma low-code universal ni compite con Retool por el constructor de paneles; tapa un agujero concreto de Firebase —la falta de una interfaz humana para los datos— y lo hace con pulcritud.

Fortalezas: la tabla, los campos derivados y de acción, las funciones TypeScript integradas y la propiedad total de los datos. Debilidades: solo Firestore, depuración floja de funciones y una competencia creciente por la atención del equipo desde BuildShip.

Para un proyecto en Firebase donde los datos se editan a mano más de una vez por semana, la capa Base gratuita cubre la mayoría de las necesidades, y Pro a 12 $ por usuario es razonable por proyectos ilimitados y búsqueda de texto completo. Para cualquier otro stack, Rowy simplemente no es la herramienta adecuada, y nunca dijo lo contrario.

Puntuación: 8 sobre 10 — una excelente herramienta especializada, con un modelo de precios honesto y una limitación importante: una sola base de datos compatible.