What MatterData is
MatterData turns a declarative model into a working web application. You describe the data, the pages, the rules, and who may see what. One shared engine reads that description and serves it.
The idea comes from Oracle APEX: an app author describes intent, and a shared runtime provides the repetitive and security-sensitive machinery. MatterData rebuilds that idea on a small stack that one organization can afford to run.
What you can build
Section titled “What you can build”Data-heavy applications for small organizations: membership administration, event registration, editorial workflows, public calendars, and school records.
These are the applications that a spreadsheet outgrows and that custom software prices out of reach.
What you write
Section titled “What you write”An application is a directory of .mtd files, plus TypeScript files for logic the model cannot
express. You can declare:
- tables, column types, relationships, constraints, and computed values.
- pages built from reports, lists, records, forms, editable tables, statistics, and crosstabs.
- routes, navigation, roles, row-level rules, and per-role column grants.
- lifecycle states and the moves between them.
- image fields, CSV files, and calendar feeds.
- hooks that run in a sandbox, inside the write’s own transaction.
The compiler checks the whole model before it reaches the runtime. An error names the file, the line, the column, and a repair.
What you do not write
Section titled “What you do not write”These belong to the engine, and every application gets them:
| Authentication | Passwords hashed with argon2id, lockout, and rate limits |
| Authorization | Row rules applied inside the query, never after it |
| Forms | Validation, error messages, and the submitted text after a rejection |
| Safe SQL | Always parameterized. A name from a request goes through an allowlist. |
| CSRF | A token on every form that changes data |
| Accessibility | Server-rendered HTML that works with JavaScript turned off |
A fix in the engine is a fix for every application at once. This is the reason the platform owns these parts instead of each app repeating them.
How it runs
Section titled “How it runs”One Go binary serves every installed application. Each organization gets its own SQLite file, so tenant data is isolated and portable. Uploaded images live in a directory beside that file.
A backup is therefore two things: the database file and the image directory. An organization that resets itself every night has a third: the stored template it returns to, which is a database file and an image directory of its own.
The four example applications
Section titled “The four example applications”The repository carries four applications that the engine is developed against:
| Application | What it covers |
|---|---|
| Sports club | Members, fees, events, public signups, images, CSV export |
| Local newspaper | Editorial states, Markdown articles, comments, media, hooks |
| School | App-wide scope, sensitive columns, derived grades, nested routes, crosstabs |
| Municipal calendar | Anonymous submissions, repeating events, calendar subscriptions |
These are test fixtures rather than products you can install. They are the most complete examples of the language, and reading them is the fastest way to see what a real app looks like.
Where the project stands
Section titled “Where the project stands”MatterData is in its engine phase. The compiler and most of the runtime work against those four applications. The deployment commands and production operations are not finished.
Read Project status before you put real data into it, and How MatterData works for the division between the compiler and the runtime.