Rowy Review 2026: a full look at the low-code Firestore backend
Firebase gives an application almost everything: authentication, file storage, a database and serverless functions. What it does not give you is a sane way to look at your own data and fix it by hand. As soon as a project grows past “hello world”, the Firestore editor in the Google Cloud console becomes a chore — documents open one at a time, bulk edits are impossible, and you would not want a content editor or a support agent anywhere near it.
Rowy is an attempt to fix exactly that. It is an open-source low-code backend that renders your Firestore collections as an ordinary spreadsheet, Airtable-style, and lets you write TypeScript server logic in the browser on the same screen. Your data stays in your own Google Cloud project rather than shipping off to someone else’s SaaS.
In this review we look at how Rowy is put together, what it can do in 2026, where it hurts, and whether $12 per seat is a fair price — or whether you should head straight for self-hosted alternatives.
What Rowy is
Rowy is a web UI on top of Firebase and Google Cloud. Architecturally it is simple: Rowy does not store your data. It connects to your GCP project, reads your Firestore collections and renders them as a table. Every action — editing a cell, uploading a file, triggering a function — runs on behalf of your project, not through a Rowy middleman.
Two consequences follow:
- You own the data outright. You pick the storage region, you handle GDPR, you pay GCP for reads and traffic. Rowy never becomes your data processor.
- Cost has two parts — the Rowy subscription plus a Google Cloud bill. At small volumes the second part usually fits in the free tier, but it never disappears.
The product ships in two forms: the hosted app at rowy.io and an open GitHub repository you can deploy into your own project. The team claims 30,000+ users and roughly 6,800 GitHub stars. One caveat matters here: the repository has moved to the buildship-ai organization, and the last activity in the open code dates to late 2024 — the team’s focus has shifted to BuildShip.
Worth mentioning BuildShip, the low-code platform for APIs, scheduled jobs and workflows that the same team pushes as a separate product. It is effectively their answer to “we need background jobs, not just data”, and it shows the direction of the whole line: from a table with functions toward a full backend builder.
Pros and cons
What works
- A spreadsheet instead of the Firestore console. Sorting, filters, bulk operations, paste from clipboard — everything the native editor has lacked for years.
- 30+ field types plus derivative fields that recalculate themselves when source data changes.
- Cloud functions inside the UI. TypeScript on the same page as the data, with access to any npm package.
- Your data in your GCP project. No migration and no lock-in if you walk away from the platform.
- A free tier without function or API-call limits. That is rare; most competitors cap exactly those.
- Access control for non-developers. Field-level roles and row-level auditing of who changed what and when.
- Open source. You can read, fork and modify the code; the license does not block commercial use.
What annoys
- Hard lock-in to Firestore. If you run PostgreSQL, MySQL or Supabase, this is not your tool and there is no workaround.
- You need a Google Cloud project with billing enabled for functions and several integrations — extra admin overhead for a small team.
- One project on the free plan. A second project means Pro, and Pro is billed per seat.
- The product is drifting toward BuildShip. Engineering attention moved to the new product, and the changelog shows it: fewer core releases.
- The interface is dense. Newcomers face dozens of fields, extensions and settings and spend the first half hour simply clicking around.
- No mobile client. Browser only.
Features in detail
The data table
The home screen is a grid that looks a lot like Airtable. Columns map to Firestore document fields, rows to documents. Types range from strings and numbers to files, images, references to other collections, geo points, JSON, arrays and timezone-aware dates.
Everything the console lacks works here: range selection with paste from Excel, row duplication, double-click editing, collection search, multi-condition filters and saved views. Large collections get pagination and virtualised rendering, so the table does not freeze on tens of thousands of documents.
Derivative fields are the quiet hero. The classic case is a total field recomputed from price × qty on any change. The logic lives in field configuration instead of being scattered across client and server, which sharply reduces the data drift that plagues Firestore projects.
Action fields are buttons inside a row that invoke your function — the “one click to confirm an order / send an email / rebuild an index” pattern that saves operators hours.
Cloud functions
Rowy lets you write TypeScript cloud functions in an embedded Monaco editor with highlighting, autocomplete and any npm package. A function binds to a collection and a trigger: document created, updated, deleted, or invoked manually from an action field.
In practice this is Rowy’s strongest argument. In a plain Firebase project, adding a trigger means setting up a local environment, installing the Firebase CLI, writing the function in a separate repo, deploying it, and remembering to redeploy later. In Rowy the loop is: open the collection, add a function, save. For operational tasks such as “send an email when status changes” or “log this to an analytics table”, the shortened loop pays for itself quickly.
Limits exist. Debugging is weaker than a classic deploy — no local runner, no breakpoints — so you debug through logs. Dependencies are managed via package.json in the UI, fine for one or two libraries, messy once you have ten functions sharing modules.
Webhooks and extensions
Webhooks pull data in: a website form, a payment provider event, an external API response. Rowy hands you a URL, you POST JSON, a document appears in the collection. It is the fastest way to connect a landing page to a database without your own server.
Extensions push data out: SendGrid for email, Slack and WhatsApp for notifications, Algolia and Typesense for full-text search. Each one is configured through a few fields and runs as a background subscription to collection changes.
A workflow we tested end to end: a landing-page lead hits a webhook → a document lands in the leads collection → a derivative field scores it by company size → a function sends the email through SendGrid and a Slack notification → Algolia indexes the record for the admin search. All of it lives on one screen with zero infrastructure code.
Permissions and auditing
Critical for teams: non-developers get access to data without gaining extra powers. Roles are set per table and per field — a content editor can change status but not price. Row-level auditing (created by, updated by, timestamps) is on the free tier; field-level auditing and backups are Business.
One limitation: user management runs through Firebase Auth, so Rowy does not replace corporate SSO. If your policy demands Okta-only login, that is a blocker — you will need to wire Firebase to an external provider separately.
Pricing
- Base — $0. One project, unlimited collections and records, unlimited cloud functions, unlimited API calls with no rate limit, 30+ field types, CSV/TSV/JSON import and export, row-level auditing, roles, Discord community access.
- Pro — $12 per seat per month (10% off with annual billing). Unlimited projects, full-text search, exports above 10,000 rows, advanced filters, cloning code across projects, a hard GCP billing cap, email support. One-month free trial.
- Business — custom. Everything in Pro plus a custom domain, priority support, data version control, field-level auditing, automated backups and forms.
The point people miss: $12 is not the full bill. Google Cloud charges come on top. For a small project that usually stays at zero — Firestore’s free tier is generous on reads and writes, Cloud Functions gives 2 million invocations a month — but busy collections and frequent triggers push it up, and nobody tracks it for you. On Pro, turn the GCP billing cap on immediately.
The economics are simple. If Rowy saves a developer one day on an admin panel, or takes data-fixing chores off an engineer’s plate, $12 pays for itself instantly. A solo developer can genuinely run one production project on the free Base tier.
How we tested it
We deployed Rowy against a test Firebase project with an orders collection (about 12,000 documents, 18 fields, including a reference to a customers collection and an array of line items) and watched three things: UI speed, function behaviour and usability for a non-developer.
Setup. The web wizard handles it: Google sign-in, project selection, granting the service account the right roles, initialising Rowy collections. The first run takes ten minutes or so, most of it on billing and IAM rather than the product itself.
The table. At 12,000 documents the UI stayed responsive: smooth scrolling, filters applying with a noticeable but tolerable delay, because every query hits Firestore and is billed as reads. Pasting 200 CSV rows completed without errors but took noticeably longer than a local spreadsheet — the price of the serverless model, not a Rowy bug. Bulk-editing a field across 500 documents took several passes: part of the batch hit Firestore batch-operation limits.
Functions. A trigger on order status update sending email through SendGrid worked on the second save — the first version failed on a missing package, because dependencies must be added to package.json by hand. Stable after that. Logs are readable in the UI, but they confirm that debugging is the weak spot: without a local emulator, the save-and-read-logs loop gets tiring.
A non-developer. A content editor with no technical background learned filters and field editing in about 20 minutes — probably the best signal the product has. Field-level restrictions behaved as expected: a forbidden field simply is not editable.
Verdict from the test: Rowy really does remove the routine around Firestore, but it does not turn Firebase into a relational database, and it is not magic for bulk operations.
Alternatives
- Airtable — prettier and simpler, but the data lives with Airtable, not you, and team pricing stings. Rowy wins on data ownership and backend logic.
- Retool — stronger at internal tools (forms, dashboards, dozens of components), but it is not a data CMS and not a Firestore admin replacement. Often complementary rather than competing.
- NocoDB and Baserow — open-source spreadsheet frontends for SQL databases (PostgreSQL, MySQL). If your stack is not Firebase, look there.
- A homegrown React Admin panel — flexible and free, but weeks of work and permanent maintenance. Rowy is cheaper while the tasks stay standard.
Who it fits
Buy it if: you run Firebase/Firestore, hold operational data (orders, leads, catalogue, users) that needs regular edits, and especially if non-developers need access without a custom admin build. A good sign: you already catch yourself opening the GCP console to fix one field and burning five minutes on a five-second task.
Skip it if: your database is not Firestore; you need corporate SSO out of the box; you plan heavy analytics and bulk ETL — that is BigQuery and specialist tooling. Think twice if predictable product direction matters: the team’s focus has shifted toward BuildShip.
The in-between case is a startup that began on Firebase and is slowly moving to PostgreSQL. Rowy will not help there: it does not ease the migration and becomes useless after it. Treat it as a long-term admin foundation only if you are confident Firestore stays your primary database for a year or two.
Verdict
Rowy is a narrow, sharply focused tool. It does not try to be a universal low-code platform and does not fight Retool for dashboard building; it plugs one specific hole in Firebase — the lack of a human interface for data — and does it neatly.
Strengths: the table, derivative and action fields, built-in TypeScript functions, full data ownership. Weaknesses: Firestore-only, weak function debugging, and growing competition for the team’s attention from BuildShip.
For a Firebase project where data is edited by hand more than once a week, the free Base tier covers most needs, and Pro at $12 per seat is fair for unlimited projects and full-text search. For every other stack Rowy is simply the wrong tool — and it never claimed otherwise.
Score: 8/10 — an excellent specialised tool with an honest pricing model and one significant limitation: a single supported database.