dblab

__Interactive client for PostgreSQL, MySQL, SQLite3, Oracle and SQL Server.__

---

Documentation: https://dblab.app

Table of contents

• Overview
• Features
• Installation

• Help Command
• Usage

• Navigation

• Query editor

• Help modal
• Key bindings
• Contribute
• License

Overview

dblab is a fast and lightweight interactive terminal-based UI application for PostgreSQL, MySQL, and SQLite3, written in Go and works on macOS, Linux, and Windows machines. The main idea behind using Go for backend development is to utilize the ability of the compiler to produce zero-dependency binaries for multiple platforms. dblab was created as an attempt to build a very simple and portable application to work with local or remote PostgreSQL/MySQL/SQLite3/Oracle/SQL Server databases.

Features

• Cross-platform support for macOS/Linux/Windows (32/64-bit)
• Simple installation (distributed as a single binary)
• Zero dependencies.
• Vim-style query editor backed by a real modal-editing engine (goeditor): normal/insert modes, word and line motions, undo/redo, visual mode selection, and in-buffer search, on top of the line-oriented editing commands.
• Multi-query execution: write multiple SQL statements separated by ; and run them concurrently with results displayed in separate tabs.
• Single-query execution: press ctrl+r to execute only the query on the current cursor line, without running other statements in the editor.
• Connection profiles with secure credential storage in the OS keyring.
• Query history: executed queries are persisted across sessions and can be browsed/re-used via a filterable list.
• Read-only mode: use --readonly to prevent accidental writes by forcing the database session into read-only mode (supported for PostgreSQL, MySQL, SQLite, Oracle, and SQL Server).
• Schema switching: press ctrl+s to pick the active schema from a filterable list without restarting the app (PostgreSQL and Oracle, when no schema was pinned at startup); the active schema is always shown in the status bar.
• Built-in help modal: press ? to display a help overlay showing all available key bindings; press Esc to dismiss it.
• Full-screen mode: press alt+f to expand the focused query editor or result set panel to fill the terminal; press Esc to exit.
• Per-panel key bindings: the query editor, the sidebar tree, the result set panel and the panel navigation each have their own section in .dblab.yaml, so every panel can be rebound independently.

Installation

Homebrew

It works with Linux, too.

brew install --cask danvergara/tools/dblab

Or

brew tap danvergara/tools
brew install --cask dblab

Binary Release (Linux/macOS/Windows)

Automated installation/update

Don't forget to always verify what you're piping into bash

Install the binary using our bash script:

curl https://raw.githubusercontent.com/danvergara/dblab/master/scripts/install_update_linux.sh | bash

Help

dblab is a terminal UI-based interactive database client
Usage:
  dblab [flags]
  dblab [command]
Available Commands:
  connect     Re-use saved connection profiles
  help        Help about any command
  version     The version of the project
Flags:
      --cfg-name string                   Database config name section
      --config                            Get the connection data from a config file (default locations are: current directory, $HOME/.dblab.yaml or $XDG_CONFIG_HOME/.dblab.yaml)
      --keybindings, -k                   Get the keybindings configuration from the config file (default locations are: current directory, $HOME/.dblab.yaml or $XDG_CONFIG_HOME/.dblab.yaml)
      --db string                         Database name
      --driver string                     Database driver
      --encrypt string                    [strict|disable|false|true] whether data sent between client and server is encrypted
  -h, --help                              help for dblab
      --host string                       Server host name or IP
      --limit uint                        Size of the result set for the table content query (should be greater than zero, otherwise the app will error out) (default 100)
      --pass string                       Password for user
      --port string                       Server port
      --save-as string                    Save the connection as a named profile for later reuse
      --schema string                     Database schema (optional for postgres and oracle only)
      --socket string                     Path to a Unix socket file
      --ssh-host string                   SSH Server Hostname/IP
      --ssh-key string                    File with private key for SSH authentication
      --ssh-key-pass string               Supports connections with protected private keys with passphrase
      --ssh-pass string                   SSH Password (Empty string for no password)
      --ssh-port string                   SSH Port
      --ssh-user string                   SSH User
      --ssl string                        SSL mode
      --ssl-verify string                 [enable|disable] or [true|false] enable ssl verify for the server
      --sslcert string                    This parameter specifies the file name of the client SSL certificate, replacing the default ~/.postgresql/postgresql.crt
      --sslkey string                     This parameter specifies the location for the secret key used for the client certificate. It can either specify a file name that will be used instead of the default ~/.postgresql/postgresql.key, or it can specify a key obtained from an external “engine”
      --sslpassword string                This parameter specifies the password for the secret key specified in sslkey
      --sslrootcert string                This parameter specifies the name of a file containing SSL certificate authority (CA) certificate(s). The default is ~/.postgresql/root.crt
      --timeout string                    in seconds (default is 0 for no timeout), set to 0 for no timeout. Recommended to set to 0 and use context to manage query and connection timeouts
      --trace-file string                 File name for trace log
      --trust-server-certificate string   [false|true] whether the server certificate is checked
  -u, --url string                        Database connection string
      --user string                       Database user
  -v, --version                           version for dblab
      --readonly                            Forces a read-only connection with the target database
      --wallet string                     Path for auto-login oracle wallet
Use "dblab [command] --help" for more information about a command.

Usage

You can start the app without passing flags or parameters; you'll be asked for connection data instead. !dblab-demo

$ dblab --host localhost --user myuser --db users --pass password --ssl disable --port 5432 --driver postgres --limit 50
$ dblab --db path/to/file.sqlite3 --driver sqlite
$ dblab --host localhost --user system --db FREEPDB1 --pass password --port 1521 --driver oracle --limit 50
$ dblab --host localhost --user SA --db msdb --pass '5@klkbN#ABC' --port 1433 --driver sqlserver --limit 50

Connection URL scheme is also supported:

$ dblab --url 'postgres://user:password@host:port/database?sslmode=[mode]'
$ dblab --url 'mysql://user:password@tcp(host:port)/db'
$ dblab --url 'file:test.db?_pragma=foreign_keys(1)&_time_format=sqlite'
$ dblab --url 'oracle://user:password@localhost:1521/db'
$ dblab --url 'sqlserver://SA:myStrong(!)Password@localhost:1433?database=tempdb&encrypt=true&trustservercertificate=false&connection+timeout=30'

If you're using PostgreSQL or Oracle, you have the option to define the schema you want to work with. The --schema flag is optional: if omitted, dblab will display all schemas the connected user has access to in the sidebar tree. If provided, only that specific schema will be shown.

# Postgres
$ dblab --host localhost --user myuser --db users --pass password --schema myschema --ssl disable --port 5432 --driver postgres --limit 50
$ dblab --url postgres://user:password@host:port/database?sslmode=[mode] --schema myschema
Oracle
$ dblab --host localhost --user user2 --db FREEPDB1 --pass password --port 1521 --driver oracle --limit 50 --schema user1
$ dblab --url 'oracle://user2:password@localhost:1521/FREEPDB1' --schema user1

For PostgreSQL, the schema can also be set directly in the connection URL with the search_path query parameter, instead of passing --schema alongside it. Both forms are equivalent:

$ dblab --url 'postgres://user:password@localhost:5432/database?sslmode=disable&search_path=myschema'

The schema the session is currently using is shown in the status bar. If you don't pin a schema — no --schema flag, no schema field in the config file and no search_path in the URL — you can also change it at any time with ctrl+s; see Active schema.

You can use the --readonly flag to open a connection in read-only mode. This prevents any write operations (INSERT, UPDATE, DELETE, etc.) from being executed, which is useful when you want to safely browse a production database. The same can be achieved via the configuration file by setting readonly: true on a database profile (see Configuration).

# Postgres
$ dblab --host localhost --user myuser --db users --pass password --ssl disable --port 5432 --driver postgres --limit 50 --readonly
MySQL
$ dblab --host localhost --user myuser --db mydb --pass password --ssl disable --port 3306 --driver mysql --limit 50 --readonly
SQLite
$ dblab --db path/to/file.sqlite3 --driver sqlite --readonly
Oracle
$ dblab --host localhost --user system --db FREEPDB1 --pass password --port 1521 --driver oracle --limit 50 --readonly
SQL Server
$ dblab --host localhost --user SA --db msdb --pass '5@klkbN#ABC' --port 1433 --driver sqlserver --limit 50 --readonly

As requested in #125, support for MySQL/MariaDB sockets was integrated.

$ dblab --url "mysql://user:password@unix(/path/to/socket/mysql.sock)/dbname?charset=utf8"
$ dblab --socket /path/to/socket/mysql.sock --user user --db dbname --pass password --ssl disable --port 5432 --driver mysql --limit 50

Postgres connection through Unix sockets:

$ dblab --url "postgres://user:password@/dbname?host=/path/to/socket"
$ dblab --socket /path/to/socket --user user --db dbname --pass password --ssl disable --port 5432 --driver postgres --limit 50

Now, it is possible to ensure SSL connections with PostgreSQL databases. SSL-related parameters have been added, such as --sslcert, --sslkey, --sslpassword, and --sslrootcert. More information on how to use such connection flags can be found here.

``{ .sh .copy } dblab --host db-postgresql-nyc3-56456-do-user-foo-0.fake.db.ondigitalocean.com --user myuser --db users --pass password --schema myschema --port 5432 --driver postgres --limit 50 --ssl require --sslrootcert ~/Downloads/foo.crt

### SSH Tunnel

Now, it's possible to connect to Postgres or MySQL (more to come later) databases on a server via SSH using a password or SSH key files.
To do so, 6 new flags have been added to the dblab command:
| Flag                 | Description                                                       |
|----------------------|-------------------------------------------------------------------|
|  --ssh-host          |  SSH Server Hostname/IP                                           |
|  --ssh-port          |  SSH Port                                                         |
|  --ssh-user          |  SSH User                                                         |
|  --ssh-pass          |  SSH Password (Empty string for no password)                      |
|  --ssh-key           |  File with private key for SSH authentication                     |
|  --ssh-key-pass      | Passphrase for protected private key files                        |
Examples
Postgres connection via SSH tunnel using a password:

Postgres connection via SSH tunnel using an SSH private key file:

Postgres connection using the url parameter via SSH tunnel using a password:

MySQL connection via SSH tunnel using a password:

MySQL connection via SSH tunnel using an SSH private key file:

MySQL connection using the url parameter via SSH tunnel using a password:

### Configuration

Entering these flags every time is tedious, so dblab provides a couple of flags to help with it: --config and --cfg-name.

dblab is going to look for a file called .dblab.yaml. Currently, there are three places where you can drop a config file:

$XDG_CONFIG_HOME ($XDG_CONFIG_HOME/.dblab.yaml)
$HOME ($HOME/.dblab.yaml)
. (the current directory where you run the command line tool)
If you want to use this feature, --config is mandatory and --cfg-name may be omitted. The config file can store one or multiple database connection sections under the database field. database is an array; previously it was an object only able to store a single connection section at a time.
We strongly encourage you to adopt the new format as of v0.18.0. --cfg-name takes the name of the desired database section to connect with. It can be omitted and its default value will be the first item in the array.

As of v0.21.0, SSL connection options are supported in the config file.

#### Key bindings configuration

Key bindings can be configured through the .dblab.yaml file. There is a field called keybindings where key bindings can be modified. By default, the keybindings are not loaded, so you need to use the --keybindings or -k flag to load them.

Bindings are grouped by the part of the UI they belong to, so every panel can be rebound independently of the others:
| Section | What it controls |
| --------- | ------------------ |
| keybindings (top level) | help, quit, history, fullscreen and schemas, which are global |
| keybindings.navigation | moving focus between the three panels |
| keybindings.editor | the Vim-style query editor: cursor motion in normal mode, mode switching, and query execution |
| keybindings.sidebar | jumping to the top / bottom of the sidebar tree |
| keybindings.resultset | tab switching and horizontal motion in the result set panel |

Every field has a default value, so you only need to list the ones you want to change; anything you leave out falls back to the default shown in the example below. The list of the available key bindings belongs to the bubbletea library. Specifically, see the KeyNames map for an accurate reference.
##### Migrating from the flat layout
Key bindings used to be partly flat: next-tab, prev-tab, page-top, page-bottom, end-of-line and beginning-of-line sat at the top level of keybindings and were shared by more than one panel. They now live under the panel that uses them:

| Old (top level) | New |
|-----------------|-----|
| next-tab | resultset.next-tab |
| prev-tab | resultset.prev-tab |
| beginning-of-line | resultset.line-start and editor.line-start |
| end-of-line | resultset.line-end and editor.line-end |
| page-top | sidebar.go-top (plus editor.go-top and resultset.go-top) |
| page-bottom | sidebar.go-bottom (plus editor.go-bottom and resultset.go-bottom) |

The old top-level fields are no longer read: if your config still sets them, those bindings silently fall back to their defaults. Two things to be aware of while migrating:
The sidebar's jump-to-top / jump-to-bottom defaults changed from <kbd>g</kbd> / <kbd>G</kbd> to <kbd>alt+k</kbd> / <kbd>alt+j</kbd>, which leaves <kbd>g</kbd> / <kbd>G</kbd> free for the editor and the result set.
The editor gained line-start, line-end, go-top and go-bottom. These motions already worked, but were hardcoded to <kbd>0</kbd>, <kbd>$</kbd>, <kbd>g</kbd> and <kbd>G</kbd>; they are now configurable.

The previously deprecated top-level execute-query field is gone as well — use execute-query under keybindings.editor.
.dblab.yaml example

Or for SQLite:

Only the host, ssl, and schema fields are optional. host defaults to 127.0.0.1, ssl defaults to disable. The schema field is only applicable to PostgreSQL and Oracle; if omitted, all accessible schemas are shown.
Connection Profiles
<img src="screenshots/dblab-connect.png" />
dblab supports saving and reusing database connection profiles. When you successfully connect to a database, you can store the connection parameters as a named profile using the --save-as flag. Both the database password and the SSH tunnel password (when using SSH connections) are stored securely in your operating system's keyring (e.g., GNOME Keyring, macOS Keychain, or Windows Credential Manager) rather than in plain text.

Saving a profile
Use the --save-as flag with any connection to save it as a named profile:

The connection parameters are saved to $XDG_CONFIG_HOME/dblab/dblab.json (excluding passwords), while the database password and SSH password (if provided) are stored in the OS keyring.

Using saved profiles
Use the connect command to launch an interactive menu that lists all saved profiles:

This opens a TUI selector where you can:

Browse saved database profiles
Press <kbd>Enter</kbd> to connect to the selected profile
Press <kbd>Ctrl+D</kbd> to delete a profile
Press <kbd>Ctrl+C</kbd> to quit
The password is automatically retrieved from the OS keyring when connecting.
Profile storage format
Profiles are stored in $XDG_CONFIG_HOME/dblab/dblab.json:

## Navigation

The UI is split into three panels: the sidebar tree on the left, the query editor on the top right, and the result set panel below it. Move focus between them with <kbd>Ctrl+H</kbd>, <kbd>Ctrl+J</kbd>, <kbd>Ctrl+K</kbd> and <kbd>Ctrl+L</kbd>.
Every key binding in this README is the default. All of them can be replaced through the .dblab.yaml configuration file — there are no flags for it — so if you've customized a binding, substitute yours for the default shown here. See Key bindings configuration.

Panels and the sidebar tree
dblab connects to a single database (the --db flag is mandatory) and displays its catalog as a tree in the sidebar. For PostgreSQL and Oracle, the tree shows the database, its schemas, and the tables under each schema. For MySQL, SQLite, and SQL Server, the tree shows the database and its tables directly. If the --schema flag is provided for PostgreSQL or Oracle, only that schema is shown; otherwise, all accessible schemas are listed.

<img src="screenshots/tree-view.png" />
Navigate the tree with <kbd>Up</kbd> and <kbd>Down</kbd> (or <kbd>k</kbd> and <kbd>j</kbd>), and press <kbd>Enter</kbd> on a table to load its rows into the result set panel. Jump straight to the first or last visible node with <kbd>alt+k</kbd> and <kbd>alt+j</kbd> (keybindings.sidebar.go-top and keybindings.sidebar.go-bottom), and scroll the tree sideways with <kbd>h</kbd> and <kbd>l</kbd> when a name is wider than the panel.

Press <kbd>/</kbd> to search the tree by name and <kbd>Esc</kbd> to leave the search. While a search is active every character you type — including <kbd>h</kbd> and <kbd>l</kbd> — goes to the search box instead of scrolling the tree.
Result sets
Selecting a table populates the result set panel, which has one tab per view of the table. Press <kbd>tab</kbd> and <kbd>shift+tab</kbd> to move between them:
Data — the rows of the table, or the result of the query you executed
Columns — the schema of the table
Indexes — the indexes on the table
Constraints — the constraints on the table
<img src="screenshots/rows-view.png" />
<img src="screenshots/structure-view.png" />
<img src="screenshots/indexes-view.png" />
<img src="screenshots/constraints-view.png" />
Move around a result set with the arrow keys or <kbd>h</kbd>/<kbd>j</kbd>/<kbd>k</kbd>/<kbd>l</kbd>. The selected cell is highlighted so you can see where you are; press <kbd>Enter</kbd> on a cell to copy its content.
There are no pagination controls — they proved too slow to page through a table effectively. To work through a large table, write a SELECT with explicit OFFSET and LIMIT instead.

Active schema
The right-hand side of the status bar shows the schema the session is currently using, as active schema: <name>. On startup that's whatever schema you pinned — via --schema, the schema field in .dblab.yaml, or the search_path query parameter of a PostgreSQL connection URL — or the session default (current_schema() on PostgreSQL, SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA') on Oracle) when you pinned none.

If you pinned a schema, that's the schema for the whole session and the picker below is disabled: <kbd>ctrl+s</kbd> does nothing. Omit the schema to be able to switch it from the app.
Press <kbd>ctrl+s</kbd> (schemas) from any panel to open the schema picker, a filterable list of the schemas the connected user can see. Type to narrow the list, press <kbd>Enter</kbd> to make the highlighted schema the active one, or press <kbd>Esc</kbd> to close the picker without changing anything. Focus returns to the query editor either way.

Switching the active schema changes the database session — set search_path on PostgreSQL, ALTER SESSION SET CURRENT_SCHEMA on Oracle — so unqualified table names in the queries you execute resolve against the new schema. The sidebar tree is left as it is: it keeps listing the schemas it was built with, and selecting a table there still reads that table's own schema, so browsing the catalog is unaffected.

The picker is only available for PostgreSQL and Oracle, the two drivers where dblab tracks an active schema. On MySQL, SQLite and SQL Server <kbd>ctrl+s</kbd> does nothing and the status bar has no schema segment.
Full-screen mode
Focus the query editor or the result set panel and press <kbd>alt+f</kbd> (fullscreen) to expand it to fill the entire terminal, hiding the title, status bar and the other panels. Press <kbd>Esc</kbd> to return to the split layout. Full-screen mode is also left automatically if you navigate focus away from the editor or result set panel — it isn't available for the sidebar tree.

<img src="screenshots/fullscreen-editor.png" />
<img src="screenshots/fullscreen-resultset.png" />
Query editor
Modes
The query editor uses normal and insert modes, similar to Vim. When you focus the editor it starts in normal mode. Press <kbd>i</kbd> to enter insert mode and type or edit SQL; press <kbd>Escape</kbd> to return to normal mode. You can also enter insert mode with <kbd>a</kbd> (after the cursor), <kbd>A</kbd> (at the end of the line), <kbd>I</kbd> (at the first non-blank character), <kbd>o</kbd> (open a new line below) or <kbd>O</kbd> (open a new line above) — editor.append, editor.append-line-end, editor.insert-line-start, editor.open-line-below and editor.open-line-above.

Cursor movement depends on the mode: in insert mode use the arrow keys, in normal mode use <kbd>h</kbd>, <kbd>j</kbd>, <kbd>k</kbd> and <kbd>l</kbd>.
The status bar's left-hand badge shows which panel is focused rather than the editor's current mode; the editor itself still shows -- NORMAL -- / -- INSERT -- in its own status line.

Editing and motions
In normal mode:
<kbd>dd</kbd> deletes the current line, <kbd>yy</kbd> yanks it into an internal register, and <kbd>p</kbd> pastes the yanked or deleted line after the current line
<kbd>x</kbd> deletes the character under the cursor
<kbd>w</kbd>, <kbd>e</kbd> and <kbd>b</kbd> move forward a word, to the end of a word and backward a word (keybindings.editor.word-forward, keybindings.editor.word-end and keybindings.editor.word-backward)

<kbd>0</kbd> and <kbd>$</kbd> move to the beginning and end of the current line (keybindings.editor.line-start and keybindings.editor.line-end)

<kbd>g</kbd> and <kbd>G</kbd> jump to the first and last line of the buffer (keybindings.editor.go-top and keybindings.editor.go-bottom)

<kbd>u</kbd> undoes the last change and <kbd>U</kbd> redoes it (keybindings.editor.undo and keybindings.editor.redo)

<kbd>v</kbd> / <kbd>V</kbd> enter visual / visual-line mode to select text, and <kbd>/</kbd> / <kbd>?</kbd> search the buffer forward / backward (<kbd>n</kbd> / <kbd>N</kbd> repeat the last search)
<kbd>Ctrl+D</kbd> / <kbd>Ctrl+U</kbd> scroll the view down / up by half a page

This is a full Vim emulation, so plenty of other standard commands (text objects, J, ~, r, registers, and so on) work as well; the list above only covers what shows up in keybindings.editor.
The cursor motions, the mode switches and the execute shortcuts are all configurable under keybindings.editor; the line-oriented commands (<kbd>dd</kbd>, <kbd>yy</kbd>, <kbd>p</kbd>, <kbd>x</kbd>), visual mode, search and <kbd>Ctrl+D</kbd> / <kbd>Ctrl+U</kbd> are fixed.

Executing queries
Press <kbd>ctrl+e</kbd> to execute the contents of the editor (keybindings.editor.execute-query). Whitespace-only queries are ignored.

Press <kbd>ctrl+r</kbd> to execute only the query on the current cursor line (keybindings.editor.execute-single-query), leaving the other statements in the editor untouched. Both bindings work from either mode.

Multiple statements
<img src="screenshots/dblab-multi-query.png" />
You can write multiple SQL statements separated by semicolons (;) and execute them all at once with <kbd>ctrl+e</kbd>:

The statements run concurrently and each result is displayed in its own tab ("query #1", "query #2", and so on) — three tabs, for the example above. If a statement fails, its tab shows the error message while the successful ones still show their results. A maximum of 5 statements can be executed per batch.

While a batch is running, press Ctrl+c to cancel it; press Ctrl+c again to quit dblab.

Query history

dblab automatically saves every executed query to a local history file ($XDG_CONFIG_HOME/dblab/dblab.gob). Press alt+h (see Key bindings configuration to configure it) to open the query history view, which displays past queries sorted newest-first in a filterable list. Use the built-in search to narrow results, press Enter to load the selected query back into the editor, or press Esc to return without selecting anything.

Help modal

Press ? at any time to open the help modal, which displays all available key bindings in a centered overlay. Press Esc to dismiss it; focus returns to the query editor.

Key bindings

These are the defaults; see Key bindings configuration to change them. The Config field column gives the .dblab.yaml key for the bindings that can be customized — the rest are fixed.

| Key | Description | Config field | |-----|-------------|--------------| | Ctrl+H | Toggle to the panel on the left | navigation.left | | Ctrl+J | Toggle to the panel below | navigation.down | | Ctrl+K | Toggle to the panel above | navigation.up | | Ctrl+L | Toggle to the panel on the right | navigation.right |

| Key | Description | Config field | |-----|-------------|--------------| | ctrl+e | Execute the contents of the editor | editor.execute-query | | ctrl+r | Execute only the query on the current cursor line | editor.execute-single-query |

| Key | Description | Config field | |-----|-------------|--------------| | i | Enter insert mode before the cursor | editor.insert | | a | Enter insert mode after the cursor | editor.append | | A | Enter insert mode at the end of the line | editor.append-line-end | | I | Enter insert mode at the first non-blank character | editor.insert-line-start | | o | Open a new line below and enter insert mode | editor.open-line-below | | O | Open a new line above and enter insert mode | editor.open-line-above | | h j k l | Move the cursor left, down, up, right | editor.left / editor.down / editor.up / editor.right | | w / e / b | Move forward a word / to the end of a word / back a word | editor.word-forward / editor.word-end / editor.word-backward | | dd | Delete the current line | — | | yy | Yank the current line | — | | p | Paste the yanked or deleted line after the current line | — | | x | Delete the character under the cursor | — | | 0 / $ | Move to the start / end of the current line | editor.line-start / editor.line-end | | g / G | Jump to the first / last line of the buffer | editor.go-top / editor.go-bottom | | u | Undo the last change | editor.undo | | U | Redo the last undone change | editor.redo | | v / V | Enter visual / visual-line mode | — | | / / ? | Search the buffer forward / backward | — | | n / N | Repeat the last search, forward / backward | — | | Ctrl+D / Ctrl+U | Scroll the view down / up by half a page | — |

| Key | Description | Config field | |-----|-------------|--------------| | Escape | Return to normal mode | editor.normal | | Arrow keys | Move the cursor | — |

| Key | Description | Config field | |-----|-------------|--------------| | Arrow Up / k | Move up the tree | — | | Arrow Down / j | Move down the tree | — | | alt+k | Jump to the first visible node | sidebar.go-top | | alt+j | Jump to the last visible node | sidebar.go-bottom | | h / l | Scroll the tree left / right | — | | / | Search the tree by name | — | | Esc | Leave the search | — | | Enter | List all rows of the selected table and display its structure | — |

| Key | Description | Config field | |-----|-------------|--------------| | tab / shift+tab | Navigate to the next / previous metadata tab | resultset.next-tab / resultset.prev-tab | | Arrow Up / k | Navigate the table upward | — | | Arrow Down / j | Navigate the table downward | — | | Arrow Left / h | Navigate the table to the left | — | | Arrow Right / l | Navigate the table to the right | — | | g / G | Move to the top / bottom of the dataset | — | | 0 / $ | Move to the left / right edge of the row | resultset.line-start / resultset.line-end | | Enter | Copy the content of the selected cell | — |

| Key | Description | Config field | |-----|-------------|--------------| | Alt+h | Open the query history view | history | | Alt+f | Expand the focused query editor or result set panel to full screen | fullscreen | | Ctrl+s | Open the schema picker to change the active schema (PostgreSQL and Oracle, when no schema was pinned at startup) | schemas | | ? | Open the help modal showing all key bindings | help | | Esc | Dismiss the help modal, the query history or the schema picker, exit full-screen mode (or return to normal mode in the query editor) | — | | Ctrl+c | Cancel running queries if any; otherwise quit the application | quit` |

Contribute

• Fork this repository
• Create a new feature branch for a new functionality or bugfix
• Commit your changes
• Execute test suite
• Push your code and open a new pull request
• Use issues for any questions
• Check wiki for extra documentation

License

The MIT License (MIT). See LICENSE file for more details.