RadiatorDB

Overview

RadiatorDB is built into Radiator server. It is a document database like MongoDB but built on top of PostgreSQL, so it requires access to one or more PostgreSQL instances.

Feature highlights

• Multi-master support
  • Configure multiple PostgreSQL instances to get multimaster replication support
  • Write to any single instance and changes replicate automatically to all other instances
  • Multimaster write conflicts are handled using a simple last-writer-wins strategy
  • Use for high availability or horizontal read scaling
• JSON REST API for database access with role-based access control
• Database UI
  • Define database UIs for create, read, update, and delete operations
  • Choose UI widgets (text, password, number etc.) for each field
  • Role-based access control
• Revision history and audit log
  • Each database insert, update, or delete generates a revision history entry with information about who made the change
  • Use the built-in UI to view the revision history and restore items as needed
• Automatically expiring documents
  • Useful for session stores that should clear automatically
• Automatic SQL schema management
  • RadiatorDB only needs write access to a PostgreSQL database and it automatically sets up the required SQL tables and replication configurations

Concepts

RadiatorDB stores collections of free-form JSON documents. Each document is keyed by a multivalue key that must be unique within its collection. The documents can be retrieved using the full key, part of the key, or using the JSON data itself.

The documents look like this:

{
  "collection": "users",
  "key": ["mikem", "example.com"],
  "doc": {
    "username": "mikem",
    "email": "mikem@example.com",
    "password": "$argon2i$v=19$m=16,t=2,p=1$M0cyOUZCazI2bWlibkhSdQ$dL2WSQcnvgCbTq+0YfunEA"
  }
}

Database UI

The underlying SQL schema does not force any format on the documents other than the key and the collection. The structure is defined on the UI layer using radconf syntax:

backends {
    radiatordb "mydb" {
        collection "users" {
            roles {
                read "support";
                write "ops";
            }

            name "Users";
            description "WiFi users and support-managed credentials";

            # Build the multivalue key from these fields
            key {
                field {
                    name "Username";
                    type text;
                }

                field {
                    name "Email";
                    type text;
                }
            }

            # Other fields in the doc content

            field "passwordHash" {
                name "Password Hash";
                type password;
                required true;
            }

            field "groups" {
                name "Groups";
                type list;

                field "group" {
                    name "Group";
                    type text;
                }
            }
        }
    }
}

This will generate a management UI that forces the entry to be in the specified format before it is inserted into the database.

TODO: Screenshot would be really nice here...

What RadiatorDB is not

RadiatorDB should not be considered an SQL database even though it is built on top of PostgreSQL. The database must not be written to using SQL as it will break constraints RadiatorDB assumes. All writes have to go through the REST API or the radconf backends in execution pipelines.

For full details see the RadiatorDB backend documentation.