Architecture

Architecture

DBeagle uses a hybrid runtime so it can stay responsive inside VS Code while handling larger result sets than a typical lightweight editor extension.

Runtime shape

VS Code extension host (TypeScript)
  -> connection management
  -> driver orchestration
  -> query execution
  -> result-session lifecycle
  -> webview messaging

Native addon (Rust via napi-rs)
  -> result ingestion
  -> paging, sorting, filtering, search
  -> chart shaping
  -> CSV / JSON export

SQL parser (Rust -> WASM)
  -> statement splitting
  -> read-only validation
  -> completion context
  -> outline building

Shipped drivers

The current runtime ships five engines behind one shared driver contract:

• Trino
• PostgreSQL
• MySQL
• Microsoft SQL Server
• Vertica

Core design choices

• Keep the primary workflow inside VS Code.
• Fail loudly instead of silently degrading on runtime errors.
• Reuse shared execution, metadata, and results infrastructure across drivers.
• Keep the UI safe by default with optional read-only protection.

Result flow

At a high level:

1. DBeagle resolves SQL from the active editor or selection.
2. The parser splits statements and validates read-only mode when enabled.
3. The active driver streams rows.
4. The native result store ingests rows page by page.
5. The result webview updates as soon as data is available.
6. Once finalized, the session unlocks full search, filter, sort, chart, and export behavior.

Security model

• Passwords stay in VS Code SecretStorage.
• Connection definitions live in VS Code configuration.
• Trino headers stay in SecretStorage.
• Native and parser loading use explicit local build outputs.
• Webviews use validated message contracts and escaped rendering.