Install

Download the installer for your platform from the latest GitHub release and run it. Builds are available for macOS (Apple Silicon & Intel), Windows (x64 & arm64), and Linux (x64 & arm64).

macOS Gatekeeper: builds may be unsigned/un-notarized. If the app is blocked on first launch, run "xattr -c /Applications/rdb.app" to allow it.

The app ships with no database drivers — those live in plugins. After installing, add at least one plugin (see Plugins) before the connection form will show any options.

First connection

  1. Click + in the sidebar to create a connection. Pick a plugin (PostgreSQL, MySQL, SQL Server, Snowflake, MongoDB, RabbitMQ, SSH, SFTP, S3, or HTTP) — the form is generated from that plugin's declared config schema.
  2. Click Test to validate the config, then Save. Profiles persist across restarts.
  3. Select a saved connection to connect. The workspace that opens depends on the plugin's kind.

Plugins

The host loads plugins at runtime from the plugins directory ($RDB_PLUGINS_DIR if set, otherwise <app-data>/plugins). Each plugin is a standalone executable plus a generated <id>.plugin.json manifest.

Install from GitHub (in-app)

Click ⤓ Install plugin in the sidebar, enter a repo (owner/name) and optionally a release tag, then Fetch release. The app selects the asset matching your OS/arch target triple, shows the published SHA-256, and — on confirmation — downloads, verifies the checksum, runs the binary's --describe to generate its manifest, and registers it live. The plugin appears in the New-connection form immediately, no rebuild required.

⚠️ Trust: plugins are native executables that run with full access to your machine. Only install plugins you trust. Downloads are checksum-verified for integrity, not authenticity.

Bundled plugins

PluginKindTalks to
PostgreSQLrdbmsPostgreSQL 12+ (via sqlx)
MySQLrdbmsMySQL & MariaDB
SQL ServerrdbmsMicrosoft SQL Server (via Tiberius)
SnowflakerdbmsSnowflake warehouses
MongoDBdocumentMongoDB & Atlas clusters
RabbitMQrabbitmqBrokers via the HTTP Management API
SSHcliRemote hosts via a PTY terminal
SFTPfilemanagerFile transfer over SFTP
Amazon S3filemanagerS3 & S3-compatible buckets
HTTP clienthttpREST APIs (collections + curl import)

RabbitMQ requires the broker's rabbitmq_management plugin to be enabled.

Workspaces

The workspace rendered for a connection depends on its plugin kind:

Saved connections

Profiles persist per-plugin at <app_data_dir>/connections/<plugin_id>/connections.json as human-readable JSON (the base path is OS-specific). Profiles whose owning plugin is no longer installed are skipped on load but left on disk.

⚠️ Security: connection configs — including passwords — are stored in plaintext. A secure-credential store is not yet implemented; treat the files accordingly.

Themes

rdb ships with 10 built-in themes — 7 dark, 3 light. The default is Catppuccin Mocha.

Catppuccin Mocha · Dracula · Nord · Tokyo Night · Gruvbox Dark · Monokai · Solarized Dark · Solarized Light · Catppuccin Latte · GitHub Light.

Building from source

Prerequisites

Run in development

Plugins are out-of-process executables discovered at runtime, so build them first and point the host at the same directory:

npm install
npm run plugins:dev                       # builds the 10 bundled plugins + manifests
RDB_PLUGINS_DIR=$PWD/dev-plugins npm run tauri dev

Without any plugins installed the connection form will be empty.

Build a release bundle

npm run tauri build   # → src-tauri/target/release/bundle/
CommandDescription
npm run devFrontend-only Vite dev server (:1420)
npm run buildType-check (tsc) and build the frontend
cargo buildBuild the full Rust workspace
cargo testRun Rust tests across the workspace
npm run plugins:devBuild bundled plugins into dev-plugins/

Architecture

The single most important idea: the Tauri host knows nothing about SQL, documents, or queues. It ships with only the rdb-core crate (no DB drivers) and acts as a transport between the frontend and out-of-process plugin executables.

React frontend
      │  @tauri-apps/api invoke()  (8 generic commands)
      ▼
Tauri host (src-tauri)  —  no DB drivers
      │  line-delimited JSON-RPC over stdio
      ▼
Plugin sidecars  —  postgres / mysql / mssql / snowflake / mongodb / rabbitmq / ssh / sftp / s3 / http

Three boundaries

Live connection handles (PgPool, mongodb::Client, the RabbitMQ HTTP client) never cross any boundary — they stay inside the plugin process, keyed by a ConnectionId (UUID).

See the full design doc: plugin-architecture.md.

Authoring a plugin

The shared traits make new backends small to add. For a relational backend:

  1. Create a binary crate under crates/plugins/<name> depending on rdb-core, rdb-plugin-runtime, and (for relational backends) rdb-rdbms-common. Add it to the workspace members in Cargo.toml.
  2. Implement rdb_core::Plugin — return a PluginInfo with the right kind and a config_schema describing the connection form, plus a connect returning an Arc<dyn Connection>.
  3. For relational backends, also implement RdbmsPlugin (list_schemas, list_tables, describe_table, execute, and optionally apply_changes for editing).
  4. In main.rs, call rdb_plugin_runtime::run(plugin, dispatcher) — for RDBMS use RdbmsDispatcher(plugin). There is no central registry to edit.
  5. To run it in dev, add the crate to the PLUGINS/CRATES arrays in scripts/dev-plugins.sh.

Non-relational backends pick a different PluginKind (Document, Rabbitmq, or Other) and the frontend renders the matching workspace component.

Publishing a plugin

For a plugin repo to be installable in-app, each GitHub Release must include:

No manifest is shipped — the host generates it by running the verified binary's --describe at install time.

← Back to download