NocoBase is an open-source, self-hosted platform for building business applications without writing code, and its design is data-model driven. Collections hold the relational data, blocks render that data as screens, and actions trigger operations against it; mastering how these three concepts interlock is what turns a blank NocoBase instance into a working application. This article walks through that layering using two concrete reference projects — a task management system and an application catalog — so first-time builders can see exactly where data ends and where the UI begins. It also explains why business data lives in plain relational tables rather than a proprietary format, and what that means for lock-in. The scope is intentionally narrow: this is a guide to shaping data and turning it into screens in NocoBase, not a comparison with PocketBase or a workflow-engine tutorial.
NocoBase is built around a single organizing idea that the official Getting Started tutorial states as one of the platform's five core principles: it is data model driven. The workflow it prescribes is strict and sequential:
The key consequence is that UI and data are fully decoupled. The interface layer sits on top of the data model rather than the other way around, which means a builder designs the schema before deciding how records will be presented or operated on.
In many no-code platforms the schema is implicit: a form is built, fields are dragged onto it, and a database table is generated in the background as a byproduct of UI choices. NocoBase inverts that order. Collections, their fields, and their relationships are declared explicitly through a visual schema designer before any screen exists. Non-technical users can still build without writing SQL, while developers retain full visibility into the resulting structure.
This ordering has practical implications:
Because business data lives in standard relational structures — NocoBase supports MySQL, PostgreSQL, and MariaDB — it stays separate from any UI definition. A database created or modified by NocoBase is a normal relational database that can be queried, backed up, or migrated with ordinary tooling. The interface layer, by contrast, is described as a thin overlay. This is the architectural reason the project advertises no platform lock-in: removing NocoBase does not strand the data in a proprietary format.
The data-model-first principle is presented as a foundational design choice and has been consistent across the 2.x line at the time of writing. Because it is documented as a core principle rather than a feature flag, it is unlikely to change between minor releases, but it is still worth re-checking the current Getting Started tutorial before relying on the wording in production documentation.
A collection is NocoBase's name for a table. It is the foundational data structure on top of which every page, block, and action is later built, as the official task-management tutorial explicitly states (NocoBase Tutorial: Task Management System). Collections and their fields are created visually through the Data Source Manager plugin; the underlying database tables are generated automatically, so no SQL is required (Building an Application Catalog with NocoBase). Because NocoBase runs on PostgreSQL (with MySQL also supported), what you create as a collection is, under the hood, a regular relational table (NocoBase as a CRM — review, capabilities, and limitations).
Following the official tutorial, the reference task-management app is built from three collections (NocoBase Tutorial: Task Management System):
title (Text), status (Select), owner (Relation → Users), due_date (Datetime).name (Text), role (Select), plus the implicit identity fields NocoBase manages for you.body (Text), author (Relation → Users), and an implicit link back to the Task it belongs to.When you add a field, NocoBase asks you to choose a type. The catalog reported in practice covers (NocoBase as a CRM — review, capabilities, and limitations):
due_date, timestamps, calendar blocks.status or role.A complete and authoritative list lives on the NocoBase plugins page; expect it to expand as new plugins are released.
Connections between collections are modeled with Relationship Fields, and the system supports one-to-one, one-to-many, and many-to-many (NocoBase as a CRM — review, capabilities, and limitations). For many-to-many links, NocoBase creates the junction table automatically — you never manage it manually (NocoBase as a CRM — review, capabilities, and limitations). Two concrete cases in the task-management example:
Reach for a Relation field whenever two collections must reference each other; reach for JSON only when the data is genuinely unstructured, since relation fields are reusable across permissions, blocks, and workflows (Business Application Development with NocoBase).
Blocks are the data-display units that turn a collection's records into something a person can actually see and edit on a page. In NocoBase, every block is bound to exactly one collection, so the choice of block type is essentially the choice of how those records should be rendered.
NocoBase ships with a set of built-in blocks, and additional ones arrive through plugins:
The exact set of supported blocks shifts between releases — for example, the 2.0-beta compatibility list marks Calendar, Gantt, and Kanban as not supported at that point, while the current stable line treats them as available (Gantt through a plugin). Always confirm against the current plugin and docs pages before assuming a block exists.
The Architecture Portal case study, documented on the NocoBase blog (Building an Application Catalog with NocoBase), illustrates this pattern clearly. The portal models an Applications collection with id, name, description, stack, owner, created_at, and last_updated fields, plus a Reminders collection (id, application_id, type, description, scheduled_date, status) linked back through an application_id relation field. Once those collections exist, the screens compose themselves:
Applications collection automatically.Applications, visualizes indicators such as the number of applications grouped by stack.Creating any of these is a two-step operation: pick the block type, then pick the collection it should bind to. The component then appears, and its per-block settings — columns to show, indicators, grouping, filters, validation — are tuned from there.
Because every block is generated from a collection and then configured individually, NocoBase gives you one-page-per-collection-style CRUD essentially for free: drop a Table and a Form on the page and you have a working list-and-detail screen. The cost is that no view comes pre-shaped for a particular business object — every column, every filter, every chart dimension is something you assemble yourself. That is the inherent trade-off of a database builder compared to a purpose-built application: total control over data shape, in exchange for explicit view configuration work.
In NocoBase, an action is the operation layer that sits between a block and the underlying collection. Every read, create, update, or delete performed by a user is implemented as an action rather than as a hard-coded button handler. Actions are one of the platform's three core concepts alongside collections (data) and blocks (display), and they are what turn a passive screen into a working application (NocoBase Task Management System Tutorial).
An action is defined once against a block or its bound collection, and then exposed wherever it makes sense in the UI. The same Edit action, for instance, can appear as a toolbar button at the top of a table, as a row-level menu item, and as a bulk operation that runs against many rows simultaneously — without any re-implementation. In the task-management reference project, this means:
Because actions are decoupled from their trigger surfaces, repositioning controls, adding context menus, or rebuilding a block does not require redefining the underlying operation.
NocoBase's role-based access control already operates at three levels — collection, record, and field — so each action naturally inherits the visibility and edit rights of the data it touches (NocoBase as a CRM review). On top of that, action-level permissions were introduced in the March 7, 2025 weekly update, allowing administrators to decide which roles may invoke a specific Create, Update, Delete, or custom action independently of broader collection rules (NocoBase weekly news).
When the built-in CRUD verbs are not enough, custom actions can be registered through plugins. This is the bridge from no-code CRUD to domain-specific operations such as the comment-posting behavior in the task app, and it is also where teams start shaping NocoBase toward their own business logic.
Workflow triggers and nodes — including the Post-Action Event that fires after an action runs — are a separate layer of the platform and are intentionally out of scope here. For a complete walkthrough of wiring these actions into a working Tasks screen, the official NocoBase Task Management System Tutorial covers the step-by-step setup, and the Getting Started chapter explains how actions and blocks are edited together in the UI.
Every collection in NocoBase maps directly to a table in a conventional relational database. The platform's primary store is PostgreSQL, with MySQL and MariaDB also supported as main data sources depending on the edition (docs.nocobase.com; nocobase.com commercial page). There is no parallel document store, no proprietary binary format, and no hidden JSON document that the UI happens to render. The relational table is the collection.
This is a deliberate architectural choice rather than an implementation detail. Business data stays in standard relational structures that are separate from the UI layer (nocobase.com; github.com/nocobase/nocobase). The interface can be redesigned, screens can be removed, and plugins can be uninstalled — none of these actions have to touch the rows themselves.
Because the tables are ordinary Postgres or MySQL tables, the builder keeps full control with standard tooling:
pg_dump, mysqldump, or filesystem-level snapshots).This contrasts with hosted no-code platforms, where business data typically lives behind a vendor API and a CSV/JSON export is the only way out.
Returning to the application-catalog reference project, this design pays off concretely. Once the Applications and Reminders collections have been created, a builder can write a single SQL query that joins the two tables — for example, listing every application together with its most recent reminder — without writing a custom block, a workflow trigger, or an API integration. The same query also feeds a BI dashboard directly.
When fields are added through the Data Source Manager, NocoBase generates the underlying CREATE TABLE and ALTER TABLE statements automatically, so no manual SQL is needed for typical modeling (dench.com review). The result, however, is a normal Postgres or MySQL schema that can be opened, inspected, and edited with any standard client.
Supported databases and plugin availability shift between releases and between Community, Standard, Professional, and Enterprise editions. The current edition matrix should be re-checked against the latest release notes before committing to a particular database engine for a production deployment.
The lock-in question for any no-code platform splits into two layers: the data and the interface. In NocoBase those layers are separated, and they behave very differently when you decide to leave.
Data and schema: low lock-in. NocoBase is released under the AGPL-3.0 license and the core platform is self-hosted, so the application and its database both live on infrastructure you control. Business data is stored in standard relational structures — PostgreSQL is the primary engine, with MySQL also supported — rather than in a proprietary document store. Because of this, the schema can be inspected, queried, and backed up directly with any standard database client, without going through the NocoBase UI. Migrating rows to another system is a conventional ETL exercise, not an export from a closed vendor cloud. (NocoBase on GitHub, dench.com CRM review)
UI configuration: meaningful lock-in. The same separation works against you above the database layer. Block layouts, action wiring, link rules between collections, and permission policies are stored in NocoBase's own metadata tables. That metadata is not interchangeable with another tool — a kanban view configured against a Tasks collection, or an action that opens a drawer to create a related record, has to be reimplemented elsewhere. You can rebuild a competitor's data model in an afternoon; rebuilding a configured screen is closer to a small project.
A few constraints are worth knowing before you commit to a from-scratch design:
For a first build, treat the task management system and the application catalog referenced throughout this article as working templates rather than as blank slates. Cloning one of them gives you a known-good collection layout, a set of already-wired blocks, and a permission scheme you can adapt. Designing a fully domain-specific schema from zero is reasonable once you have a concrete data model in mind; doing it on day one is the most common way first-time builders stall.