Almost every useful automation needs somewhere to keep things: order numbers already processed, customer lists, a queue of pending work, execution records.
Most people reach for Google Sheets first, and at the start it is completely sufficient. This article is about when it stops being sufficient, and what you gain once you replace it.
The 30-second overview
| Item | Details |
|---|---|
| What it solves | An automation needs somewhere to keep state |
| Better than Sheets how | Typed fields, your own API quota, webhooks |
| The key point | Two-way: a data change can trigger a workflow in return |
| Combined avg. monthly cost | About NT$998 |
| When not to switch | Few workflows, little data, and only you using it |
Where Google Sheets starts to jam
1. Concurrent writes collide. When two workflows both try to write to the last row at the same time, it is easy for one to overwrite the other. The problem does not appear when you have few workflows, but once five or six share the same sheet you will start hitting it, and the symptom is data that goes missing "occasionally", which is the hardest kind to track down.
2. The API has quotas. The Sheets API has a per-minute request limit. Usually that is fine, but the moment a workflow has to process a few hundred records at once you hit it, and the workflow fails.
3. There are no types. The leading 0 in a phone number gets eaten, dates are auto-converted into a different format, long numbers turn into scientific notation. These are the default behaviors of a spreadsheet, not bugs, but they hand your automation the wrong values.
4. You cannot find anything. Past a few thousand rows, finding one specific record becomes painful, because a spreadsheet has no real concept of a filtered view.
What changes once you move to NocoDB
NocoDB sits on a real database underneath, and that brings several direct changes:
- Fields have types. A date is a date, a number is a number, and nothing gets reformatted behind your back.
- The API is designed for programs. Every table automatically gets a REST API, and it is your own instance, so there is no shared quota problem.
- There are webhooks. This is the key part: a data change can trigger n8n in return, instead of n8n only writing one way.
- Multiple views. One dataset, and you look at a grid, a colleague looks at a kanban board, and your manager looks at a calendar, with no one copying it separately.
Two-way is the real point
If you only write to it from n8n, the difference between NocoDB and Sheets is not big enough. The real difference is that a data change can trigger a workflow.
That lets a person step into the middle of an automation:
| Step | Who does it |
|---|---|
| Pick up a new inquiry | n8n |
| Write it into NocoDB with status "pending review" | n8n |
| Take a look and change the status to "approved" | A person |
| The status change fires a webhook | NocoDB |
| Send the quote, create the calendar entry, notify sales | n8n |
The biggest problem with pure automation is that there is nowhere for a person to intervene. Either everything is automatic (and then something goes wrong), or everything is manual. This combination gives you a middle state: the machine gets it ready, a person clicks once, the machine carries on.
When you do not need to switch
Let us be honest. In the following situations Google Sheets is enough and switching is a waste of money:
- Only one or two workflows, and they never run at the same time
- A dataset of a few hundred rows at most
- You are the only one looking at it
- You need spreadsheet formulas and pivot tables (NocoDB is not designed for that)
The turning point usually arrives when you start seeing data go missing "occasionally", or when you have so many workflows that you cannot keep track of which one writes to which sheet.
n8n averages NT$499/mo (billed yearly) and NocoDB is NT$499/mo, so together they come to about NT$998/mo on average. Compare that number against "how long it takes to track down one data error", not against the fact that Sheets is free.
A real workflow
Take handling inquiries as the example, and look at how the two tools split the work:
| Step | Who does it |
|---|---|
| The website form is submitted and fires a webhook | n8n |
| Clean up the fields, check whether this is an existing customer | n8n |
| Write it into NocoDB with status "pending review" | n8n |
| Take a look, change it to "approved" | A person |
| The status change fires a webhook | NocoDB |
| Send the quote email, create the calendar entry, notify sales | n8n |
Step four is the key one. A fully automatic workflow has nowhere for a person to hit the brakes, and most businesses want someone to take a look before a quote goes out.
FAQ
Q: What exactly is not enough about Google Sheets?
Four things: concurrent writes overwrite each other, the API has quota limits, there are no field types (the leading 0 in a phone number gets eaten), and people cannot find anything once there is a lot of data. With few workflows you hit none of them; with five or six workflows sharing one sheet you hit all of them.
Q: Do I have to buy both?
Not necessarily. Running n8n with Sheets works perfectly well, and plenty of people do it for a long time. The time to switch is when those four symptoms start showing up.
Q: What are webhooks actually good for?
They let a person step into the middle of an automation. The machine prepares the data and marks it pending review, a person takes a look and changes the status, and the status change triggers the next actions. The biggest problem with pure automation is that there is nowhere for a person to intervene, and this combination gives you a middle state.
Q: Will it slow down with a lot of data?
NocoDB runs on a real database underneath, so it handles volume far better than a spreadsheet. What to watch is live cross-table rollups, which become noticeable when the number of linked records is large. The approach is covered in the formulas and links tutorial.
Q: Can it connect to my existing database?
NocoDB supports connecting to an existing database, so you do not necessarily have to move the data in. That is especially useful when you already have a system and just want a usable interface on top of it.
Start with a single table
Our advice is not to design the complete data structure up front. First let one workflow write into one table, and live with it for two weeks.
You will quickly find that the fields you actually need are not the ones you imagined: some get set up and nobody fills them in, and others have to be filled in by hand every time. Those observations are far more accurate than planning ahead.
Once the structure settles, add links, views, and webhook triggers. A system where the full architecture is drawn before rollout usually produces something beautiful that nobody uses.
Sources and further links
n8n's nodes and pricing change often. These are the primary sources for checking:
- n8n official documentation
- n8n official pricing — cloud plans and quotas
- n8n source code and release notes — the authoritative source for license terms
Further reading
- NocoDB tutorial: creating your first table and view
- NocoDB API quick start: getting a token, reading and writing tables, connecting automations
- n8n webhooks and third-party integration guide
- Using NocoDB as a CRM: when it is enough and when to move on
- What is n8n? A complete introduction to the workflow automation platform
- RoamerHost NocoDB hosting plans
- RoamerHost n8n hosting plans
Want someone to build it for you?
If you would rather not assemble these workflows yourself, or the project is large enough that you want someone planning it with you, Roamer Tech (the company behind RoamerHost) takes on contract work for business process automation and AI agents:
