Rad

Rad is a relational database project that reimagines how developers interact with their data layer. Rather than treating the database as a separate system that applications talk to through ORMs and query builders, Rad unifies the data model, migrations, and application client into a single cohesive workflow. The project is currently at version zero and positioned as a proof of concept for exploring what databases could look like if designed around modern development patterns from the ground up. The explicit warning on the documentation is clear that this is a research project ready to try but not ready for production or important data.

The entire system revolves around a declarative schema file called rad.schema.yaml. This file serves as the single source of truth for your database structure. When you define tables, columns, relationships, and constraints in this YAML file, Rad handles everything downstream automatically. Running rad schema migrate reads your schema, compares it to the current database state, and applies changes without requiring manual migration files. There are no numbered migration scripts to write, review, or maintain. The schema you write is what your database becomes, and the tool figures out how to get there from wherever you currently are.

Generated type-safe clients are what set Rad apart from traditional database tooling. Instead of constructing SQL strings at runtime or using a generic ORM that maps results to objects through reflection, Rad generates strongly typed methods directly from your schema. A query like db.Tasks.Query().StatusEq(todo).OrderByPriority().All(ctx) demonstrates the pattern. Every table gets typed query methods. Every column gets typed filters with appropriate operators. Every relationship gets navigation methods. The compiler catches type mismatches, missing columns, and invalid operations before your code ever runs. This eliminates entire categories of runtime errors that plague string-based query construction.

The architecture is built around a custom query language called LIR, short for Logical Intermediate Representation. Generated clients produce LIR rather than SQL, which then flows through Rad's query planner and executor layers. The database communicates over a rad protocol, a JSON-over-HTTP format designed specifically for generated clients rather than human-readable SQL commands. This separation between the query representation and the wire format means the same schema can potentially generate clients for multiple programming languages while maintaining the same semantics. Go is the primary supported target currently, with TypeScript implied through the reference architecture documentation.

Data retrieval handles relationships intelligently without requiring developers to reconstruct object graphs from flat result sets. When you query for data that includes parent records, child collections, or nested relationships, Rad returns the data structured the way your application actually uses it. You don't need to execute multiple queries and stitch the results together manually, nor do you need to process flattened rows back into a hierarchy. The query planner handles the join strategy and the executor delivers structured results that map directly to your typed client interfaces.

Rename-safe migrations use stable IDs to preserve developer intent during schema refactoring. When you rename a column in your schema file, Rad understands that you're renaming rather than dropping and recreating. The migration applies the rename rather than losing data. This addresses a common pain point with traditional migration tools where schema changes that are conceptually simple become error-prone operations requiring careful manual attention. The stable ID approach means the schema evolution tracks your intent rather than just diffing the before and after states.

The project packages everything into a single binary that provides the database server, CLI tools, and code generation capabilities. This eliminates the typical fragmentation where developers juggle separate tools for database administration, migration management, client generation, and development utilities. The entire workflow happens through one executable with subcommands for different operations. Installation is downloading a binary rather than configuring a database server, setting up a migration tool, and adding a code generation step to your build process.

Internally, the database is organized into five architectural layers. Layer one handles KV abstraction for underlying storage. Layer two manages the catalog of schema metadata. Layer three handles LIR parsing and the relation graph. Layer four is the query planner that determines execution strategy. Layer five is the executor that actually runs queries against storage. This layered architecture is documented publicly, suggesting the project is designed for contributors to understand and extend rather than being a black box. The intended audience is developers building OLTP applications who want to reduce boilerplate and close the gap between their schema and their application logic. There's no published pricing because the project is still in experimental stages, focused on proving out the concepts before considering commercial viability or production readiness.