CheqqThe Cheqq alternative to NocoDB
A spreadsheet UI over your database is the beginning.
NocoDB does something genuinely useful: it puts a usable front end on a database you already own. Cheqq starts there and keeps going — columns that fill themselves, workflows that act on the rows, apps on the open web and documents out the other end.
What NocoDB is forAn open-source no-code interface for databases you control. NocoDB's real value is that it connects to your existing Postgres or MySQL, runs on your own infrastructure, and never takes custody of your data.
A hosted workspace where the records are one part of a system. Collections, deterministic automations, published apps with enforced permissions, real document output, and an agent that builds all of it from description.
Why people start looking
Nothing here is a knock on NocoDB. These are the points at which one product stops being the right shape for the job, whichever product it is.
A view is not a system
Once the rows are visible, the work is still whatever has to happen to them — the chasing, the categorising, the reporting. A grid does not do any of that.
The thinking columns stay empty
Classification, research, judgement calls. The kind of column that cannot be a formula, and so ends up being a person.
You are also running it
Self-hosting is a feature until it is a Tuesday evening. Upgrades, backups, uptime and the connection pool become yours to think about.
Sharing means building a front end
Letting a customer see their own row usually turns into a small app somebody has to write, deploy and then maintain.
Cheqq vs NocoDB
Row by row, in plain terms. Where NocoDB is the stronger answer, the row says so.
NocoDBIn your workspace on Cheqq's infrastructure, isolated per workspace, exportable as CSV or XLSX whenever you want.
In a database you already own and administer, on hardware you choose. If data custody is the requirement, that is decisive.
Hosted only.
Open source, self-hostable, with an active community.
Import CSV or XLSX into collections, or read and write an external system through an integration or its API from any workflow step.
Connects directly to an existing Postgres or MySQL schema and edits it in place — the core of what it is for.
Give a column a job and it runs on every row, with web sources attached, a price quoted before it runs, and manual edits protected.
Formulas and links; the thinking columns stay manual.
Six trigger types, branching, loops, sandboxed code, retries and human approval steps with escalation, with full run history.
Webhooks and scripts you wire up yourself.
Published apps at their own address with server-enforced field permissions, plus real .pptx, .xlsx, .docx and .pdf built from the records and editable in the workspace.
Shared views and forms over the base.
Describe the system; it compiles into tables, workflows and screens you can read and change by asking.
You design the schema and the interface yourself.
Based on each product's publicly documented capabilities. Both move fast — if something here is out of date, tell us and we will fix it.
What you would build instead
Not features to evaluate — sentences you could type on your first afternoon, and what comes back.
Let the rows act on themselves.
The reason the data is there is that something is supposed to happen to it. Describe that, and it runs on a schedule, on a webhook, or the moment a record changes — the same way every time.
Publish a page instead of writing one.
The customer-facing view you were about to build as a small app. Live at its own address, reading real records, restricted to the fields you list — and rolled back in a click if it was wrong.
When to stay with NocoDB
We would rather you picked the right tool than picked ours. These are the cases where NocoDB is the better answer.
- The data must stay on your infrastructureRegulatory, contractual or philosophical — if it cannot leave your servers, NocoDB is the right answer and Cheqq is not.
- You have a Postgres schema alreadyPointing a UI at tables your application already writes to, without moving or copying anything, is precisely NocoDB's job.
- Open source matters to youBeing able to read the code, fork it and run it forever is a real guarantee. Cheqq does not offer that.
- You want zero per-seat costSelf-hosted and open source has a cost shape that hosted software cannot match if you are happy to operate it.
Moving across, gradually
You do not have to switch in one go — most people run both for a while and let the NocoDB side shrink.
Bring a table over, or leave it where it is
Import CSV to make it a collection, or keep the database where it is and have a Cheqq workflow read and write it through its API.
Add the columns that were always manual
Describe what the column should contain and it fills the backlog of rows as well as the new ones, showing its sources.
Turn the scripts into workflows
The cron jobs and webhook handlers around your base become readable steps with retries, approvals and a run history.
Switching from NocoDB
Can Cheqq connect to my existing Postgres like NocoDB does?
Not as a native in-place editor — Cheqq's collections are its own store. What you can do is read from and write to an external database or service from any workflow step via its API or an MCP server, which covers keeping the two in step.
Is Cheqq open source?
No. If running the code yourself is a requirement, NocoDB is the better fit and we would rather say so than talk you round it.
Can I get my data out?
Yes, at any time — CSV or XLSX export on any collection, and the API for anything programmatic. Published apps only ever expose the fields you list.
What replaces my cron jobs and scripts?
Workflows. Six trigger types including schedules and webhooks, with branching, loops and sandboxed code where you genuinely need code — plus retries, approval gates and a full event history per run.
Comparing something else?
vs SmartSuite
vs Teable
vs Excel
vs Google SheetsPast the grid, into the system
Import one table and describe what should happen to its rows. Free to start, no card.
Start free