DBeagle Roadmap

April 11, 2026 ยท View on GitHub

This roadmap is kept as repo truth for the unreleased V1 branch. Checked items reflect what is already implemented in the current tree.

Phase 1: Foundation + Rust Core + Trino (MVP)

1.1 Extension Scaffold + Build System

  • Initialize the VS Code extension with TypeScript
  • Configure esbuild bundling for the extension host and webview entry points
  • Set up package.json contribution points
  • Add commands for connect, disconnect, run query, and refresh schema
  • Add keybindings, including Ctrl/Cmd+Enter for query execution
  • Add configuration settings
  • Set up lazy activation events

1.2 Rust Native Core (napi-rs)

  • Initialize the Cargo workspace with the native/ crate
  • Configure napi-rs with @napi-rs/cli
  • Implement ResultStore as columnar in-memory storage
  • Add a streaming builder or append/finalize path so results can materialize incrementally
  • Add page retrieval, counting, export, aggregate, and search APIs
  • Use MessagePack between JS and Rust
  • Use Rayon for parallel sort/filter
  • Add release and debug native build scripts
  • Add the TypeScript native binding wrapper
  • Fail loudly if the native module cannot load

1.3 SQL Parser (WASM - sqlparser-rs)

  • Initialize crates/sql-parser/ with wasm-pack
  • Wrap sqlparser-rs for ANSI SQL and Trino dialects
  • Expose parse_sql, completion_context, check_read_only, format_sql, and split_statements
  • Bundle the .wasm output with the extension
  • Keep the parser crate platform-independent

1.4 CI/CD + Cross-Compilation

  • Add GitHub Actions CI for lint, typecheck, Rust tests, and Vitest
  • Add a release workflow for the currently shipped VSIX targets
  • Package platform-specific VSIX builds in CI
  • Build the WASM parser once and include it in all VSIX artifacts
  • Use a performance-oriented Cargo release profile
  • Add local benchmark budget checks for pre-push verification
  • Publish platform-specific VSIXs to the VS Code Marketplace

1.5 Driver Abstraction Layer

  • Define the DatabaseDriver interface
  • Define connection, result, and result-page types
  • Separate small bounded queries from streamed user queries
  • Keep the driver layer read-only
  • Ensure raw driver rows feed directly into Rust after retrieval

1.6 Trino Driver Implementation

  • Implement the Trino driver using trino-client
  • Support HTTP and HTTPS connections
  • Support basic auth, no auth, and custom headers
  • Stream query results with async iteration
  • Support query cancellation
  • Add schema introspection through information_schema
  • Add connection health checks
  • Reuse connections with HTTP keep-alive
  • Support configurable query timeouts

1.7 Connection Manager

  • Store connection configs in VS Code settings
  • Store passwords in ExtensionContext.secrets
  • Support add, edit, remove, and duplicate connection flows
  • Test connections before saving
  • Track active connection state
  • Fail loudly on connection/runtime errors instead of retrying with compatibility behavior
  • Emit connection status events for UI updates

1.8 Connection Tree View (Sidebar)

  • Implement TreeDataProvider with lazy child loading
  • Support nodes for connection, catalog, schema, table/view, and column
  • Add context menus by node type
  • Add distinct icons for node type and connection state
  • Show inline data types on column nodes
  • Support click-to-preview for tables with SELECT * ... LIMIT 100

1.8.1 Multi-Driver Groundwork

  • Generalize ConnectionDriverId and the shared driver descriptor layer
  • Preserve saved non-Trino configs that already use the current discriminated storage shape
  • Derive parser dialect and editor language registrations from driver descriptors instead of hardcoding Trino
  • Add a second shipped driver as the proving implementation

1.9 Query Execution

  • Run SQL from the active editor
  • Run selected text when a selection exists
  • Support multi-statement execution through WASM splitting
  • Validate read-only SQL before execution
  • Show progress during execution
  • Support query cancellation
  • Display execution time
  • Highlight parse and execution errors with line/column information
  • Record query history metadata
  • Use the planned pipeline:
    • Validate SQL for read-only safety
    • Create a streaming Rust result builder
    • Stream pages from the driver directly into Rust
    • Render the first page as soon as pageSize rows are materialized
    • Keep the result view in a visible streaming state with live progress and cancel support
    • Finalize the store on completion, then enable full sort/filter/export/charting actions

1.10 Result View (Editor-Adjacent Grid)

  • Register a bottom-panel WebviewViewProvider
  • Maintain per-editor result state
  • Add a detach flow into a WebviewPanel
  • Treat the panel as an editor-adjacent result surface, not literal inline editor content
  • Show tabular results
  • Show a clear streaming / partial-results state while the query is still materializing
  • Show data-type-aware column headers
  • Add page-based navigation
  • Add column sorting
  • Add per-column filtering
  • Add column resizing
  • Add copy support
  • Add distinct NULL styling
  • Show row count and execution time
  • Export current results as CSV and JSON
  • Support keyboard navigation
  • Add in-result search

1.11 Basic Charting

  • Add a chart/grid toggle
  • Auto-detect chart-friendly columns
  • Support bar, line, pie, and scatter charts
  • Use Chart.js for MVP chart rendering
  • Feed charts with aggregated or otherwise bounded data from Rust
  • Let users map X and Y columns
  • Export charts as PNG
  • Respect VS Code themes
  • Use Rust aggregations as the chart data source
  • Enable full chart interactions only after the query result has finalized

1.12 Status Bar

  • Show the active connection
  • Show the configured default catalog and schema context
  • Support click-to-switch active connection
  • Show query execution state

1.13 Connection Form (Webview)

  • Add a clean form for connection configuration
  • Support name, host, port, catalog, schema, user, password, and SSL fields
  • Add a test-connection action
  • Add save and save-and-connect flows
  • Keep the shared form model driver-aware while shipping only the Trino form in Phase 1
  • Add advanced headers, properties, and timeout configuration

Phase 2: Query Authoring + Core UX

2.1 SQL Autocomplete + Hinting (WASM-Powered)

  • Register a CompletionItemProvider for SQL
  • Use debounced calls to completion_context()
  • Add keyword completions
  • Add Trino-specific function completions
  • Add table completions from schema metadata
  • Add column completions from schema metadata
  • Add schema-qualified completions
  • Use . as the trigger character
  • Show completion details with data type and table information

2.2 Context-Aware Metadata Scope

  • Suggest tables after FROM and JOIN
  • Suggest columns after SELECT, WHERE, and ON
  • Suggest children after .
  • Avoid suggestions after AS
  • Track aliases from the parsed AST
  • Debounce metadata fetches
  • Let users select the schemas that are active for a connection
  • Only show selected schemas in the connection tree and related metadata surfaces

Note: SQL completion context and candidate generation now run in the WASM parser crate; TypeScript keeps scoped metadata snapshots warm, syncs them into WASM, and maps the returned suggestions into VS Code items. The remaining schema-scope reuse work now sits with Phase 3 multi-driver hardening so it lands consistently across future engines rather than as a Trino-only refinement. Hover is still intentionally deferred until it can provide clearer value than the current lightweight experiments.

2.3 Query Outline

  • Build a Rust-backed outline for statements and CTEs in the active SQL file
  • Scope the outline to the currently opened file and refresh it as edits land
  • Surface the outline in the left navigation panel with jump-to-section navigation

2.4 SQL Scratch Workspace

  • Implement scratch SQL files stored outside the current repo and git diff surface
  • Make scratches reusable across projects while remaining local-first
  • Add commands to create, reopen, and organize recent scratches

2.5 Parameterized Queries

  • Add a dockable parameter view for $name SQL placeholders
  • Resolve parameterized queries in memory before execution
  • Revisit query history and saved query assets after the scratch workflow settles

2.6 Result View Polish

  • Freeze headers and row index during scroll

Phase 3: Driver Expansion + Metadata Foundation

3.0 Multi-Driver Core Hardening

  • Add typed connection settings and validation helpers for postgres, mysql, and mssql instead of treating non-Trino settings as generic records
  • Unlock the shared connection form for multiple shipped drivers while keeping driver-specific advanced fields explicit
  • Register multiple runtime drivers in extension bootstrap and keep driver-specific health checks and messaging
  • Move identifier quoting, table preview SQL, and bounded-query wrapping behind driver-owned helpers instead of hardcoding Trino/ANSI assumptions
  • Normalize timeout, cancellation, pooling, and metadata-loading behavior across drivers without hiding engine-specific failure modes
  • Decide and document the shared namespace model for engines that differ on catalog, database, and schema
  • Reuse schema selection consistently in autocomplete, metadata search, and all driver introspection flows

Note: The completed Phase 3.0 items now back five shipped runtimes: Trino, PostgreSQL, MySQL, SQL Server, and Vertica.

3.1 PostgreSQL Driver

  • Implement using pg plus pg-cursor for paged streaming
  • Use pg.Pool
  • Add SSL/TLS support
  • Add cancellation and timeout handling that map cleanly into the shared driver contract
  • Add schema introspection via information_schema for the shared tree and completion layers
  • Map PostgreSQL database/schema defaults into the shared metadata model

Note: The original plan called for information_schema plus pg_catalog introspection. The shipped Phase 3.1 implementation only needed information_schema for the shared metadata model; richer pg_catalog coverage can be added later if PostgreSQL-specific browsing needs it.

3.2 MySQL Driver

  • Implement using mysql2
  • Add connection pooling
  • Add SSL support
  • Spike and lock the paged-streaming approach before promising parity with Trino/PostgreSQL
  • Add schema introspection via information_schema
  • Decide how MySQL database names map into the shared metadata tree and schema-scope UX

3.3 SQL Server Driver

  • Implement using tedious
  • Add encrypted/TLS connections
  • Support row-event streaming with pause/resume, per-request timeouts, and cancellation
  • Model database/schema/object introspection for the shared tree and completion layers
  • Account for SQL Server driver request-concurrency limits in the runtime/pooling strategy

Note: The shipped Phase 3.3 implementation uses tedious row events plus request pause() / resume() internally, while the shared DBeagle driver contract continues to expose paged async-iterator result pages.

3.4 Vertica Driver

  • Implement using vertica-nodejs
  • Add pooled client lifecycle, cancellation, and timeout handling that fit the shared driver contract
  • Add schema introspection via v_catalog for the shared tree and completion layers
  • Map Vertica database/schema defaults into the shared metadata model
  • Add a Vertica parser dialect path that currently reuses the PostgreSQL grammar until sqlparser-rs ships native Vertica support

Note: The shipped Phase 3.4 parser path intentionally maps Vertica to the PostgreSQL parser grammar internally because the current sqlparser-rs release does not yet expose a native Vertica dialect.

3.5 Local Driver Test Matrix

  • Add a reproducible local PostgreSQL target under test/local/
  • Add reproducible local targets for MySQL and SQL Server under test/local/
  • Add a reproducible local Vertica target under test/local/
  • Add unit coverage for multi-driver connection parsing, form flows, registry bootstrap, and preview-SQL generation
  • Add manual smoke checks for connect, browse, preview, run query, cancel, and completion in each shipped driver
  • Keep driver rollout gated on the existing lint, typecheck, Rust, Vitest, and build baseline

Note: The shared local matrix now covers Trino, PostgreSQL, MySQL, SQL Server, and Vertica. The MySQL target landed during Phase 3.2; later work completed the remaining local-target gaps and aligned the smoke matrix across all shipped drivers. The completion work for Phase 3.5 now also includes the driver-by-driver smoke matrix in TESTING.md, matching seed/query guidance in test/local/README.md, broader multi-driver Vitest coverage, and a shared npm run test:baseline gate that CI uses directly.

Phase 4: Query Intelligence + AI Workflows

4.1 Query Plan + Explain Workflows

  • Fetch query plans in database-native form when supported by the active driver
  • Copy query plans as markdown with enough statement context for AI analysis
  • Add EXPLAIN and EXPLAIN ANALYZE visualization
  • Normalize plan capture behind the driver abstraction without hiding DB-specific detail

4.2 Metadata Search Across Tables

  • Add Rust-backed quick search for columns across the active database
  • Respect selected schemas and active connection scope to avoid noisy matches
  • Return table, schema, and data-type metadata in search results
  • Keep search interactive on large catalogs by reusing cached metadata where possible

4.3 AI-Friendly Result Capture

  • Add single-click copy for top 10 / top 100 rows plus the query text and source file name
  • Provide markdown-first copy formats that are easy to paste into AI tools
  • Preserve column names, ordering, truncation markers, and connection context
  • Keep capture flows read-only and safe for partially streamed results

Phase 5: Runtime Hardening + Concurrent Sessions

5.1 Memory + Performance Guardrails

  • Add memory benchmarks for the Rust result store and streaming pipeline
  • Benchmark large result materialization, export, chart aggregation, and cancellation paths
  • Benchmark metadata-cache and search memory usage on large catalogs
  • Benchmark multi-session memory overhead before broadening concurrent workloads
  • Gate pull requests on memory regression thresholds once baselines stabilize

5.2 Multi-Session / Multi-Connection Runtime

  • Open, maintain, and query against multiple live connections in parallel
  • Bind execution state, cancellation, results, and status UI to the correct session
  • Preserve per-session catalog/schema context and reconnect behavior independently
  • Persist schema-selection profiles without adding noise to other workspaces

5.3 Multi-Result Surfaces

  • Support multiple result sets per editor session within the result view
  • Add multiple result tabs

Phase 6: Result Exploration + Export

6.1 Advanced Result Grid

  • Add virtual scrolling
  • Add richer numeric and timestamp filters
  • Add pinned columns
  • Add result diffing
  • Add transpose view

6.2 Advanced Charting

  • Add histogram and distribution charts
  • Add heatmaps
  • Add zoomable time series charts
  • Add chart annotations and labels
  • Add multi-series charts
  • Save chart configurations per query

6.3 Data Export

  • Export to CSV, JSON, SQL INSERT, and Excel
  • Export entire tables without being memory-bound
  • Copy results as markdown tables
  • Export charts as SVG and PNG
  • Add Apache Arrow and Parquet export

Phase 7: Connectivity + Additional Drivers

7.1 Connection Features

  • Add SSH tunnel support
  • Add connection groups and folders
  • Support connection config import/export
  • Support workspace-specific connections
  • Add Kerberos for Trino

7.2 Additional Drivers

  • Add SQLite via better-sqlite3
  • Add ClickHouse via @clickhouse/client
  • Add DuckDB via duckdb
  • Add a generic ODBC connector

Implementation Order

Phase 1 (MVP - Read-Only Trino Explorer with Rust Core):
1.1  Extension scaffold + esbuild + package.json
1.2  Rust native core (napi-rs ResultStore, sort, filter)
1.3  SQL parser WASM (sqlparser-rs, validate, split)
1.4  CI/CD + cross-compilation pipeline
1.5  Driver interface definition
1.6  Trino driver implementation
1.7  Connection manager + secret storage
1.8  Connection tree view
1.9  Query execution
1.10 Result view
1.11 Basic charting
1.12 Status bar
1.13 Connection form

Phase 2:
2.1  SQL autocomplete + hinting
2.2  Context-aware metadata scope
2.3  Query outline
2.4  SQL scratch workspace
2.5  Parameterized queries
2.6  Result view polish

Phase 3:
3.0  Multi-driver core hardening
3.1  PostgreSQL driver
3.2  MySQL driver
3.3  SQL Server driver
3.4  Vertica driver
3.5  Local driver test matrix

Phase 4:
4.1  Query plan + explain workflows
4.2  Metadata search across tables
4.3  AI-friendly result capture

Phase 5:
5.1  Memory + performance guardrails
5.2  Multi-session / multi-connection runtime
5.3  Multi-result surfaces

Phase 6:
6.1  Advanced result grid
6.2  Advanced charting
6.3  Data export

Phase 7:
7.1  Connection features
7.2  Additional drivers

Open Questions / Future Considerations

  • Notebook support through a DBeagle notebook format
  • ERD visualization from schema metadata
  • Quick data preview on tree hover
  • Shared metadata hierarchy for engines that do not naturally expose catalog.schema.table
  • Live query-session catalog/schema context tracking after USE or equivalent session-changing statements
  • Marketplace release process and changelog automation
  • Degree of read-only enforcement configurability
  • Arrow IPC as an alternative to MessagePack in later phases
  • DuckDB as a local analytical sidecar