DEV Community

Jamse Bao
Jamse Bao

Posted on

Stress-Testing dbx: 20 MB on the Disk, 90 Database Paths to Exercise

#go #database #cli #performance

A database client supporting 90+ engines sounds like a dependency-management problem disguised as a UI. My late-night question was simpler: how much of that complexity does t8y2/dbx carry before the first connection?

The interesting claim is its small footprint—around 20 MB—combined with desktop, CLI, Docker, AI, and MCP Server modes. That is a much different architecture from shipping one heavy client per database vendor. The real test is not today’s +420 stars; it is startup latency, resident memory, and whether an unused adapter stays out of the hot path.

Under the Hood

The likely execution model is a shared core with database-specific drivers around it. The desktop interface, CLI, Docker image, and MCP endpoint become different front doors to the same connection and query layers.

That design has two useful consequences:

  • Connection handling and query behavior can stay consistent across interfaces.
  • New database support does not require duplicating authentication, result formatting, or export logic.

The edge case is driver loading. If all 90+ integrations initialize eagerly, startup and memory usage will grow quickly. Lazy loading is therefore more important than the headline database count.

A Minimal Measurement Pass

After downloading a release binary, I used this deliberately boring check:

chmod +x ./dbx

/usr/bin/time -v ./dbx --help 2>&1 \
  | grep -E 'Elapsed|Maximum resident'
Enter fullscreen mode Exit fullscreen mode

For a source checkout, the first useful inspection is:

git clone https://github.com/t8y2/dbx.git
cd dbx
find . -maxdepth 2 \( -name 'go.mod' -o -name 'Cargo.toml' -o -name 'Dockerfile' \) -print
Enter fullscreen mode Exit fullscreen mode

This avoids guessing the build system and immediately exposes whether the advertised modes are separate binaries, containers, or wrappers.

Trade-offs I Would Watch

A compact binary does not guarantee a compact running process. TLS libraries, database drivers, schema introspection, query history, and result grids can dominate memory after startup. MongoDB and Redis also do not fit neatly into a relational result-table model, so abstraction quality matters more than adapter count.

For repeatable testing, I would record cold and warm startup, idle RSS, connection time, and a 100,000-row result fetch. The most important failure signal is not a crash—it is a client that appears lightweight until one broad schema scan quietly consumes the machine.

Top comments (0)