undb

undb is a private-first, self-hosted no-code platform that combines the simplicity of spreadsheet-style data management with the power of a full Backend-as-a-Service. Built on a clean domain-driven design architecture with TypeScript and Bun, it lets you create tables, define relationships, build forms, and expose REST APIs — all without writing code. The entire stack can be compiled into a single binary or deployed via Docker, making it genuinely portable.

At its core, undb supports SQLite for local use, PostgreSQL and MySQL for production-scale deployments, and Turso for distributed edge databases. The SvelteKit 5 frontend uses Houdini for GraphQL data fetching and an ANTLR4-based formula parser that evaluates Excel-style expressions across fields. Multiple view types — Grid, Kanban, Gallery, Calendar, and Pivot — render data from the same underlying schema through a declarative pipeline.

undb is designed for the full spectrum from solo developer to small team: one person can run it from a single binary file on their laptop, while a team can deploy it in Docker with S3-compatible file storage, email notifications, OAuth2, and OpenTelemetry observability. The same codebase handles both scenarios through environment-driven configuration.

The project is actively maintained with over 140 releases, with recent additions including MySQL support, webhook improvements, and PostgreSQL integration. A managed cloud version is available at app.undb.io for teams who want the no-code experience without the operational burden.

What You Get

• Multi-database backend - Choose between SQLite for local lightweight deployments, PostgreSQL or MySQL for production scale, or Turso for distributed edge databases — all switchable via environment variables without code changes.
• ANTLR4-based formula engine - Excel/Airtable-style formula fields powered by a custom ANTLR4 grammar that parses and evaluates mathematical expressions, date functions, and cross-field references at the database layer.
• Five view types from one schema - Grid, Kanban, Gallery, Calendar, and Pivot views all derive their rendering from the same underlying table schema through a declarative pipeline, so schema changes propagate everywhere automatically.
• Auto-generated OpenAPI REST API - Every table you create automatically gets REST endpoints documented with Swagger UI, enabling external apps and custom frontends to interact with your data immediately.
• Single binary or Docker deployment - The entire backend compiles into a standalone binary using Bun’s compile feature, or deploys as a multi-stage Docker image with Tini for stable container initialization.
• Form builder with submission API - Visual form builder creates data entry forms tied to any table, with submitted records flowing directly into the database through the same validation and event pipeline as UI edits.
• Real-time collaboration via SSE - Server-Sent Events broadcast record changes to connected clients in real time, so multiple users see table updates without page refreshes.
• Webhook system for automation - Configurable webhooks fire on record create, update, and delete events, enabling integration with external automation tools like n8n, Zapier, or custom workflows.
• S3-compatible file storage - Attach files to records with configurable storage backends supporting local filesystem or any S3-compatible provider including MinIO, AWS S3, and Cloudflare R2.
• OAuth2 and OTP authentication - Built-in authentication with GitHub OAuth2, email/password, and optional TOTP-based two-factor authentication, plus admin user seeding via environment variables.

Common Use Cases

• Building a private project tracker - A small engineering team deploys undb via Docker, creates a table for feature requests with Kanban and Calendar views, uses formula fields to auto-calculate priority scores, and exposes a form for stakeholders to submit requests without database access.
• Running a client-facing data portal - A consultant uses undb as a lightweight BaaS for a client project, defining tables via the UI, exposing the auto-generated OpenAPI endpoints to a custom React frontend, and giving the client a no-code interface to manage their own records.
• Replacing Airtable for a self-hosted team - A privacy-conscious organization migrates from Airtable to undb deployed on their own infrastructure, preserving spreadsheet-style workflows with Kanban and Gallery views while keeping sensitive data entirely on-premises.
• Prototyping a data model before writing backend code - A solo developer uses the playground mode at app.undb.io to design table schemas, relationships, and formula fields in minutes, then self-hosts the production instance once the data model is validated.
• Building an internal tool without a backend team - A marketing team creates a campaign asset tracker with Gallery view for creative files, Calendar view for deadlines, formula fields for budget calculations, and webhook notifications to Slack when records are updated.

Under The Hood

Architecture The codebase implements a genuine domain-driven design architecture across a Turborepo monorepo, with the domain logic completely isolated from infrastructure concerns. A CQRS pattern separates read and write paths through explicit CommandBus and QueryBus abstractions, with tsyringe providing real inversion-of-control dependency injection rather than simple environment-variable wiring. The backend runs as an Elysia.js HTTP server that registers modular route handlers for auth, tables, OpenAPI, realtime, and webhooks — each backed by domain packages that know nothing about HTTP. Data flows from HTTP request through a command handler, into domain aggregates that emit events, through an outbox pattern for reliable webhook delivery. This clean separation means the persistence layer (Drizzle ORM) can target SQLite, PostgreSQL, MySQL, or Turso with minimal application-layer changes.

Tech Stack The backend is TypeScript compiled to a standalone binary with Bun, exposing HTTP via Elysia.js with co-located Swagger, tRPC, and GraphQL (via a generated schema with Houdini client) endpoints. Drizzle ORM manages schema migrations across four database targets with separate drizzle config files per adapter. Authentication uses Lucia with adapters for each database, extended with Arctic for OAuth2 (GitHub) and Oslo for TOTP. The SvelteKit 5 frontend runs as a static build via adapter-static, fetching data through Houdini’s compile-time GraphQL client and TanStack Svelte Query for REST. Formula fields use an ANTLR4-generated parser with a custom formula registry that validates function signatures and variadic arguments at definition time. File storage plugs into MinIO or any S3-compatible backend via the AWS SDK.

Code Quality The codebase has meaningful test coverage in the most critical areas — the ANTLR4 formula registry, domain specifications, field utilities, and formula field validation — with proper assertions that verify expected behavior rather than just execution. TypeScript strict mode is enforced across packages, and Biome with Husky enforces formatting and linting on every commit. Error handling in the backend uses Elysia’s typed error system with status codes, though some domain error types remain loosely typed. The DI container with tsyringe and decorator-based injection improves testability considerably compared to the previous generation of the codebase. The monorepo package structure (23 packages) is well-organized around domain boundaries, though the distinction between some packages (commands vs command-handlers) adds navigation overhead.

What Makes It Unique The combination of an ANTLR4-based formula grammar with a type-checked formula registry is the most technically distinctive element — it enables proper syntax validation and variadic argument handling for Airtable-style formulas rather than simple string interpolation. The single-binary compilation using Bun’s --compile flag means the entire backend (including frontend assets embedded via static plugin) ships as one executable file, which is practically unique among self-hosted BaaS tools. The multi-database abstraction via Drizzle that covers SQLite, PostgreSQL, MySQL, and Turso (edge-distributed SQLite) with separate migration configs lets users start on SQLite locally and migrate to managed Postgres without changing application code. The static SvelteKit frontend with Houdini’s compile-time GraphQL query generation avoids runtime schema introspection, producing leaner client bundles for a no-code tool.

Self-Hosting

undb is released under the GNU Affero General Public License v3.0 (AGPL-3.0). This is a strong copyleft license with a network use provision: if you modify undb and provide it as a network service to users, you must make your modified source code available under the same terms. For most self-hosters using undb internally for their own team’s data management, this has no practical impact — you can modify it freely for internal use. However, if you are building a SaaS product or reselling a modified version of undb to customers over a network, the AGPL requires you to open-source those modifications. Commercial use is permitted, but the copyleft obligations must be carefully evaluated before embedding undb into a proprietary product.

Running undb yourself is genuinely straightforward at small scale. A single Docker command starts the full stack with SQLite and local file storage in minutes. For production, you will want to choose a persistent database (PostgreSQL or MySQL), configure S3-compatible storage for file attachments, set up SMTP for email notifications, and handle TLS termination with a reverse proxy like Caddy or nginx. The application is stateless beyond the database and storage backend, so horizontal scaling is possible but requires shared database and storage. You are responsible for database backups, container restarts, and monitoring — the built-in OpenTelemetry integration helps with the latter.

The managed cloud at app.undb.io offers the same feature set without any of the operational burden, handled backups, and a no-setup path for evaluation. There is currently no documented tiering between the free cloud tier and self-hosted, meaning the AGPL self-hosted version appears to be feature-equivalent to what runs in the cloud. The project does not publish a formal enterprise support offering or SLA, so production self-hosters should plan for community support via Discord and GitHub issues. Teams that need guaranteed response times or managed upgrades will need to either use the cloud version or budget for their own operational expertise.