v0.4.0 — The Polyglot Engine & CodeMirror Migration

[abeni16]

What's New in v0.4.0

🚀 7 New Database Engines

VeloxDB now supports 13 database engines natively with end-to-end connection pooling, schema tree exploration, and dialect-specific execution:

• ClickHouse — High-performance columnar analytics database via HTTP query endpoint (FORMAT JSON)
• LibSQL — Hybrid SQLite engine supporting local files and remote pipeline protocols (/v2/pipeline) with auth tokens
• Turso — Managed distributed cloud SQLite database via Turso pipeline
• ScyllaDB — High-throughput C++ Cassandra-compatible NoSQL engine via native CQL session driver
• Apache Cassandra — Distributed NoSQL database supporting CQL queries, keyspaces, and column families
• Microsoft SQL Server (MSSQL) — Enterprise database engine support via TDS (tiberius + tokio-rustls)
• Azure SQL — Microsoft cloud-hosted relational database via secure TLS TDS protocol

⚡ Connection Dialog Improvements

• Connection String by Default: Connection dialog now defaults to connection string input mode with real-time regex parsing and automatic engine selection.
• Refined Engine Grid: Engine selector cards have been streamlined to compact, high-density squares (72px × 58px) with custom vector icons for all engines.
• Interactive Onboarding 3D Sphere: Onboarding flow now features all 13 supported engines in the rotating 3D orbit sphere, plus a dedicated + badge indicating more engines planned for future releases.

---

💡 Architecture Discussion: Why We Moved from Monaco to CodeMirror 6

One of the most foundational architectural evolutions in VeloxDB v0.4.0 is the complete removal of the Monaco Editor in favor of CodeMirror 6. Below is an engineering deep-dive into why this migration was necessary and how it transforms the desktop SQL experience.

1. Bundle Size & Startup Latency (Eliminating the Web Worker Overhead)

• The Problem with Monaco: Monaco is the editor that powers VS Code. While extraordinarily rich, it was never designed for lightweight embedding. Including Monaco introduced an extra ~20–30 MB to the frontend distribution bundle and required coordinating asynchronous Web Workers (editor.worker.js, ts.worker.js, etc.). In a cross-platform desktop application built with Tauri, this introduced initial tab-mounting lag and unnecessary memory overhead.
• The CodeMirror 6 Solution: CodeMirror 6 was rewritten from scratch as a modern, modular, tree-shakeable system. It runs synchronously on the main thread without requiring complex web worker routing, slashing bundle weight down to a few hundred kilobytes. Opening new query tabs is now instantaneous.

2. Fine-Grained Multi-Dialect SQL Parsing

• The Problem with Monaco: Monaco provides a monolithic, generic SQL language mode. Differentiating keywords and syntax between PostgreSQL, MySQL, SQLite, T-SQL, and Cassandra CQL required cumbersome token providers and regex patching.
• The CodeMirror 6 Solution: CodeMirror's @codemirror/lang-sql package includes first-class dialect definitions with dedicated Lezer grammar AST parsers. In VeloxDB v0.4.0, switching connection engines dynamically reconfigures the editor dialect:
  • PostgreSQL for Postgres, Supabase, Neon, CockroachDB, TimescaleDB
  • MySQL for MySQL, MariaDB, TiDB, PlanetScale
  • SQLite for SQLite, LibSQL, Turso
  • MSSQL for Microsoft SQL Server & Azure SQL
  • Cassandra for Apache Cassandra & ScyllaDB
  • StandardSQL for ClickHouse and DuckDB

3. First-Class Support for NoSQL & Key-Value Engines

• The Problem with Monaco: VeloxDB is not only a relational SQL client; it also provides full querying capabilities for MongoDB and Redis. Monaco's SQL services could not gracefully support MongoDB JSON/BSON syntax or Redis CLI commands without colliding with SQL keyword suggestions.
• The CodeMirror 6 Solution: CodeMirror 6's extension architecture allows custom completion sources to be plugged in dynamically per engine. VeloxDB now features:
  • Dedicated autocompletion for MongoDB pipeline operators ($match, $group, $project, $lookup, $unwind, $sort, etc.) and collection methods (find, aggregate, insertOne, updateMany, etc.)
  • Dedicated autocompletion for Redis commands (GET, SET, HGETALL, LPUSH, LRANGE, XADD, INFO, etc.)

4. Desktop Memory Footprint & Multi-Tab Stability

• The Problem with Monaco: In desktop workflows where developers open 10–20 query tabs across various databases, each Monaco instance holds heavy DOM structures, text models, and event listeners that degrade frame rates during rapid tab switching.
• The CodeMirror 6 Solution: CodeMirror 6 separates document state (EditorState) from visual rendering (EditorView). Inactive tabs can serialize and hold their state with near-zero memory footprint, rendering fresh views on demand with zero memory leaks.

---

Upgrading from v0.3.1: Drop-in upgrade. All existing database connections and saved query drafts are fully preserved.

---

This discussion was created from the release v0.4.0 — The Polyglot Engine & CodeMirror Migration.