WhoDB: A Sub-50MB Database Explorer That Speaks Eight Database Dialects

Hook

Most database management tools weigh in at 200MB+, take 10+ seconds to start, and still only speak one or two database dialects fluently. WhoDB does eight in under 50MB with sub-second startup.

Context

The modern backend developer's database landscape has fragmented dramatically. A typical microservices architecture might use PostgreSQL for transactional data, MongoDB for documents, Redis for caching, Elasticsearch for search, and ClickHouse for analytics. Each database traditionally required its own management tool—pgAdmin for Postgres, Compass for MongoDB, RedisInsight for Redis—creating a cluttered toolbox and context-switching nightmare.

Meanwhile, existing multi-database tools like DBeaver solved the proliferation problem but introduced their own: bloated installations exceeding 200MB, Java runtime dependencies, sluggish startup times, and interfaces designed in the pre-modern web era. For developers who just need to inspect a table, run a quick query, or debug a data issue, launching a heavyweight IDE feels like firing up a bulldozer to plant a flower. WhoDB emerged from this friction, asking a simple question: what if a database explorer could be as fast and lightweight as modern CLI tools while supporting the full polyglot persistence stack developers actually use?

Technical Insight

WhoDB's architecture achieves its remarkable footprint through three key decisions: a Go backend that compiles to a single native binary, a strategic separation between the tool and the databases it manages, and a unified abstraction layer that normalizes operations across wildly different database paradigms.

The Go backend uses database-specific drivers (lib/pq for PostgreSQL, go-sql-driver/mysql for MySQL, mongo-go-driver for MongoDB) but abstracts them behind a common interface. This means adding support for a new database type doesn't require rewriting the frontend—it's purely a backend concern. Here's how WhoDB structures a query operation across different database types:

type DatabaseDriver interface {
    Connect(config ConnectionConfig) error
    ExecuteQuery(query string) (QueryResult, error)
    GetSchema() (Schema, error)
    Close() error
}

// PostgreSQL implementation
type PostgresDriver struct {
    conn *sql.DB
}

func (p *PostgresDriver) ExecuteQuery(query string) (QueryResult, error) {
    rows, err := p.conn.Query(query)
    if err != nil {
        return QueryResult{}, err
    }
    defer rows.Close()
    
    return normalizeRows(rows) // Converts to common format
}

// MongoDB implementation
type MongoDriver struct {
    client *mongo.Client
}

func (m *MongoDriver) ExecuteQuery(query string) (QueryResult, error) {
    // Parses query as MongoDB aggregation pipeline
    pipeline := parseMongoPipeline(query)
    cursor, err := m.client.Database("db").Collection("coll").Aggregate(ctx, pipeline)
    
    return normalizeDocuments(cursor) // Converts to same common format
}

This abstraction pays dividends in the frontend. The React/TypeScript interface receives normalized JSON regardless of the backend database, allowing the same spreadsheet-like grid component to render PostgreSQL rows, MongoDB documents, and Redis key-value pairs without special-casing. The grid uses TanStack Table (formerly React Table) for virtualization, meaning it can smoothly render result sets with 10,000+ rows without DOM bloat.

The AI chat integration showcases another architectural strength. Rather than hard-coding OpenAI, WhoDB defines a generic LLM provider interface that accepts a prompt and returns a completion. This means adding Anthropic support required only implementing that interface—no changes to the chat UI or query execution logic:

interface LLMProvider {
  generateSQL(prompt: string, schema: Schema): Promise<string>;
}

class OllamaProvider implements LLMProvider {
  async generateSQL(prompt: string, schema: Schema): Promise<string> {
    const systemPrompt = `You are a SQL expert. Given this schema:\n${schema}\nGenerate ONLY the SQL query, no explanations.`;
    
    const response = await fetch('http://localhost:11434/api/generate', {
      method: 'POST',
      body: JSON.stringify({
        model: 'codellama',
        prompt: `${systemPrompt}\n\nUser request: ${prompt}`,
        stream: false
      })
    });
    
    return extractSQLFromResponse(await response.json());
  }
}

The local-first option with Ollama is particularly clever for developers working with sensitive data. You can use CodeLlama or SQLCoder models running entirely on your machine, avoiding the data exfiltration concerns that come with sending schema information and queries to third-party APIs.

WhoDB's distribution strategy also deserves attention. The project compiles the React frontend into static assets that get embedded directly into the Go binary using Go's embed package. This means the entire application—backend server, database drivers, and frontend UI—ships as a single executable with zero runtime dependencies. A Docker deployment is literally just:

docker run -p 8080:8080 clidey/whodb

No volume mounts for configuration files, no multi-stage builds with Node and Go, no nginx reverse proxy. The simplicity is refreshing in an era of increasingly complex deployment manifests.

Gotcha

The multi-database abstraction that makes WhoDB elegant also creates its primary limitation: features that don't translate across database paradigms get relegated to the lowest common denominator. PostgreSQL's advanced features like CTEs, window functions, and full-text search work fine if you write raw SQL, but the visual query builder can't expose them because MongoDB and Redis have no equivalent concepts. You're essentially getting a surface-level explorer for each database rather than deep, database-specific tooling.

The enterprise edition paywall hits harder than the README suggests. If your production environment includes Oracle, SQL Server, or Snowflake—common in large organizations—you're looking at a paid license. The community edition's eight databases cover most development scenarios, but the moment you need WhoDB for actual production DBA work in an enterprise context, you'll likely need to pay. The pricing isn't published on GitHub, which means a sales conversation before you can evaluate enterprise databases.

Finally, the AI query generation is impressive but unreliable enough that you can't trust it blindly. Complex joins, subqueries, or domain-specific logic often produce subtly incorrect SQL that looks plausible but returns wrong results. It's a great starting point for learning SQL or quickly scaffolding simple queries, but experienced developers will find themselves correcting the AI's output more often than they'd like. Treat it as autocomplete, not autonomous coding.

Verdict

Use WhoDB if you're a full-stack developer juggling multiple databases across microservices, value fast startup times and low resource usage over exhaustive feature sets, or want a modern alternative to bloated tools like DBeaver for everyday exploration and debugging. It's particularly compelling for teams running Postgres, MySQL, and MongoDB together—the most common polyglot stack—and developers comfortable with raw SQL who just need a better interface than psql or the Mongo shell. The AI features, while imperfect, genuinely lower the barrier for junior developers or analysts who need to query data occasionally without SQL mastery. Skip it if you need deep, database-specific administration features like PostgreSQL's vacuum analysis or MongoDB's sharding management, work primarily with enterprise databases that require the paid edition, or are a DBA running production systems where tool stability and maturity outweigh performance and aesthetics. Also skip if your security posture prohibits AI integrations entirely, even local ones—the AI features are prominent enough that their absence would feel like missing functionality.