Rowy

Open-source low-code backend for Firebase, honestly reviewed. Because “Airtable for Firestore” is a narrower pitch than it sounds.

TL;DR

• What it is: Open-source (Apache 2.0) spreadsheet UI for Firestore with an in-browser Cloud Functions editor — a low-code backend layer specifically for Google Cloud Platform and Firebase [3][2].
• Who it’s for: Firebase developers who want non-technical teammates to manage Firestore data without learning the Firebase Console, and small teams building internal tools on GCP [3][homepage].
• Critical constraint: This is not a general Airtable alternative. Rowy only works with Firestore. If your database is Postgres, MySQL, or anything outside the GCP ecosystem, stop reading here [2][3].
• Cost savings vs Airtable: Airtable Business runs $45/person/month. Rowy Pro is roughly $12/person/month, and the self-hosted community edition is free software (you still pay for GCP) [4][1].
• Key strength: Genuinely eliminates context-switching between Firebase Console, VS Code, and spreadsheets. Cloud Functions are written and deployed directly from the same UI where you manage data [3][homepage].
• Key weakness: The product appears to be mid-pivot toward a new product called BuildShip. The homepage now leads with “BuildShip: Visual Backend Builder, with AI” and the “Rowy 2.0” beta has been in signup limbo with no public release date [homepage]. That is a meaningful uncertainty signal for anyone betting their stack on it.

---

What is Rowy

Rowy is a browser-based admin panel for Google Firestore that looks like a spreadsheet and lets you write Cloud Functions in the same interface. The pitch from the GitHub README is: “Low-code backend platform. Manage database on spreadsheet-like UI and build cloud functions workflows in JS/TS, all in your browser.” [README].

The core value proposition is reducing the cognitive overhead of Firebase development. Normally, you’d manage data in the Firebase Console (a raw document viewer), write Cloud Functions in VS Code, and hand over read access to non-technical teammates with a prayer. Rowy collapses all three into one spreadsheet-style interface where you can sort, filter, and edit Firestore documents while also writing JavaScript/TypeScript functions that trigger on field changes — using any NPM package, no CLI required [3][homepage].

It sits at 6,802 GitHub stars [merged profile], which puts it in the “interesting project” tier rather than the “industry standard” tier. For comparison, NocoDB (a true Airtable alternative with PostgreSQL support) has cleared 50K+ stars. The difference partly reflects Rowy’s narrower audience — you have to already be a Firebase shop for this to be relevant.

The company behind Rowy also built BuildShip, a separate visual workflow builder that now takes up more homepage real estate than Rowy itself. Whether this represents a product evolution or a slow pivot away from Rowy is unclear, but the “Sign up for Rowy 2.0” beta CTA with no delivery timeline is not a confidence signal [homepage].

---

Why people choose it

The reviewers we found land consistently in the same place: Rowy wins for Firebase teams who want to give non-technical team members structured data access, and it loses the moment you step outside GCP.

The Firebase Console problem. The Firebase Console’s document editor is functional but hostile to non-engineers. Every Firestore document is displayed as nested JSON. Rowy maps those documents to spreadsheet rows, adds typed field controls (date pickers, image uploaders, single-select dropdowns), and layers in access controls so you can give a content editor write access to specific columns without giving them the keys to the entire project [3]. Medevel.com describes this as solving the “minimize context switching” problem — managing data and writing Cloud Functions without leaving the browser [3].

Cloud Functions in-browser. The integration between data editing and function writing is the differentiator that no other Airtable-style tool offers. You see a column change trigger a function, you edit that function in the same window, and the change deploys to your GCP project. AlternativeTo describes it as: “Build cloud functions workflows on field level data changes… Use any NPM modules or APIs” [1]. That is a materially different thing from Airtable’s automation blocks.

Comparison to NocoDB. NocoDB is probably the most common alternative that comes up. NocoDB supports PostgreSQL, MySQL, SQLite, and many other databases. It has more stars, a larger community, and broader database support. NocoDB wins on everything except one thing: it doesn’t have an in-browser Cloud Functions editor tied to your existing GCP infrastructure. If you’re already a Firebase shop and want to stay one, Rowy’s integration is tighter [4][6].

Comparison to Airtable. The NocoBase article [4] includes a direct cost comparison table. Rowy Pro is approximately $1,440/year for a 10-person team, versus Airtable Business at $5,400/year for the same team size — a 3.75× difference. But this comparison is somewhat apples-to-oranges: Airtable hosts your data and is a general-purpose tool; Rowy is a management UI that sits on top of your own Firestore instance [4].

---

Features

Based on the README, documentation, and third-party reviews:

Spreadsheet interface for Firestore:

• Full CRUD on Firestore collections [2][3]
• Bulk import and export via CSV, JSON, TSV [2][3]
• Sort, filter, lock, freeze, resize, hide, and rename columns [README]
• Multiple views for the same collection [README]
• Real-time data with auto-refresh [3]

Cloud Functions workflow builder:

• Write and deploy Cloud Functions directly in the browser, triggered by field-level data changes [3][README]
• Full NPM package access — no build step, no CLI [1][3]
• Pre-built extensions for SendGrid, Algolia, Twilio, BigQuery [README]
• Action field: a clickable button in the spreadsheet that calls any Cloud Function [3][README]
• Webhooks in and out (Typeform, SendGrid, or custom) [homepage]

Field types (30+):

• Basic: text, number, email, phone, URL
• UI pickers: date, checkbox, single select, multi-select
• Uploaders: image, file
• Rich editors: JSON, code, rich text, markdown
• Special: Aggregate (computed from sub-table), Connector (data from another collection), Connect Service (data from any HTTP endpoint), Derivative (auto-calculated on field update) [3][README]

Team and access controls:

• Granular table-level and field-level permissions
• Custom user roles with RBAC
• Built-in user management [3][README]
• Customizable views per role [3]

What’s not there:

• No support for any database outside Firestore. PostgreSQL, MySQL, SQLite — none of these work [2][3].
• No offline or air-gapped deployment. Rowy runs as a Cloud Run instance on your GCP project; you cannot run it on a $5 VPS [README].
• The AI features mentioned in the “Rowy 2.0” beta announcement are not publicly available as of this writing [homepage].

---

Pricing: SaaS vs self-hosted math

Rowy’s pricing:

• Free tier: limited functionality, community support [1]
• Pro: approximately $12/person/month (AlternativeTo cites “up to $12/month”; NocoBase’s comparison table shows $1,440/year for 10 people = $12/person/month) [1][4]
• Self-hosted community edition: free software, Apache 2.0 license, but you still pay Google Cloud Run and Firestore costs [2][3]

Important nuance on “self-hosted”: Rowy does not run on a generic Linux VPS. The self-hosted path is: deploy a Cloud Run container on your own GCP project. You own the data, Google doesn’t hand it to Rowy Inc., but you are still paying Google Cloud costs. The README’s deploy button points to rowy.app, which sets up the Cloud Run instance on your project [README]. This is meaningfully different from Activepieces or NocoDB, which you can run on a $6 Hetzner box.

Airtable comparison (10-person team, annual):

• Airtable Team: $2,400/year ($20/person/month)
• Airtable Business: $5,400/year ($45/person/month)
• Rowy Pro: $1,440/year
• Rowy self-hosted (community edition): GCP costs only — typically $10–40/month depending on Cloud Run usage and Firestore read/write volume [4]

The cost argument is real but needs context. Airtable hosts everything and is database-agnostic. Rowy requires you to already be paying for a Firebase project. For a team that’s already on Firebase, the incremental cost of Rowy Pro over the community edition is modest; the comparison to Airtable pricing only makes sense if you’re evaluating Rowy as a data management tool for a Firebase project you’d have anyway.

---

Deployment reality check

Getting Rowy running is not a standard Docker Compose situation. The deployment path is GCP-specific:

1. You need a Google Cloud project with Firestore enabled
2. Rowy deploys as a Cloud Run container on your GCP project using its guided installer at rowy.app
3. Firebase Authentication is used for user management — you don’t manage users in a separate auth system
4. Your data stays in your Firestore instance; Rowy only stores configuration [README][homepage]

The README explicitly states: “Your data and cloud functions stay on your own Firestore/GCP and is managed via a cloud run instance that operates exclusively on your GCP project. So we do not access or store any of your data on Rowy.” [README]. That is a genuine data sovereignty guarantee, not marketing copy.

What can go sideways:

• If you’re not already on Firebase, the setup requires creating a GCP project, enabling Firestore, setting up Firebase Authentication, and then deploying the Cloud Run instance. For someone who has never used GCP, this is a 4–6 hour process, not 30 minutes.
• Cloud Run costs money when it serves traffic. At low usage it’s effectively free (Google’s free tier covers 2M requests/month), but this is a cost vector that doesn’t exist with a self-hosted VPS.
• Firestore pricing is per-read/write/delete operation. A busy team using Rowy to manage large collections will see Firestore costs climb independently of any Rowy pricing.
• The “Rowy 2.0” banner and BuildShip pivot on the homepage raise a legitimate question about the project’s roadmap. If the core team is building BuildShip as the next thing, Rowy’s development velocity may slow. The last commit badge on the README points to the rc branch; the main repo’s activity should be checked before committing to this tool in a production workflow.

---

Pros and Cons

Pros

• Genuine Firebase integration. No comparable open-source tool bridges Firestore document management and Cloud Function authoring in one UI. For Firebase teams, this is a real time-saver [3][README].
• Apache 2.0 license. Free to self-host, fork, or embed. No commercial license required for the core [2][3].
• Your data never leaves your GCP project. The Rowy Cloud Run instance operates exclusively on your infrastructure — a stronger data sovereignty guarantee than most SaaS tools [README].
• 30+ typed field types including image uploaders, rich text, aggregate, and derivative fields that most spreadsheet-style tools don’t have [3][README].
• Non-technical team access without Firebase Console exposure. Content editors and PMs get a spreadsheet; engineers keep the Cloud Functions [homepage][3].
• Templates library for common workflows (Vision API + GPT, Figma data injection, Webflow forms to Firestore) [homepage].
• Field-level RBAC — granular enough to show one column to editors and hide it from viewers [3][README].

Cons

• Hard Firebase/Firestore lock-in. This is the defining constraint. If you’re not on Firebase, Rowy doesn’t exist for you [2][3]. This eliminates it as an Airtable alternative for the majority of teams.
• Not a traditional self-hosted deployment. You cannot run Rowy on a VPS. It requires GCP, Cloud Run, and Firestore. “Free self-hosted” means free software license, not free infrastructure [README].
• Unclear product trajectory. The BuildShip pivot and “Rowy 2.0 beta” signup with no delivery date are yellow flags for teams evaluating long-term tool bets [homepage]. Low GitHub star count (6,802) compared to alternatives suggests a smaller community to maintain it if the core team deprioritizes it.
• No SQL database support. Firestore is a document/NoSQL database. Teams that need relational data models, JOINs, or foreign keys will hit the ceiling quickly [2][3].
• GCP cost complexity. Cloud Run + Firestore costs add up in ways that a flat VPS bill doesn’t. A team actively using Rowy for bulk operations could see unexpected Firestore billing spikes.
• Limited third-party review coverage. We found no independent reviews from 2025 or 2026. The most detailed coverage is from medevel.com and a LinuxLinks listing — neither reflects hands-on testing of the current version [2][3].
• No confirmed REST API. The merged profile notes API import as a feature, but there is no documented public REST API for programmatic flow management comparable to what NocoDB or Baserow expose.

---

Who should use this / who shouldn’t

Use Rowy if:

• You’re already building on Firebase/Firestore and want to give non-technical teammates structured data access without teaching them the Firebase Console.
• You want to write Cloud Functions triggered by data changes without leaving the browser or setting up local development.
• You’re comfortable with GCP billing and already paying for Firestore.
• Your team is small enough that the community edition (free) covers your needs.

Skip it (use NocoDB instead) if:

• Your database is PostgreSQL, MySQL, SQLite, or anything outside Firestore.
• You want a true self-hosted Airtable alternative that runs on a $6 VPS with no cloud vendor dependency [4][6].
• You need a large community, active development, and a stable long-term roadmap — NocoDB has 50K+ stars and a clear product trajectory.

Skip it (use Airtable or Baserow instead) if:

• You don’t have a Firebase project and aren’t planning to build one.
• You need native views (calendar, gallery, kanban), forms, and automations that work out of the box — Airtable and Baserow both cover this without GCP setup.

Skip it (stay on Firebase Console) if:

• Your team is entirely technical. The Firebase Console is sufficient, and adding Rowy adds a dependency without clear benefit for an engineering-only team.

---

Alternatives worth considering

• NocoDB — the strongest open-source Airtable alternative for non-Firebase stacks. Supports PostgreSQL, MySQL, SQLite. 50K+ stars, actively developed, runs on any VPS. Pick this over Rowy unless you specifically need Firebase integration [4][6].
• Baserow — self-hosted, PostgreSQL-backed, clean UI, good for non-technical users. Premium plan is $1,200/year for a 10-person team [4].
• Teable — newer entrant, PostgreSQL-based, professional plan at $1,200/year for 10 people, simpler than Baserow [4].
• Airtable — the incumbent. Best UI, largest ecosystem, no self-hosting option, most expensive at scale ($5,400/year for 10-person Business plan) [4].
• NocoBase — the most unusual option. Not per-seat pricing: $800/year flat for any team size on the Standard plan. Plugin-based, developer-friendly, but steeper learning curve [4].
• Grist — open-source spreadsheet-database hybrid with Python formula support. Good for teams that want more power than Airtable without the per-seat pricing [6].
• BuildShip — Rowy Inc.’s own next product. Visual backend workflow builder, Firebase-adjacent, currently in beta. May be where the Rowy team’s attention is actually going [homepage].

---

Bottom line

Rowy is a genuinely useful tool for a specific audience: Firebase developers who need to give non-technical teammates structured Firestore access, combined with in-browser Cloud Functions authoring. For that audience, nothing open-source does it better. The Apache 2.0 license, data sovereignty guarantee, and field-level access controls are real strengths.

The problem is the audience is narrow, and the product signals are mixed. The homepage now leads with a different product (BuildShip), the promised Rowy 2.0 has no release date, and the GitHub star count suggests this never crossed into mainstream adoption. If you’re evaluating a long-term data management stack and you’re not already on Firebase, there are better-maintained alternatives with larger communities and no cloud vendor dependency. If you are on Firebase and want to eliminate the “non-technical teammates staring at JSON documents” problem, Rowy solves it cleanly.

---

Sources

1. AlternativeTo — Rowy listing (feature description, pricing context). https://alternativeto.net/software/rowy/about/
2. LinuxLinks — “rowy: low-code backend platform” (license, feature summary). https://www.linuxlinks.com/rowy-low-code-backend-platform/
3. Medevel.com — “Rowy is your open-source Airtable alternative” (detailed feature breakdown, deployment context). https://medevel.com/rowy-firestore-manager/
4. NocoBase Blog — “Is Airtable Too Expensive? 5 Self-Hosted Alternatives Compared” (pricing comparison table including Rowy Pro annual costs). https://www.nocobase.com/en/blog/5-self-hosted-airtable-alternatives
5. SaaSHub — “Rowy Alternatives & Competitors” (competitive landscape, positioning). https://www.saashub.com/rowy-alternatives

Primary sources:

• GitHub repository and README: https://github.com/rowyio/rowy (6,802 stars, Apache 2.0 license)
• Official website: https://www.rowy.io
• Live demo: https://demo.rowy.io
• Documentation: https://docs.rowy.io