Rowy Review 2026: полный обзор low-code бэкенда на Firestore

Firebase даёт приложению почти всё: аутентификацию, хранилище файлов, базу данных и serverless-функции. Не даёт он одного — удобного способа смотреть на свои данные и править их руками. Как только проект выходит за пределы «hello world», редактор Firestore в консоли Google Cloud превращается в пытку: документы открываются по одному, массовая правка невозможна, а менеджеру или контент-редактору туда лучше вообще не заходить.

Rowy — попытка решить именно эту проблему. Это open-source low-code бэкенд, который показывает вашу коллекцию Firestore в виде обычной таблицы (как в Excel или Airtable) и позволяет тут же, в браузере, писать серверную логику на TypeScript. Данные при этом остаются в вашем собственном проекте Google Cloud, а не уходят в чужой SaaS.

В этом обзоре мы разберём, как Rowy устроен, что он умеет в 2026 году, где лежат подводные камни и стоит ли отдавать ему $12 за место — или лучше сразу смотреть в сторону self-hosted альтернатив.

Что такое Rowy

Rowy — веб-интерфейс поверх Firebase и Google Cloud. Архитектурно всё просто: Rowy не хранит ваши данные у себя. Он подключается к вашему проекту GCP, читает коллекции Firestore и рендерит их в табличном виде. Каждое действие — правка ячейки, загрузка файла, запуск функции — выполняется от имени вашего проекта, а не через промежуточный сервер Rowy.

Отсюда вытекают два важных следствия:

1. Владение данными остаётся полным. Вы сами выбираете регион хранения, сами отвечаете за GDPR, сами платите GCP за трафик и чтения. Rowy не становится вашим data processor.
2. Стоимость складывается из двух частей — подписка Rowy плюс счёт от Google Cloud. Вторая часть при небольшой нагрузке почти всегда попадает в бесплатный лимит, но забывать о ней нельзя.

Сам продукт состоит из двух частей: облачного приложения rowy.io и открытого репозитория на GitHub, который можно развернуть в своём проекте. Разработчики заявляют более 30 000 пользователей и около 6 800 звёзд на GitHub. Но здесь нужна оговорка: репозиторий переехал в организацию buildship-ai, а последняя активность в открытом коде датируется концом 2024 года — основной фокус команды сместился на BuildShip.

Отдельно стоит сказать про BuildShip — low-code платформу для API, планировщиков и воркфлоу, которую команда Rowy продвигает как отдельный продукт. Фактически это ответ на запрос «нам нужны не только данные, но и фоновые задачи», и он показывает, куда движется вся линейка: от таблицы с функциями к полноценному backend-конструктору.

Плюсы и минусы

Что нравится

• Табличный интерфейс вместо консоли Firestore. Сортировка, фильтры, массовые операции, вставка из буфера обмена — всё то, чего годами не хватало в родном редакторе.
• Более 30 типов полей и производные поля (derivative), которые сами пересчитываются при изменении данных.
• Cloud functions прямо в интерфейсе. Пишете TypeScript на той же странице, где лежат данные, и можете использовать любой npm-пакет.
• Данные в вашем GCP-проекте. Никакой миграции и никакой зависимости от чужого хостинга в случае ухода с платформы.
• Бесплатный тариф без ограничений на число функций и вызовов API. Это редкость: большинство конкурентов режет именно функции.
• Разграничение прав для не-разработчиков. Роли на уровне полей, аудит изменений: кто и когда поменял значение.
• Open source. Код можно читать, форкать и дорабатывать; лицензия не блокирует коммерческое использование.

Что раздражает

• Жёсткая привязка к Firestore. Если у вас PostgreSQL, MySQL или Supabase — Rowy не ваш инструмент, и обойти это нельзя.
• Требуется проект Google Cloud с включённым биллингом для функций и ряда интеграций. Для маленькой команды это дополнительная административная возня.
• Квота «один проект» на бесплатном тарифе. Второй проект — уже Pro, а Pro считается за место в команде.
• Продукт заметно «вырос» в сторону BuildShip. Часть внимания команды ушла в новый продукт, и по changelog это чувствуется: обновлений ядра стало меньше.
• Интерфейс местами перегружен. Новичок видит десятки полей, расширений и настроек и первые полчаса просто не понимает, что нажимать.
• Нет собственного мобильного клиента. Всё — только через браузер.

Функциональность: разбор по блокам

Таблица данных

Главный экран Rowy — это сетка, очень похожая на Airtable. Колонки соответствуют полям документа Firestore, строки — документам. Поддерживаются типы от простых строк и чисел до файлов, изображений, ссылок на другие коллекции, координат, JSON, массивов и дат с часовым поясом.

Работает всё, чего не хватает в консоли: выделение диапазона и вставка данных из Excel, копирование строк, быстрое редактирование по двойному клику, поиск по коллекции, фильтры по нескольким условиям и сохранённые представления. Для больших коллекций есть пагинация и виртуализированный рендер — таблица не виснет на десятках тысяч документов.

Отдельно полезны derivative fields. Классический пример — поле total, которое пересчитывается из price × qty при любом изменении. Логика хранится в конфигурации поля, а не размазана по клиенту и серверу, и это заметно снижает шанс рассинхронизации данных — типичной боли Firestore-проектов.

Action fields — кнопки в строке таблицы, которые запускают вашу функцию. Это тот самый паттерн «одна кнопка, чтобы подтвердить заказ / отправить письмо / пересобрать индекс», и он экономит часы ручной работы операторам.

Cloud functions

Rowy позволяет писать cloud functions на TypeScript в встроенном Monaco-редакторе — с подсветкой, автодополнением и доступом к любому npm-пакету. Функция привязывается к коллекции и триггеру: создание, обновление, удаление документа или вызов вручную/из action-поля.

На практике это главный аргумент в пользу Rowy. В обычном Firebase-проекте, чтобы добавить триггер, нужно настроить локальную среду, поставить Firebase CLI, написать функцию в отдельном репозитории, задеплоить и потом не забыть обновить. В Rowy цикл выглядит так: открыл коллекцию → добавил функцию → сохранил. Для операционных задач вроде «отправить письмо при смене статуса» или «записать лог в аналитическую таблицу» такой сокращённый цикл окупается быстро.

Ограничения тоже есть. Отладка слабее, чем в классическом деплое: нет нормального локального запуска и брейкпоинтов, поэтому ошибки ловятся по логам. Зависимости ставятся через package.json прямо в интерфейсе, что удобно для одной-двух библиотек, но при десятке функций и общих модулях начинает путаться.

Вебхуки и расширения

Вебхуки принимают данные извне: форма на сайте, событие из платёжной системы, ответ внешнего API. Схема простая: Rowy выдаёт URL, вы шлёте POST с JSON, документ появляется в коллекции. Это самый быстрый способ связать лендинг с базой без собственного сервера.

Расширения отправляют данные наружу: SendGrid для писем, Slack и WhatsApp для уведомлений, Algolia и Typesense для полнотекстового поиска. Каждое расширение настраивается в несколько полей и работает как фоновая подписка на изменения коллекции.

Практический сценарий, который мы проверяли: заявка с лендинга → вебхук → документ в коллекции leads → derivative-поле считает приоритет по размеру компании → функция шлёт письмо через SendGrid и уведомление в Slack → Algolia индексирует запись для поиска в админке. Всё это живёт в одном экране и не требует ни строчки инфраструктурного кода.

Права доступа и аудит

Для команд это критично: не-разработчики получают доступ к данным, но не получают лишних возможностей. Роли настраиваются на уровне таблиц и отдельных полей: редактор контента может менять status, но не price. Есть аудит на уровне строк (кто создал, кто изменил, когда) — на бесплатном тарифе, а поле-уровневый аудит и бэкапы уже в Business.

Ограничение: управление пользователями идёт через Firebase Auth, и это значит, что Rowy не заменяет корпоративный SSO. Для компаний с требованием «вход только через Okta» это станет блокером — придётся интегрировать Firebase с внешним провайдером отдельно.

Цены

Тарифная сетка Rowy в 2026 году выглядит так:

• Base — $0. Один проект, неограниченное число коллекций и записей, неограниченные cloud functions, неограниченные вызовы API без рейт-лимита, более 30 типов полей, импорт и экспорт CSV/TSV/JSON, аудит на уровне строк, роли, доступ к Discord-сообществу.
• Pro — $12 за место в месяц (при годовой оплате — скидка 10%). Неограниченное число проектов, полнотекстовый поиск, экспорт больших датасетов (свыше 10 000 строк), расширенные фильтры, клонирование кода между проектами, жёсткий лимит биллинга GCP, поддержка по почте. Есть месячный бесплатный триал.
• Business — по запросу. Всё из Pro плюс собственный домен, приоритетная поддержка, версионирование данных, аудит на уровне полей, автоматические бэкапы и формы.

Ключевой момент, который часто упускают: $12 — это не полная стоимость. К подписке добавляется счёт Google Cloud. Для маленького проекта он почти наверняка останется нулевым: Firestore имеет щедрый бесплатный лимит на чтения и записи, Cloud Functions — 2 млн вызовов в месяц. Но при активных коллекциях и частых триггерах счёт начинает расти, и следить за ним нужно самостоятельно. В Pro есть ограничитель биллинга GCP — имеет смысл включать его сразу.

Экономика простая: если Rowy заменяет разработчику хотя бы день работы над админкой или снимает с инженера рутину правки данных, $12 окупаются мгновенно. Для одиночного разработчика на бесплатном тарифе Base реально можно вести один продакшн-проект.

Как мы тестировали

Мы разворачивали Rowy на тестовом проекте Firebase с коллекцией заказов (около 12 000 документов, 18 полей, включая ссылку на коллекцию клиентов и массив позиций) и смотрели на три вещи: скорость работы интерфейса, поведение функций и удобство для не-разработчика.

Подключение. Установка идёт через веб-мастер: авторизация в Google, выбор проекта, предоставление сервисному аккаунту нужных ролей, инициализация коллекций Rowy. Первый запуск занимает десяток минут, основное время уходит на биллинг и IAM — не на сам продукт.

Таблица. На 12 тысячах документов интерфейс оставался отзывчивым: скролл плавный, фильтры применяются с заметной, но терпимой задержкой, потому что каждый запрос уходит в Firestore и оплачивается как чтения. Вставка 200 строк из CSV прошла без ошибок, но заняла ощутимо больше времени, чем в локальной таблице, — это цена serverless-модели, а не баг Rowy. Массовое изменение поля у 500 документов потребовало нескольких подходов: часть записей упёрлась в лимиты Firestore на пакетные операции.

Функции. Триггер на обновление статуса заказа с отправкой письма через SendGrid заработал со второго сохранения — первая версия упала на отсутствующем пакете, потому что зависимости нужно добавлять в package.json вручную. После этого стабильно. Логи читаются в интерфейсе, но по ним видно, что отладка — слабое место: без локального эмулятора цикл «сохранил — посмотрел лог» раздражает.

Не-разработчик. Редактор контента без технического бэкграунда освоил фильтры и правку полей примерно за 20 минут — это, пожалуй, лучший показатель продукта. Ограничения по полям сработали как ожидалось: запрещённое поле просто не редактируется.

Итог теста: Rowy действительно убирает рутину вокруг Firestore, но не превращает Firebase в «настоящую» реляционную базу, и ожидать от него чудес при массовых операциях не стоит.

Альтернативы

• Airtable — проще и красивее, но данные живут у Airtable, а не у вас, а цены на команды кусаются. Rowy выигрывает в контроле над данными и в бэкенд-логике.
• Retool — сильнее в интерфейсах для внутренних инструментов (формы, дашборды, десятки компонентов), но это не CMS для данных и не замена Firestore-админке. Часто они не конкуренты, а дополняют друг друга.
• NocoDB и Baserow — open-source табличные фронтенды, но для SQL-баз (PostgreSQL, MySQL). Если ваш стек не Firebase, смотрите на них.
• Собственная админка на React Admin — гибко и бесплатно, но это недели разработки и вечная поддержка. Rowy дешевле, пока задачи типовые.

Кому подходит Rowy

Берите, если: у вас Firebase/Firestore, есть операционные данные (заказы, заявки, каталог, пользователи), и правки в них нужны регулярно. Особенно если к данным нужно пускать не-разработчиков, а писать отдельную админку не хочется. Хороший признак: вы уже ловите себя на том, что открываете консоль GCP, чтобы поправить одно поле, и тратите на это пять минут вместо пяти секунд.

Не берите, если: база не Firestore; нужен корпоративный SSO из коробки; планируете тяжёлую аналитику и массовые ETL-операции — для этого есть BigQuery и специализированные инструменты. Также стоит подумать дважды, если критична предсказуемость развития продукта: фокус команды сместился на BuildShip.

Промежуточный случай — стартап, который начинал на Firebase и постепенно уезжает в сторону PostgreSQL. Rowy здесь не поможет: миграцию он не облегчает, а после переезда становится бесполезен. Планировать его как долгосрочную основу админки стоит только при уверенности, что Firestore останется основной базой хотя бы на горизонте года-двух.

Вердикт

Rowy — узкий, но очень хорошо заточенный инструмент. Он не пытается быть универсальной low-code платформой и не конкурирует с Retool за конструктор дашбордов; он закрывает одну конкретную дыру Firebase — отсутствие человеческого интерфейса для данных — и делает это аккуратно.

Сильные стороны — таблица, derivative и action-поля, встроенные TypeScript-функции и полное владение данными. Слабые — привязка к Firestore, слабая отладка функций и растущая конкуренция за внимание команды со стороны BuildShip.

Для проекта на Firebase, где данные правят вручную чаще раза в неделю, бесплатный Base закрывает большинство потребностей, а Pro за $12 за место — разумная цена за неограниченные проекты и полнотекстовый поиск. Для всех остальных стеков Rowy просто не тот инструмент, и это нормально: он и не обещал быть универсальным.

Оценка: 8 из 10 — отличный специализированный инструмент с честной ценовой моделью и одним существенным ограничением в виде единственной поддерживаемой базы данных.