data-ui

Competitive Landscape

How Data UI compares to existing tools for building database-backed, RBAC-protected applications.

The Gap in the Market

Existing tools occupy points along a spectrum — from raw frameworks (Rails, Django) to low-code platforms (Directus, Budibase) to AI code generators (Bolt.new, v0). Each addresses a slice of the problem: scaffolding CRUD, or wrapping a database with an API, or generating frontend code from a prompt. But none covers the full distance from data model to deployed, secured, multi-user application.

The gaps are not at the margins. They are structural:

Data UI is not a better version of these tools. It is a different category: a compiler that takes a small declarative model and produces a complete, running application — database schema, RBAC enforcement, REST API, React frontend, validation hooks compiled to native code, and one-command deployment to TLS at the model’s own domain. The model is the application. The compiler guarantees consistency across the entire expansion. There is no second system to configure, no separate deploy pipeline to operate, no imperative code that drifts from the spec.

The Three Differentiators

1. One-click deploy to TLS at a model-specified domain

The model declares its own domain:

(:domain "todo.demo.data-ui.com")

One command — scripts/data-ui deploy — compiles the model, builds a Docker image, renders Kubernetes manifests, provisions PostgreSQL with persistent volumes, obtains and renews a Let’s Encrypt TLS certificate via DNS-01, configures HAProxy routing, and brings the application live at the specified domain. All derived from the model. All deterministic and repeatable.

Nobody else does this. The entire industry treats “build the app” and “deploy the app with TLS to your domain” as separate problems solved by separate tools:

Data UI collapses build and deploy into one model. The 30-second demo isn’t “here’s a running dev server” — it’s “here’s a live, TLS-secured, publicly accessible application.”

2. Native compilation — the compiled model is executable machine code

Data UI runs on SBCL (Steel Bank Common Lisp), which compiles to native machine code. The compiler’s output — *compiled-model* — is not just a data structure describing the application. It is a live, executable artifact containing:

All in one structure. No interpreter. No VM. No JIT warmup. The generic backend functions (be-list, be-insert, be-update, etc.) are compiled function calls, not interpreted scripts. When a validation hook runs, it calls a function pointer to native code that was placed in the compiled model at compile time.

Every comparable tool runs on an interpreter or managed runtime:

Data UI’s deployment footprint is a single native process plus PostgreSQL. No Node.js runtime, no Python interpreter, no JVM, no Redis, no separate WSGI server. The performance ceiling is higher and the operational surface is smaller.

3. The model is an API for a non-human consumer

Data UI’s model format is explicitly designed for AI consumption. An AI does not write arbitrary code into a Data UI application — it selects from a defined vocabulary (the hook registry) and fills parameters, exactly as it fills a function call. The compiler guarantees the result is consistent.

This is structurally different from every other approach:

Data UI is the only system where an AI can produce a small, structured model and the compiler expands it into a complete, consistent, deployed application — database, API, RBAC, frontend, TLS, domain — with no code generation and no drift.

Feature Comparison

Capability Data UI Frappe Directus PocketBase Hasura Supabase Bolt/v0
DB schema from model ✅ ✅ ✅¹ ✅ ❌² ✅ ❌
Auto-generated REST API ✅ ✅ ✅ ✅ ✅³ ✅ ❌
Auto-generated frontend UI ✅ ✅⁴ ✅⁴ ✅⁴ ❌ ❌ ✅
RBAC from model ✅ ✅ ❌⁵ ❌ ❌⁵ ❌⁶ ❌
Field-level scoping ✅ ❌ ✅ ❌ ✅ ✅⁶ ❌
Deploy to TLS at model’s domain ✅ ❌ ❌ ❌ ❌ ❌ ❌
Native machine code ✅ ❌ ❌ ✅⁷ ❌ ❌ ❌
Model fits in an email ✅ ❌ ❌ ❌ ✅ ❌ N/A
AI-consumable model format ✅ ❌ ❌ ❌ ✅ ❌ N/A⁸
Structured hook vocabulary ✅ ❌ ❌ ❌ ❌ ❌ ❌
Interactive development (REPL) ✅ ❌ ❌ ❌ ❌ ❌ ❌

¹ Directus wraps an existing database; it does not compile one from a model. ² Hasura connects to an existing database. ³ GraphQL, not REST. ⁴ Admin panel only, not a custom application frontend. ⁵ Permissions must be configured separately from the data model. ⁶ Via PostgreSQL Row Level Security (manual SQL policies). ⁷ Go compiles to native code, but PocketBase has no REPL, no interactive development, and no homoiconicity. ⁸ These tools consume natural language prompts, not structured models. Output is imperative code, not a reproducible specification.

The Closest Competitors

Frappe Framework

The closest philosophical cousin. Frappe is metadata-driven: DocTypes (JSON) define models, views, and permissions, and the framework generates database tables, REST APIs, and admin UI from them. It powers ERPNext, a full ERP system.

Where Data UI pulls ahead:

Directus

The strongest RBAC offering in the market. Directus wraps any SQL database and auto-generates REST/GraphQL APIs, an admin studio, and granular permissions (collection-level, field-level, item-level with dynamic filters, hierarchical role inheritance).

Where Data UI pulls ahead:

PocketBase

The best “whole app in a file” in the market. A single Go binary with embedded SQLite, REST API, auth, admin dashboard, and file storage.

Where Data UI pulls ahead:

AI Code Generators (Bolt.new, v0, Lovable, Replit Agent)

These tools generate full-stack applications from natural language prompts. They are impressive demos but fundamentally different from Data UI.

Where Data UI pulls ahead:

The Practical Result

The three differentiators are not independent features. They compound. A model that compiles to native code, carries its own deployment configuration, and is designed for AI consumption means something specific in practice:

You can build and deploy a real application in minutes, not days. Starting from an existing model, a few minutes to tweak, test, and deploy. Starting from scratch, perhaps 30 minutes. Either way, the result is not a dev server or a sandbox preview — it is a live, TLS-secured, publicly accessible application at its own domain, backed by PostgreSQL, with full RBAC enforcement, a REST API, and a React frontend, all from a single model file that fits in an email.

No comparable tool can make this claim. Consider what it takes to deploy a Frappe application: install the bench CLI, provision a server, install Python, MariaDB, Redis, nginx, supervisor, configure each service, run bench new-site, set up DNS, obtain TLS certificates, configure nginx vhosts, and start the supervisor processes. The setup alone is a multi-hour exercise, and that is before you have written a single DocType.

The gap is not incremental. It is categorical. When the model is the application — schema, logic, permissions, deployment, domain — the compiler guarantees that the deployed system is consistent with the specification. There is no imperative code to drift, no separate permission configuration to forget, no deployment checklist to get wrong. The application is more robust not because of better testing or more careful engineering, but because there is structurally less that can go wrong. The distance between intent and running software collapses to a single compile step.

This site is open source. Improve this page.