Softwr

No-Code · head to head

Noloco vs Rowy

Noloco logo

Noloco

No-Code

Client portals and internal tools built over data you already have

From
On request
Rated
-
Rowy logo

Rowy

Spreadsheets

Spreadsheet interface for Google Cloud Firestore with cloud functions written in the browser

From
Free
Rated
-

The short version

  • Only Rowy has a free tier, so it costs nothing to try first.
  • Each has a real cost: Noloco pricing follows user counts, and a client portal is by definition many low-activity users, so an agency with a few hundred client logins climbs the bands quickly for people who sign in twice a month.; Rowy every Firestore limit is inherited, including the one megabyte per document ceiling and roughly one sustained write per second per document, which surprises users who expect spreadsheet behaviour.
  • They diverge on capability: Noloco covers Row-level permissions, Rowy covers Firestore backed grid.
  • Prices and features above were last checked on 31 August 2026.

Where they differ

Only the attributes on which Noloco and Rowy actually diverge.

Attributes where Noloco and Rowy differ
AttributeNolocoRowy
Starting priceOn requestFree
Pricing modelquoteOpen source, no licence fee
Free tierNoYes
CategoryNo-CodeSpreadsheets

Identical on both: platforms (Web), user rating (Not yet rated).

What each one covers

Drawn from each product's published feature list. An absence here means we hold no record of it - not that the product lacks it.

Only in Noloco

  • Row-level permissions
  • Multiple data sources
  • Client portals
  • Workflows
  • Forms and record detail pages
  • White labelling

Only in Rowy

  • Firestore backed grid
  • Browser authored cloud functions
  • Typed columns
  • Runs in your Google Cloud project
  • Role based access
  • Form view
  • Open source

What people use each for

The jobs each tool is most often brought in to do.

Noloco

  • Giving clients a branded portal onto their own records in an Airtable basenot Rowy
  • Replacing shared spreadsheets with a permissioned internal tool for an operations teamnot Rowy
  • A lightweight CRM over a PostgreSQL database that already existsnot Rowy
  • Partner or contractor dashboards where each party must see only its own jobs and documentsnot Rowy

Rowy

  • A Firebase application that needs an internal admin interface without building onenot Noloco
  • Operations staff correcting production records in Firestore without developer involvementnot Noloco
  • Attaching a small transformation or notification function to a field change without a full deployment pipelinenot Noloco
  • A content team populating documents that a mobile application reads directly from Firestorenot Noloco

Where each one falls short

Documented limitations, not opinions. Every one is a constraint you would hit in normal use.

Noloco

  • Pricing follows user counts, and a client portal is by definition many low-activity users, so an agency with a few hundred client logins climbs the bands quickly for people who sign in twice a month.
  • Limits are inherited from the data source. Airtable record ceilings, API rate limits and slow queries appear in the portal your customers use, and no setting inside Noloco can fix them.
  • Design control is deliberately narrow. You get a consistent application shell rather than a bespoke interface, which is fine for operations and a problem for anything marketing-led.
  • It is a small vendor competing directly with Airtable Interfaces and Softr, both far larger, so roadmap pace and long-term viability are legitimate procurement questions.
  • Output is responsive web only, with no native mobile application and no offline mode, so field staff on poor connections are not served by it.

Rowy

  • Every Firestore limit is inherited, including the one megabyte per document ceiling and roughly one sustained write per second per document, which surprises users who expect spreadsheet behaviour.
  • Firestore has no joins, so linking tables in the grid is a convenience layer rather than a relational feature and reports across collections still need a separate query.
  • It is useful only to teams already on Firebase, so choosing it effectively locks the operational tooling to one cloud vendor.
  • Query costs are billed by document read, and an unfiltered grid on a large collection can generate a bill that a spreadsheet user has no intuition for.
  • Development activity has slowed relative to the broader category, so evaluate current maintenance before making it load bearing for internal operations.

Pricing, plan by plan

Noloco

On request
  • Noloco$undefined/year
    • Tiered plans differentiated by user counts, data sources and white labelling
    • Trial period rather than a permanent free plan
    • Higher tiers add custom domains, advanced permissions and priority support

Rowy

Free
  • Open source self hostedFree
    • No licence fee
    • Deploys into your own Google Cloud project
    • You pay Google Cloud for Firestore reads, writes and storage

Which should you pick?

Choose Noloco if

  • You need row-level permissions.
  • You also want multiple data sources.

Choose Rowy if

  • You need firestore backed grid.
  • You want to start without paying.
  • You also want browser authored cloud functions.

Questions people ask

Is Noloco or Rowy better?
Neither clearly leads. Noloco starts at On request and Rowy at Free, and user ratings are close enough to be indistinguishable. Choose on capability and platform support.
Which is cheaper, Noloco or Rowy?
Rowy has a free tier; the other does not. Paid plans start at On request for Noloco and Free for Rowy.
Does Noloco or Rowy run on more platforms?
Both run on Web, so platform support will not decide this one for you.
Can I use Rowy for free?
Yes. Rowy has a free tier, so you can try it without paying. Noloco starts at On request.
What is Noloco best used for?
Noloco is most often used for giving clients a branded portal onto their own records in an airtable base, replacing shared spreadsheets with a permissioned internal tool for an operations team, a lightweight crm over a postgresql database that already exists, partner or contractor dashboards where each party must see only its own jobs and documents. Of those, giving clients a branded portal onto their own records in an airtable base and replacing shared spreadsheets with a permissioned internal tool for an operations team are not what Rowy is typically brought in for.
What can Noloco do that Rowy cannot?
Noloco covers Row-level permissions, Multiple data sources, Client portals, Workflows. Rowy covers Firestore backed grid, Browser authored cloud functions, Typed columns, Runs in your Google Cloud project.

Answered from the vendors’ own pages

Noloco: Do I need Airtable to use it?

No. Airtable is the most common source but PostgreSQL, MySQL, Google Sheets, HubSpot and built-in Noloco tables all work.

Rowy: Where is my data stored?

In your own Firestore instance inside your own Google Cloud project. Rowy does not hold a copy.

Noloco: Can external clients log in without paying for seats?

Client and internal users are counted differently, but they are still counted, so a portal with many client logins moves you up the plan bands. Check the current band definitions before committing to a per-client model.

Rowy: What does it cost to run?

No licence fee. You pay Google Cloud for Firestore reads, writes, storage and function invocations, and an open grid on a big collection reads a lot.

Noloco: How is this different from Softr?

Both build portals over existing data. Noloco leans harder on permissions and multiple database sources; Softr leans on templates, speed to a first version and a bigger ecosystem.

Rowy: Can it do joins across collections?

Not really. Firestore does not support joins, and no interface layer can add them.

Rowy: Is there a row limit?

Not from Rowy. The limits that bite are Firestore document size and per document write throughput.

Rowy: Is it suitable if I am not on Firebase?

No. It is specifically a Firestore interface.

Share

Related pages

Other head to heads