# Why I Built dbterm: A Small Database Workbench

Most of my database work was the same four things:

1. Take a backup.
2. See the data quickly.
3. Follow one record across related tables.
4. Run a small query.

I kept opening large tools such as DBeaver or MySQL Workbench, then used one small corner of them. A five-year-old laptop made the mismatch hard to ignore. I wanted something that opened quickly, stayed keyboard-friendly, and did the useful part without a long ceremony.

That became [dbterm](https://dbterm.shreyam1008.com.np/), a Go database workbench. The [source is on GitHub](https://github.com/shreyam1008/dbterm), and the full [Why I Built dbterm](https://shreyam1008.com.np/log/building-dbterm/) log has the interactive demo.

## The useful loop comes first

The first version was read-focused, not read-only. I wanted to scan a table, sort it, refresh it, copy a key, and move to related rows without losing my place.

That sounds small, but it covers a surprising amount of daily work. A customer row can lead to orders. An order can lead to payments. The important action is often not a large query; it is moving through the data with enough context to ask the next question.

Queries and broader data workflows still matter. The point is to keep the everyday loop small even when the product grows.

## Why Go fit the project

Go kept the development loop short. Builds were fast, tests were plain, and a single binary made it easier to try the tool on another machine.

The big feature flows came first. Then hundreds of smaller requirements arrived: keyboard paths, empty states, refresh behavior, error messages, backup details, and regression checks. The rhythm was simple:

~~~text
build the path → test the real behavior → merge a small change → repeat
~~~

AI helped with parts of the implementation and editing, but the product still needed actual builds and tests. A generated suggestion is not evidence that a database operation is safe.

## The backup agent grew beside the TUI

The backup side follows a careful pipeline:

~~~text
source → verify → compress → encrypt → publish
~~~

The source and destination stay independent. dbterm supports PostgreSQL, MySQL and MariaDB, SQLite, Turso, and Cloudflare D1. Backups can move local-to-local, local-to-remote, remote-to-local, or remote-to-remote through the supported destinations.

Restore is deliberately narrower than backup today: PostgreSQL, MySQL and MariaDB, plus local SQLite. dbterm is useful, but it is not a claim that every path is finished or bug-free.

## A small tool should tell the truth

The goal is not to replace every database client. It is to make the repeated read-and-check work feel lighter, especially on modest hardware.

That also means keeping the limits visible. A terminal UI is not automatically faster for every person. A backup is not complete until its copy and verification path are understood. A small binary is not a guarantee of small queries or fast networks.

I built dbterm because I wanted a calmer database loop. Open it, inspect the data, follow the useful relationship, run the small query, and leave with a backup I can explain.

This is a short companion to the [full dbterm article](https://shreyam1008.com.np/log/building-dbterm/). Edited with AI assistance.