A database client lives or dies by the quality of its SQL editor. It's where developers spend the most time, the place where every bit of friction costs minutes. So when we started building QoreDB, the choice of editor component was a foundational decision.
We chose CodeMirror 6, Marijn Haverbeke's complete rewrite of the project. Not to follow a trend, but because its modular architecture allowed exactly what we were looking for: a fast, extensible editor whose every layer we control.
Why CodeMirror 6 and not Monaco
Monaco, the editor extracted from VS Code, is a popular choice. It offers a lot of features out of the box. But it comes at a cost: a hefty bundle, an opaque extension model, and heavy integration in a non-Electron context. QoreDB runs on Tauri 2, with a native webview. We need an editor that integrates cleanly into a lightweight DOM, without loading megabytes of JavaScript at startup.
CodeMirror 6 is designed as an assembly of independent building blocks. You import only what you use: SQL syntax highlighting, autocompletion, line numbers, keyboard shortcut handling. The rest doesn't exist in the bundle. This granularity is essential in a desktop application that has to stay responsive even with several tabs open.
The other advantage is CodeMirror 6's immutable state system. Every change produces a new transaction, which integrates naturally with the React model. You can observe content changes, control editability, and inject extensions dynamically without recreating the instance.
Three SQL dialects, a single component
QoreDB supports PostgreSQL, MySQL and SQL Server. Each engine has its own syntax, its reserved keywords, its conventions. Rather than building a generic editor that levels down to the lowest common denominator, we use the @codemirror/lang-sql module, which exposes specific dialects. When you connect to a PostgreSQL database, the editor loads the PostgreSQL dialect. The keywords, the highlighting and the completion suggestions match that specific engine.
This choice is consistent with QoreDB's philosophy: don't abstract away the differences between engines. If you write SQL for PostgreSQL, your editor speaks PostgreSQL. Not a generic SQL that would hide the specifics of the engine you're targeting.
Autocompletion based on the real schema
QoreDB's autocompletion combines three sources of suggestions, active simultaneously as you type.
The first source is the SQL keywords of the active dialect. SELECT, FROM, WHERE, JOIN and all the reserved words of the current engine. CodeMirror provides this completion natively through its SQL module.
The second source is snippets. QoreDB ships templates for common operations: SELECT with WHERE, INSERT INTO, UPDATE, DELETE, JOIN. Each snippet uses CodeMirror's placeholder system to guide input. You type "sel" and you get a complete SELECT skeleton with logical cursor positions.
The third source is the most interesting: schema metadata. QoreDB queries the Rust backend to retrieve the names of schemas, tables, views and columns from the connected database. This metadata feeds a frontend cache with a five-minute TTL. As you type in the editor, the system analyzes the cursor context. After a FROM or a JOIN, it suggests tables. After a dot, it suggests the columns of the preceding table. If you write users., you get the list of columns from the users table, with their types.
The schema cache and invalidation
The metadata cache is a deliberate choice. Querying the database server on every keystroke would be too slow and would generate unnecessary network load, especially over an SSH tunnel. The cache is structured per session: each open connection has its own schema data.
The five-minute TTL covers the majority of typical editing sessions. If the schema changes in the meantime (an ALTER TABLE, for example), QoreDB invalidates the cache in a targeted way. When you run a DDL operation from the application, the cache for the affected collections or columns is cleared immediately. This avoids suggesting columns that no longer exist, or missing ones that have just been added.
A manual refresh button also lets you force an update if you modify the schema outside of QoreDB.
The Rust backend's role in introspection
All schema introspection goes through the Rust backend via Tauri commands. The frontend never talks directly to the database. When the editor needs the list of tables in a schema, it calls a typed Rust command that runs the appropriate query on the target engine.
Each driver implements the DataEngine trait, which exposes the introspection methods: list namespaces, list collections, describe a table. The PostgreSQL driver queries pg_catalog and information_schema. The MySQL driver uses its own system queries. The MongoDB driver lists collections through the native API. Each driver returns a unified format that the frontend consumes without knowing the underlying engine.
This design has a direct benefit: autocompletion works the same way whether you're connected to PostgreSQL, MySQL or SQL Server. The experience is consistent, but the data is always that of the real engine.
What the editor does, and what it doesn't
QoreDB's editor is designed for a precise use: writing, running and iterating on SQL queries. It includes automatic formatting via sql-formatter (Cmd+Shift+F), execution with Cmd+Enter (full query or selection), per-connection persisted history, and reusable snippets through the Query Library.
We made the choice not to include real-time linting or advanced syntax validation. These features add complexity and false positives, especially across varied SQL dialects. A developer writing SQL knows their syntax. The error feedback from the database engine is more reliable and more precise than a client-side JavaScript parser.
In the same way, autocompletion doesn't try to guess the full intent of a query. It suggests what it knows for certain: the objects that exist in the schema, the dialect's keywords, the configured snippets. No probabilistic suggestions, no history-based completion. Precision takes priority over exhaustiveness.
Multi-tab and per-session isolation
QoreDB lets you open several editors in parallel, each tied to its own connection. Each tab has its own independent CodeMirror instance, its content, its history, and its schema metadata. You can write a PostgreSQL query in one tab and a MySQL query in another, each with the right dialect and the right suggestions.
Each tab's state is persisted. If the application restarts, whether deliberately or after a crash, the editors get their content back. It's an implementation detail, but it changes the day-to-day experience: you never lose a query you're in the middle of writing.
The theme, integrated into the design system
The editor respects the application's global theme. In dark mode, it uses CodeMirror's oneDark theme, adjusted with the CSS variables of QoreDB's design system so that the background, border and text colors are consistent with the rest of the interface. In light mode, the default styles are overridden in the same way. Theme switching is instant, without recreating the editor instance.
QoreDB's SQL editor is a deliberate assembly of precise components. CodeMirror 6 provides the base, the SQL dialects guarantee fidelity to the target engine, and schema-aware autocompletion delivers real productivity without approximation. Every decision, from the metadata cache to the absence of linting, reflects a simple principle: give developers reliable and transparent tools, rather than an illusion of intelligence.
Stay updated on new releases
Subscribe to get product releases, new drivers notifications, and technical tutorials.