v0.23.0 follows v0.22.0 and is a release about where things live. Visual EXPLAIN gained a parser registry that plugins fill at runtime, which is the piece the SQL Server plugin was waiting for: its 1.0.0-beta.1 is in the registry for macOS, Linux and Windows. The SQL editor learns to open .sql files from disk, edit them and save them back, without running them. The data folder that holds connections, settings, saved queries, themes and notebooks can be moved anywhere, an iCloud Drive or Dropbox folder included, so a second machine picks up the same connections. The built-in PostgreSQL driver is now deprecated: the PostgreSQL plugin installs itself when you have a PostgreSQL connection, every place the old driver shows up carries a Deprecated badge, and a migration flow moves connections over one at a time or in bulk, tests them, and offers Undo when the result is not what you expected. Two long-standing bugs that ate typed characters in the editor are gone. The tail is a set of community fixes: dump files that round-trip JSON columns, a connections.json that no longer loses fields it does not understand, a configurable PostgreSQL pool size, and shortcuts that stay out of the way while an input method is composing.

Plugins Ship Their Own EXPLAIN Parsers, and the SQL Server Plugin Lands

Last week's post told the story of this change in full; this is the release it ships in. PR #688 takes @tabularis/explain from 0.1.0 to 0.2.0 with a parser registry: registerExplainParser, unregisterExplainParser, getExplainParser and listExplainParsers, with the built-in PostgreSQL, MySQL and SQLite parsers registered through the same path, so detection and parsing dispatch by format instead of a hard-coded switch. Registering an existing format replaces it, which is what a plugin upgrade needs; unregistering restores detection order deterministically.

On the plugin side, a driver can now answer explain_query with a raw payload tagged with an engine and a format, and declare an explain_parsers array in its .tabularium manifest pointing at a TypeScript bundle for that format. The desktop reads each declared module once, evaluates it the way UI extension bundles are evaluated, matches the export by exact engine and format and registers it. Bundles that fail to read or evaluate are logged and skipped per plugin; a parser that throws during actual parsing surfaces through Visual EXPLAIN's normal error handling. Disabling and re-enabling a plugin unregisters and reloads its formats, so the cycle is deterministic. Plugins that keep returning the parsed plan shape are unaffected.

Two supporting pieces landed with it. The Raw tab of Visual EXPLAIN detects XML from the leading tag, switches Monaco to the XML language and indents a single-line document one node per line, keeping attribute values containing > intact; SQL Server SHOWPLAN arrives as one line, so without this the raw view was a wrapped paragraph. And the host now enforces a plugin's min_runtime_version at install and load time: an older Tabularis refuses the plugin with a message naming both versions, at install even when the archive came from a URL or a local file, instead of failing later inside Visual EXPLAIN. Comparison follows semver precedence, so a prerelease host does not satisfy a 0.23.0 floor. Development builds load the plugin anyway and show the mismatch as a bottom-right warning toast, so a plugin declaring the next release as its floor stays testable.

The first plugin to use all of this is the SQL Server plugin. Its 1.0.0-beta.1 is in the registry with builds for macOS, Linux and Windows, declares min_runtime_version 0.23.0, and ships a sqlserver-showplan-xml parser as its explain bundle. Its manifest declares schemas, views, routines and routine management, triggers, user management, table management, connection strings, TLS and EXPLAIN. It is a beta, and it needs this release: on v0.22.0 the catalogue filters it out, and a manual install is refused with the version message described above.

Open, Edit and Save SQL Files in Editor Tabs

The editor has always worked on text that lives in the app. PR #706 adds a folder icon to the tab strip that opens a native file picker filtered on .sql, .psql and .pgsql. The file becomes a new console tab titled with its name and bound to its path, and nothing is executed on open. On a multi-database connection the tab inherits the currently selected database.

Saving writes the editor text back to that path; Save As asks for a new one, rebinds the tab and renames it. Ctrl/Cmd+S on a file-backed console saves the file, and keeps its previous meaning, submitting pending grid changes, on every other tab. The toolbar gets a compact save split button in the style of the other controls: the main action saves, or opens Save As when the console is not bound to a file yet, and is disabled when there is nothing to save; a small amber dot next to the icon marks unsaved changes; the chevron opens a menu with Save, Save As and Add to Saved Queries, which opens the existing saved-query modal prefilled with the current SQL. The same Save and Save As entries sit at the top of the tab's right-click menu, the tab title gets a bullet while the file is dirty, and its tooltip shows the full path.

Dirty tracking is a real comparison rather than a flag. The tab stores the content last read from or written to disk and compares the editor text against it, so typing a character and deleting it again leaves the file clean, and an edit made while a write is in flight keeps the tab dirty. That stored content is persisted with the tab, so a file tab restored after a restart can still be saved to the same path and still knows whether it changed. Close, Close Others, Close to the Right, Close to the Left and Close All all check whether any tab about to go has unsaved file changes and ask before discarding them.

The file IO goes through two small Tauri commands in Rust instead of the JS filesystem plugin. The earlier attempt failed with a forbidden path error for anything outside the app data directory, and the runtime scope the dialog plugin grants for a picked path does not survive a restart, so saving a restored tab could never have worked that way. The commands validate the path, cap reads at 50 MB and run the blocking IO off the main thread, the same approach result exports already use.

Move the Data Folder Anywhere, and Sync It

Issue #702 from @jschuur asked for connections that follow you across machines. PR #707 answers with a Settings → Storage tab and one setting: the root folder where Tabularis keeps its data. Connections, config.json, saved queries, themes, notebooks, query history and custom connection icons all live under it. Installed plugins are the one exception and always stay in the platform data directory, since they are per-platform binaries. TablePlus does this with one path per file; a single root is simpler and covers the case people actually have, a folder in iCloud Drive or Dropbox.

When you pick a new folder the backend inspects it first. If it already holds Tabularis data, synced from another machine say, the default is to use it as is. Otherwise you choose between copying your current data into it, with existing files never overwritten, or starting empty. The current folder, anything nested inside it or containing it, relative paths and plain files are rejected. The choice is written to storage-location.json in the default config directory, so the app finds it before loading anything else, and it is resolved once per process and cached; the GUI and the tabularis --mcp subprocess read the same pointer and always agree. That is also why a change needs a restart, and the tab shows a banner with a Restart now button until you do. The tab carries a warning worth repeating: Tabularis reads the folder at startup, so avoid running two instances on the same folder at the same time, for example on two machines while it is still syncing.

The TABULARIS_DATA_DIR environment variable overrides the pointer file. When it is set the tab shows the folder read-only and explains why, and a note documents the variable with a copy-ready example. It applies to the MCP server too and is the right tool for portable installs, scripts and development. Every remaining direct call to the platform config and data directories now goes through one path module, so nothing is left behind in the old folder, and the asset protocol scope is extended at startup so custom connection icons load from the new location.

The Built-in PostgreSQL Driver Is Deprecated, and the Plugin Migration Is Reversible

The PostgreSQL plugin has been catching up with the built-in driver since spring, and it reached 1.0.0-rc.1 last week. From this release on it is the driver PostgreSQL connections are supposed to use, and the built-in postgres driver is deprecated with a tentative removal date of 2026-10-05. The flow that gets you from one to the other is the work of @aesslinger in PR #685, designed first in a planning document and then built in five reviewed chunks.

It starts before you do anything. At launch, if at least one saved connection uses the built-in postgres driver and a compatible plugin release exists in the registry, Tabularis installs and activates the postgresql plugin in the background. This re-triggers on every launch, so uninstalling the plugin while a built-in PostgreSQL connection still exists gets it reinstalled next time; there is no opt-out for this release, and the PR says so rather than leaving it to be discovered. Once the plugin is ready, three things appear:

• A Deprecated badge, with a tooltip naming the replacement and the removal date, on the built-in entry in the connection catalogue, on its card under Settings → Plugins, and on every connection row that still uses it. The plugin's own catalogue entry sorts ahead of the built-in one.
• A dismissible banner on the Connections page. It reads Try the new PostgreSQL plugin when the plugin is installed, and couldn't be downloaded, we'll retry on the next launch when the registry was unreachable. Dismissing it hides it for the connections that existed at that moment; a new built-in connection brings it back.
• A Switch to plugin action on each built-in PostgreSQL connection, as a button on the card and in the context menu, plus a Review connections link on the banner that opens a bulk checklist.

Switching a single connection asks for confirmation, flips the driver to postgresql, reconnects it if it was open, and runs a connection test. The toast that follows reports success or the exact failure, and always carries Undo, which flips the driver back and reconnects again. A failure that is not the plugin's fault is labelled as such: if the connection also fails on the built-in driver, the toast says so and keeps the switch. If the plugin process itself did not start, the toast says no connection was attempted. Undo can fail too, for instance when the connection was deleted underneath it, and that surfaces as its own error toast instead of an unhandled rejection. Every one of these outcomes also has a Report an issue action that opens a pre-filled GitHub Issue Form in the plugin repository with the plugin and app versions, OS and error already in place, and it works even when the registry API is unreachable thanks to a static fallback URL for the first-party plugin.

The bulk checklist is where the capability check lives. Each connection is compared against the capabilities the installed plugin declares in its manifest. A connection that uses something the plugin does not declare, SSL or connection strings are the two the code knows about, is listed unchecked with the specific gap named inline and a Report this gap action; once you have filed it, the row shows Reported instead. A connection whose connection string is stored in the keychain is unchecked as well, with a note that the secret will not carry over and needs to be re-entered after migrating, because the plugin cannot read the built-in driver's keychain entry. Everything else defaults to checked. Migrate N selected then works through the rows sequentially with per-row status, one failure does not abort the rest, and migration continues if you close the modal. Every migration is recorded in a persisted history so the state survives a restart.

Two details for later. The whole thing is parameterized by a (builtinId, pluginId) pair, with ("postgres", "postgresql") as the only entry today, so the MySQL and SQLite deprecations that are expected to follow are an additional pair rather than a redesign. And a migrationModeByDriver setting is staged for a future switch to forced migration; for v0.23.0 every driver is opt-in, and nothing moves unless you click.

Two Bugs That Ate Keystrokes in the SQL Editor

Issue #731, reported by @aesslinger against the PostgreSQL plugin before it was traced to the app, described a character disappearing right after a Shift+Home selection. PR #732 found two independent bugs behind the symptom.

The first is WebKit-only, which is why it never showed on Windows. Monaco falls back to a hidden textarea for keyboard input wherever the EditContext API is missing, which is every WebKit build (WebKitGTK on Linux, WKWebView on macOS) and Firefox. For a backward selection, Shift+Home, Shift+Left or Shift+Up, it mirrors the selection into that textarea as a reversed range, browsers collapse such a range to the smaller offset, the next typed character lands before the mirrored text, and Monaco deduces a one-character composition over a non-empty selection and discards it. A small app-side patch collapses the reversed range at the anchor for Monaco's input textarea only; Monaco 0.56.0 and current VS Code main still carry the same code, so the fix stays in Tabularis for now.

The second affected every platform. The editor wrapper debounces onChange by 300 ms and separately re-syncs Monaco from the initialValue prop whenever the two differ. The flush re-renders the page asynchronously, so a keystroke typed between the flush and that effect was already in the editor but not yet in the prop, and the effect wrote the stale value back. Typing at roughly the debounce interval lost every third character: abcd typed at 0.30 to 0.32 s intervals came out as abd. The wrapper now remembers the values it handed to onChange until the consumer echoes them back and never re-applies an echo; a genuinely external change, a saved query loaded into the tab for instance, still wins and cancels any pending flush. Both fixes were verified in the real Tauri app on WebKitGTK 2.52.6, driving the console with xdotool and reading the editor state through the remote inspector.

The same PR stops @monaco-editor/react from fetching Monaco from the jsDelivr CDN at runtime while a full copy sat unused in the bundle. The loader now points at the bundled package and registers the editor and JSON workers itself, so the editor works offline and ships the version pinned in package.json.

Smaller Things

• Tables first in the quick navigator (PR #703): a PostgreSQL schema with about 300 tables showed 1.6k entries because PostGIS alone adds over a thousand functions to public, and typing a table name did not filter them away. Objects now carry a relevance weight (tables 20, views 10, routines and triggers 0), so tables come first on an empty query and a table containing the text ranks above functions, while typing the exact name of a function still puts that function first. The fuzzy threshold drops from 0.4 to 0.3, one typo every four characters, which also applies to the command palette since both share the same search. The palette renders at most 100 rows; the footer still shows the total match count.
• Dump files round-trip JSON columns and backslashes (@soliloquist, PR #720, fixes #717): the dumper applied two different escaping rules inside one file. Text columns doubled backslashes, correct for MySQL and wrong for PostgreSQL and SQLite, where the dump re-imported a\b as a\\b. JSON columns went through a fallback that only escaped quotes, so on MySQL \" became " (error 3140 on import) and \uXXXX became uXXXX, valid JSON with all non-ASCII text silently destroyed. One dialect-aware string escaper now handles every literal, JSON and JSONB columns are written as JSON literals with UTF-8 emitted as-is, and unit tests cover both dialects, NUL, nested values and JSON scalars. Behaviour change for PostgreSQL and SQLite text columns: backslashes are no longer doubled.
• connections.json keeps the fields it does not understand (@atirna, PR #708, fixes #668): an older binary saving the file used to drop every field it did not recognize, which became a real problem once the MCP process started writing it alongside a possibly newer GUI. Unknown fields are now preserved on write.
• PostgreSQL pool size is a setting (@DhruvShah-Dev, PR #681, refs #71): the built-in PostgreSQL driver gains a Pool Max Size setting under Settings → Plugins, used when the pool is created. The default stays at 10, oversized values are capped at 64, and invalid or zero values fall back to the default. Useful behind pgBouncer, where a pool of ten per connection is more than you want.
• Shortcuts stay quiet during text composition (@DhruvShah-Dev, PR #656, fixes #655): dead keys and IME composition produce keydown events that look like shortcuts before the final character is committed. A shared guard recognizes them (isComposing, Dead, Process, Unidentified, keycode 229) and both the global shortcut handler and the Monaco interception skip them, so the character reaches the editor instead of stealing focus.
• Storage globals bound to jsdom in the test suite (@be-student, PR #719, fixes #713): Node 26's native Web Storage globals kept Vitest from installing jsdom's, and 40 tests failed at localStorage.clear(). Shared setup now binds localStorage and sessionStorage to the worker's jsdom window before test modules load, with regression cases and a note in the testing rules.
• Preview builds for pull requests (PR #705): a maintainer adds the preview label to a PR and CI builds it for macOS (arm64 and x64), Linux and Windows, uploads the installable bundles as run artifacts kept for 14 days, rebuilds on every push while the label stays, and maintains one sticky comment with a download link per platform. PRs from branches of the repository come out signed and notarized; PRs from forks come out unsigned, and the comment says which case applies. Release mode now fails explicitly when signing secrets are missing instead of publishing unsigned bundles. If you reported a bug and get pointed at one of these, it is the fastest way to confirm the fix before a nightly.
• CI dependencies: Dependabot bumped actions/checkout to 7.0.1, actions/cache to 6, actions/upload-artifact to 7 and swatinem/rust-cache to 2.9.2 (#661, #662, #663, #664).

Thanks

Five external contributors land in v0.23.0.

@aesslinger built the release's headline feature end to end, from the planning document to the on-demand install, the deprecation badges, the per-connection and bulk migration flows, the capability-gap detection and the reversible outcome toasts, and kept every review follow-up as its own commit (#685). The same author reported the lost-keystroke bug in #731, the connections.json field loss in #668 and the flaky storage tests in #713, which is three fixes in this release that started as precise reports.

@DhruvShah-Dev made the PostgreSQL pool size configurable (#681) and kept shortcuts from consuming IME composition events (#656). @soliloquist found, reproduced and fixed the dump escaping bug, with a reproduction table and a verification against MySQL 8.0 that left nothing to guess (#720). @atirna made connections.json writes preserve unknown fields (#708), and @be-student fixed the test harness under Node 26 (#719). Thanks also to @jschuur for asking for synced connections in #702, to @mccuskk for the focus-stealing report in #655, and to @ealvesss for the pool-size report that PR #681 refers to.

If you have a dozen PostgreSQL connections and want the plugin without retyping them, keep your migration scripts in files the app could not open, or carry the same connections on two machines and have been exporting and importing them by hand, this is the upgrade.

v0.23.0 is available now. Update via the in-app updater, or download from the releases page.

This week explain.tabularis.dev understands SQL Server. You run your query with SET STATISTICS XML ON, or SET SHOWPLAN_XML ON if you only want the estimated plan, copy the XML that comes back and paste it into the page. The plan opens as the same interactive graph, diagram, table and stats views that PostgreSQL, MySQL and SQLite plans have had since July. Everything runs in the browser and nothing is uploaded.

The operator tree is what you would expect from a SHOWPLAN: Table Scan, Index Seek, Clustered Index Seek, Nested Loops, Hash Match, Sort, Top, Compute Scalar, Parallelism. For actual plans you also get estimated versus actual rows per operator, the number of executions on the inner side of a join, and the self time and cumulative cost that make the hot branch stand out. Pasted XML is pretty-printed and highlighted, since SQL Server hands it to you as a single very long line.

This is a small feature to describe and it took a surprisingly long path to ship. I want to write down that path, because the interesting part is not SQL Server. It is what had to change in Tabularis so that a plugin could bring its own EXPLAIN parser.

Where the parser used to live

When I extracted Visual EXPLAIN into the @tabularis/explain package this summer, the boundary I settled on was: drivers stop at raw EXPLAIN output, and everything after that, parsing, exclusive metrics, findings and views, belongs to the package. That boundary worked well for the three built-in engines, and it is what made the online visualizer possible in the first place.

It had a limit I did not think about enough at the time. The list of raw formats was a closed union of five string literals, dispatched by an exhaustive switch. Only a parser compiled into the package could handle a format. Plugins had a different contract altogether: a driver plugin's explain_query response was always a fully parsed plan, built inside the plugin process.

For SQL Server that meant the plugin carried a Rust SHOWPLAN parser. It worked, and it had good tests, but it had three problems. The parser could only evolve with a Rust binary release. Anyone wanting SQL Server plans in a browser would have to write a second parser, because a web page cannot spawn a plugin process. And every plan-model improvement in @tabularis/explain had to be mirrored by hand on the Rust side to stay in sync.

The fix I wanted was not "add SQL Server to the core package". SQL Server support was already becoming a plugin, and I did not want the core to learn one more engine each time a driver plugin appears. I wanted the plugin to own its parser and the core to be able to load it.

What changed in the core

The work landed in two steps in the Tabularis repository.

The first is a parser registry in @tabularis/explain, released as 0.2.0. A parser is now a small descriptor: an engine id, a globally unique format tag, an optional label, a parse function and an optional sniff function for cheap source detection.

export interface RegisteredExplainParser {
  readonly engine: string;
  readonly format: string;
  readonly label?: string;
  parse(payload: string): ExplainPlan;
  sniff?(payload: string): boolean;
}

export function registerExplainParser(parser: RegisteredExplainParser): void;
export function unregisterExplainParser(format: string): void;

The five built-in parsers became entries in the same registry, the exhaustive switch is gone, and the engine and format types are open while keeping literal autocomplete for the known values. This part is engine-neutral. The package knows nothing about SQL Server.

The second step is PR #688, which teaches the desktop app to use that registry for plugins:

• A driver plugin can now answer explain_query with raw output, the same engine, format and payload shape the built-in drivers already used, instead of a parsed plan.
• The plugin manifest gains an optional explain_parsers array. Each entry names the engine, the format, a label, and the path of a JavaScript bundle inside the installed plugin directory.
• When the set of enabled plugins changes, Tabularis reads each declared bundle, evaluates it with the host's @tabularis/explain API injected as __TABULARIS_EXPLAIN__, checks that the exported descriptor matches the manifest entry exactly, and registers it. Disabling the plugin unregisters its formats, and reloads happen in sorted plugin-id order so enable and disable cycles are deterministic.
• A broken bundle is isolated to its own plugin. Parse errors inside a working parser flow into the normal Visual EXPLAIN error handling.
• min_runtime_version is now enforced at install and at load time, with a message that names both versions. Development builds load the plugin anyway and show the mismatch as a warning toast, which is how I tested the plugin against an unreleased host.
• The raw view learned XML. It used to know JSON and plain text, and a SHOWPLAN document came out as one wrapped paragraph in Monaco.

The plugin guide has a new section on this, so any third-party driver can do the same thing without waiting for a core release.

What changed in the plugin

On the SQL Server plugin side the Rust parser is gone. The Rust process now does the only thing that needs a database connection: it turns SHOWPLAN_XML or STATISTICS XML on, runs the statement, turns the option off again even if the statement failed, and returns the untouched XML with the format tag sqlserver-showplan-xml.

The parser is TypeScript and lives in the explain/ directory of the plugin repository. It has no runtime dependencies and uses no Node built-ins, with its own small XML reader that validates nesting, attributes, entities, comments and CDATA and ignores namespace prefixes. That is deliberate: the same source has to run in a browser tab, in the desktop IIFE and in server-side JavaScript. The build produces both an IIFE that ships inside the plugin archive and an ESM package, @tabularis/explain-sqlserver, versioned and released with the plugin.

The migration was checked with golden fixtures captured from SQL Server 2022: a trivial scan, an index seek with key lookup, a parallel hash join, a STATISTICS XML actual plan, a missing-index recommendation and a multi-statement batch. Their expected output is what the old Rust parser produced. The Rust parser was removed only after the TypeScript one matched it on every fixture.

The online visualizer then needed very little. One PR adds the two packages, imports @tabularis/explain-sqlserver for its registration side effect, and relies on the ShowPlanXML root element for auto-detection. There is no SQL Server code in the site itself.

A note on how this was planned

Before writing any of this I froze the contract in a design document in the plugin repository, with a table of verified claims about the code at specific commits. Doing that caught two mistakes in my own first draft: I believed the Rust parser subtracted child subtree costs and mapped average row size, and it did neither. The document says so explicitly rather than quietly correcting the design. After the Tabularis Web migration I have become quite attached to this way of working: spend the time on a plan that is checked against the repository, then let the implementation tasks be boring.

Next week: SQL Server

The reason all of this happened now is that the SQL Server plugin is about to ship. In April I wrote that SQL Server would be a built-in driver and not a plugin. I was wrong about that, and the roadmap page explains why the direction changed. The short version is that the plugin protocol caught up with what SQL Server needs, and this parser work closed the last gap I knew of.

The plugin covers connection pooling, schema introspection, query execution with multiple result sets, full CRUD, DDL, triggers, stored routines, database users and privileges, BLOBs and visual execution plans. It requires Tabularis 0.23.0, the first release with raw plugin EXPLAIN output and parser bundle loading. Both are planned for next week.

Until then, if you have a SQL Server plan you have been squinting at in Management Studio, paste it into explain.tabularis.dev and tell me what looks wrong. The parser is new and real plans are the best test fixtures I can get.

v0.22.0 follows v0.21.0 and is a release about how the app fits into the desktop around it. The theme can now follow the operating system's light/dark appearance, with a separate theme for each mode, and the native window chrome switches with it. On Linux, Tabularis detects tiling window managers and drops its native decorations so the window tiles like everything else on the screen. Inside the app, the data grid learns the selection shortcuts you already know from Google Sheets: Shift+Arrow grows a range, Ctrl/Cmd+Arrow jumps to the edge, Shift+Space and Ctrl/Cmd+Space select rows and columns, and a plain click on a header selects the column. Notebooks get a round of frontend fixes from the community, and the tail of the release is a set of precise bug fixes: the production banner no longer slices the last grid row in half, PostgreSQL Test Connection finally honors client certificates and custom CAs, SQLite BLOBs that are really text display as text, and MySQL routine definitions resolve in the schema you opened them from.

Follow System: One Theme for Light, One for Dark

Tabularis has had a light/dark listener in the theme provider for a long time, but it was hardcoded to the two default themes and hidden behind a flag nothing could set. Issue #649 asked for the real thing, and @iamthenuggetman built it in PR #650. Settings → Appearance gains a Theme Mode switch with two options:

• Static keeps a single fixed theme. This is the previous behavior and still the default, so nothing changes for existing installs.
• Follow System shows two pickers, Light Theme and Dark Theme, each filtered to themes of that classification (custom themes included, classified by their Monaco base). The app watches prefers-color-scheme and applies the matching pick the moment the OS flips, and it also asks the native window to switch its chrome via Tauri's setTheme, so the titlebar follows too.

The resolution is a pure helper, resolveActiveThemeId(settings, systemIsDark), and the edge cases are handled rather than hoped away: toggling Follow System applies the current-mode theme immediately, a picked theme that no longer resolves (a deleted custom theme, say) falls back to the preset for the current OS mode instead of always landing on dark, and deleting a custom theme resets any per-mode pick that referenced it. The editor is untouched: Same as App follows the switch automatically, explicit editor overrides stay fixed. Three optional fields land in config.json, followSystemTheme, lightThemeId and darkThemeId; absent fields mean Static, so there is no migration. Strings shipped in all eleven locales, and the PR came with provider tests for hydration, persistence, bidirectional OS switching and the fallback paths, plus a follow-up from the Kilo review that fixed the delete-active-theme case in follow mode.

Spreadsheet-Style Selection in the Data Grid

The grid got cell focus and arrow navigation in v0.18.0 and cell-range selection with Shift+click shortly after. What it lacked was the keyboard half of that story, and issue #673 from @manojvignesh laid out exactly which half: rows, columns and ranges, from the keyboard, the way Google Sheets does it. PR #683 implements that set. Every shortcut is relative to the focused cell:

The second column binding exists because plain Ctrl+Space is often consumed before it reaches the app: ibus and fcitx on Linux, Spotlight on macOS. Row, column and range selection remain mutually exclusive, so Ctrl/Cmd + C keeps unambiguous copy semantics, and the focused cell survives Shift/Ctrl+Space so shortcuts chain (Shift+Down three times, then Shift+Space, selects four rows).

Headers change with it. A plain click on a column header now selects that column, replacing the current selection; Ctrl/Cmd+click still toggles and Shift+click still range-selects. Sorting moves to the sort icon next to the column name, which is now a real button with an aria-label, still revealed on hover. One behavior to be aware of: with a focused cell, Ctrl+Left/Right now jumps to the grid edge instead of paginating. The Next page and Previous page shortcuts still fire when no cell is focused and from the pagination buttons, and both remain user-overridable in Settings → Keyboard Shortcuts, where the new bindings are listed too. The range logic lives in pure helpers in utils/dataGrid.ts with unit tests, and every shortcut has a component test.

Native Decorations Get Out of the Way on Tiling Window Managers

On a tiling window manager the native titlebar is dead weight: the compositor already decides where the window goes and how big it is, and the extra strip just steals vertical space and looks wrong next to everything else. PR #680 makes Tabularis notice. On Linux it looks for the session sockets and desktop names of common tilers, HYPRLAND_INSTANCE_SIGNATURE, SWAYSOCK, I3SOCK, NIRI_SOCKET, RIVER_SOCKET, BSPWM_SOCKET, and XDG_CURRENT_DESKTOP / XDG_SESSION_DESKTOP / DESKTOP_SESSION values such as awesome, bspwm, dwm, hyprland, i3, leftwm, niri, qtile, river, sway and xmonad, and hides native decorations when it recognizes one.

The behavior is a setting rather than a guess you can't override. Settings → General → Window Decorations offers Automatic (the default, described above), Always show and Always hide, persisted as windowDecorations in config.json. Changing it applies to every open window immediately, and secondary windows (connection windows, detached results) are created with the same mode. On macOS and Windows, Automatic keeps native decorations on; the setting is there if you want to force it either way. The detection is a pure function over environment variables and carries its own unit tests.

Notebook Polish

Two PRs from @harshavardhankonisa went through the notebook frontend with a magnifying glass.

PR #687 fixes three things you notice within a minute of using a notebook. The add-cell dropdown always opened downward, so near the bottom of the viewport it rendered off-screen and could not be clicked; it now measures its position and flips upward when there is no room below. New cells were not scrolled into view, because scrollToCell ran before React had rendered the cell, so the scroll was a silent no-op; the update is now flushed synchronously and scroll-plus-focus live inside addCell itself, which also removed six duplicated call sites. And the SQL cell editor was a fixed 150px box, cramped for any multi-line query; it now tracks Monaco's content height and grows to fit, with a 60px minimum for empty cells.

PR #700 is a broader React audit that touches the notebook as well as a dozen other components. The visible change is that cells scroll to the top of the viewport with a small margin instead of the center, which reads better when you are adding cells in sequence. Under the surface, eleven copies of the copy-to-clipboard-then-reset-after-two-seconds pattern, none of which cleaned up its timer on unmount, are replaced by one useCopyFeedback hook with tests; the context menu uses stable keys so rebuilt menus no longer inherit stale hover state; SqlHighlight sanitizes its HTML through DOMPurify like the plugin README modal already did; the connection icon component stops calling setState during render; and the notebook outline's role="button" rows answer to Space as well as Enter, as WCAG expects.

Smaller Things

• The production banner no longer clips the last grid row (@thomaswasle, PR #684, closes #682): every routed page sizes itself with h-full, which resolved against the full height of <main> and ignored the banner rendered above it. With a production-flagged connection the page was about 18px taller than the space it had, and the bottom of the results grid, half of the last row, was cut off and unreachable. The routed content is now wrapped in a properly sized flex item, which fixes the editor and split-pane geometry under the banner as well.
• PostgreSQL Test Connection honors client certificates and custom CAs (@adisusilayasa, PR #678): the driver never overrode test_connection, so the test path went through sqlx::AnyConnection and a URL that carried no client certificate, and on macOS used the system keychain instead of the supplied CA bundle. Servers requiring mTLS rejected the test with connection requires a valid client certificate even though real queries, fixed in v0.21.0, worked. The test now uses the same rustls connector as the query pool, so ssl_ca, ssl_cert and ssl_key behave identically in both.
• Monaco relayouts while you drag the editor resize handle (@DhruvShah-Dev, PR #657, fixes #113): the resize handler wrote panel heights to the DOM during the drag and committed React state on release, and Monaco's automatic layout lagged behind the manual writes, leaving stale measurements and visual glitches. The editor is now explicitly relayouted during the drag and once more after release.
• SQLite text BLOBs display as text (PR #696, fixes #695): the v0.20.0 hex preview treated every small generic BLOB as binary, so a BLOB column holding UTF-8 strings, file paths for instance, came back as a hexdump. A complete application/octet-stream value that decodes as valid UTF-8 with no binary control characters is now shown as text; invalid UTF-8 and real binary keep the hex preview.
• MySQL routine definitions in non-default schemas (PR #701, fixes #699): SHOW CREATE PROCEDURE was issued with the bare routine name, so MySQL resolved it against the session's default database and returned error 1305 for any routine opened from another database in the sidebar. Listing, parameters, drop and call scripts were already schema-aware; the definition and edit path was the only one that wasn't. The statement is now schema-qualified with proper backtick escaping, with unit tests for both routine types.
• brew install --cask tabularis, no tap (@justsrc, PR #691): Tabularis is in the main Homebrew cask repository, so the brew tap TabularisDB/tabularis step is gone from all eleven README translations.
• Nightly build pinned: the CI install of tauri-cli is pinned to a revision and runs with --locked, after an unpinned branch install pulled a value-bag release incompatible with the log crate and broke the nightly.

Thanks

Six external contributors land in v0.22.0.

@iamthenuggetman shipped the release's headline feature, Follow System theme mode with per-mode themes, native chrome sync and the full fallback story (#650). @harshavardhankonisa fixed the notebook's dropdown, scroll and editor-height issues (#687) and followed up with a React audit that removed a class of timer leaks and render-time state updates across the app (#700). @thomaswasle diagnosed and fixed the production-banner clipping with a writeup that made the review trivial (#684).

@adisusilayasa closed the loop on PostgreSQL client certificates by bringing Test Connection onto the same connector as the pool (#678). @DhruvShah-Dev put the editor resize glitch open since March to rest (#657), and @justsrc simplified the macOS install docs now that the cask lives upstream (#691). Thanks also to @manojvignesh for the selection-shortcuts spec in #673, to @agross for the SQLite BLOB report, and to @madiajijah11 for the MySQL routine report.

If you switch your OS to dark at sunset and have been switching Tabularis by hand right after, run it under Hyprland or Sway with a titlebar that doesn't belong there, or have reached for Shift+Space in the grid out of spreadsheet habit and had nothing happen, this is the upgrade.

v0.22.0 is available now. Update via the in-app updater, or download from the releases page.

v0.21.0 follows v0.20.0 and is a release about the two surfaces you spend the whole day in: the editor and the results bar. Long scripts can now be folded one statement at a time, and a collapsed statement shows you what it contains when you hover it. The pagination bar gets a rows-per-page selector that applies to that tab only, so raising the limit for one result no longer means changing a global setting and putting it back. Underneath, PostgreSQL connections with a client certificate and key finally present them to the server, plugin installs can be cancelled without leaving a half-extracted directory behind, and the two safety guards (destructive query and production write) are unified so you see one warning instead of two. The rest is a long tail of community fixes: multi-statement exports, hidden SQLite virtual-table columns, database-qualified tables in grid editing, a manual TablePlus import path, and a Snap that appears in the launcher.

Fold Statements, Preview Them on Hover

Long migration scripts and seed files are mostly noise around the one statement you care about. PR #674 teaches the Monaco editor to fold SQL per statement: every multiline statement gets its own folding range, computed with the same dialect-aware splitter that already powers run-at-cursor, so a $$ body or a DELIMITER block folds as one unit rather than at the first stray semicolon. Fold controls stay visible in the gutter instead of appearing only on hover.

The part that makes folding usable rather than merely available is the preview. Hover a collapsed statement and a syntax-highlighted popup shows what's inside; you can move the pointer into it and scroll it without expanding the fold. Previews are scoped to the main query editor, so the small SQL fields elsewhere in the app don't grow tooltips they don't need.

Rows Per Page, Per Tab

The Result Page Size setting has always been global. Issue #672 put its finger on the consequence: with a global page size of 50, a query ending in LIMIT 51 came back as two pages, 50 and 1, and the only way around it was to go to Settings and change the value for every tab. PR #675 adds a rows-per-page selector to the results pagination bar. Whatever you pick there overrides the global setting for the current tab only; other tabs and new tabs keep the default. This is the same model DataGrip uses: the setting is the default, the control on the grid wins for the view you're looking at.

The selector offers presets from 50 to 5000 (the global value is marked as default and slotted in if it isn't already a preset), a custom value input, and an All option that turns pagination off for the tab. All works because execute_query already accepted an optional limit and simply runs the statement unpaginated when none is sent. The override lives on the tab and is persisted with it, so it survives a restart. Changing the page size recomputes the page number so the first visible row stays in view instead of jumping. Editor runs, multi-statement batches and result-panel paging all resolve the effective size through one helper: tab value first, then the global setting, then the historical fallback of 100.

PostgreSQL Client Certificates (mTLS)

The connection form has had Client Certificate and Client Key fields for a while. The TLS connector never used them: build_postgres_tls_connector called .with_no_client_auth() in every SSL mode, so a server that requires client authentication, Google Cloud SQL with mTLS enabled being the canonical case, rejected every connection with connection requires a valid client certificate. PR #666, from @adisusilayasa, loads the certificate and private key from PEM via rustls_pemfile and attaches them with .with_client_auth_cert(...) whenever both ssl_cert and ssl_key are supplied. Client auth is skipped when ssl_mode is disabled, and the pool key now includes both paths, so editing the certificate on a connection can never reuse a pool built without it. Unit tests cover PEM loading, connector configuration and the pool-key change.

Cancellable Plugin Installs

A plugin download that stalls used to be a wait-it-out situation. PR #665 turns the install button into a Cancel button while a plugin is downloading. Cancelling aborts the active request and the extraction, then removes the staged files. The ordering matters for updates: an existing plugin stays active until its replacement is fully verified and ready, so cancelling an update leaves you with the version you had, not with nothing. The registry cards were reworked alongside to show the download, extraction and cancellation states clearly.

One Safety Guard Instead of Two

v0.19.0 introduced the production write guard and it stacked on top of the older destructive-query guard, which meant a DELETE without a WHERE on a production connection produced two modals in a row, and the destructive one still made you sit through its five-second countdown. PR #667 unifies them:

• The five-second countdown is now opt-in. It's off by default and lives under Settings → General as Delay safety confirmations, persisted in config.json as safetyConfirmationDelayEnabled. When enabled it applies to both destructive-query and production-write confirmations.
• On a production connection, the production warning is the only one shown; the standard dangerous-query modal is suppressed, since the production one already covers it.
• Production guards run before dangerous-query guards on every execution path: editor, batch, notebook cells and AI-generated queries. A dedicated query-guard pipeline test pins the ordering.

The related banner fix in PR #677 keeps the red production banner on the connection editor only, so it no longer follows you into Settings.

The SSL-Mode Migration Reaches the MCP Server

v0.20.0 shipped a migration that rewrites stale MySQL-style ssl_mode spellings on PostgreSQL-dialect connections. It ran from the two GUI commands that load connections, and nowhere else. The standalone tabularis --mcp process reads the same connections.json and uses ssl_mode directly to open real database connections, so a connection saved with the stale value stayed silently cleartext over MCP for as long as nobody reopened it in the GUI. Issue #639, fixed by @aesslinger in PR #643.

The fix is four small commits and the middle one is the interesting part. Running the migration from MCP makes that process a writer of connections.json for the first time, and MCP clients spawn it as an independent subprocess that can run alongside the GUI, with no file locking anywhere in the persistence layer. Rather than bolt locking onto ~20 write sites, the migration got a content-based compare-and-swap: it re-reads the file immediately before writing and skips its write for this run if anything changed since its initial read. That's safe because the migration is idempotent and self-terminating; the next process to load connections retries. Content rather than mtime, because coarse filesystem timestamps can't tell two writes in the same second apart. The migration logic moved into its own connection_migrations module with no AppHandle dependency along the way, and a redundant file read found in review was removed by teaching persistence to parse content it already has. The migrate_ssh_connections path has the same gap and is explicitly left as a follow-up: it touches a second file and the OS keychain.

Smaller Things

• Multi-statement result exports (@DhruvShah-Dev, PR #628, fixes #627): the export button is enabled for the active tab of a multi-statement result, and it exports the loaded rows directly instead of re-running the script on a fresh connection, which is what made temp-table scripts impossible to save. After a batch run the first result-bearing statement is selected automatically. Because the export uses what's loaded, the progress modal now warns when only N of M total rows were exported and suggests paging or narrowing the query. CSV, JSON and Markdown formatters are covered by tests.
• Hidden SQLite virtual-table columns stay hidden (@DhruvShah-Dev, PR #624, fixes #622): the move to PRAGMA table_xinfo in v0.20.0 surfaced hidden = 1 rows, FTS5 internals for instance, as ordinary writable columns in the New Row modal. Those are filtered out; hidden = 2 and 3 still map to generated columns.
• Manual TablePlus import path (@DhruvShah-Dev, PR #625, fixes #620): if TablePlus keeps its data somewhere other than the default Application Support location, the importer used to report the source as unavailable. You can now point it at the TablePlus Data directory (or a plist inside it) when auto-discovery fails.
• Database-qualified tables in grid editing and autocomplete (PR #660, closes #659): SELECT * FROM Ops.Addresses used to make the grid look up the primary key of a table called Ops. The extractor resolves Addresses when the qualifier matches the active database; a mismatched qualifier keeps the result read-only so a write can never target a same-named table in the wrong database. Autocomplete keeps each loaded table's database, so typing Ops. suggests tables from Ops while Ops.Addresses. and aliases still suggest columns.
• Query errors you can select and copy (@DhruvShah-Dev, PR #613, closes #591, #608, #610): the error text in the result panel is selectable and gets an explicit Copy button. The same PR renders MySQL/MariaDB JSON updates as JSON text instead of CAST(... AS JSON), which MariaDB rejects, and aligns the object palette's multi-database branch with the sidebar's live selection.
• Run-at-cursor for tabs that weren't active on first render (@GabrielMalava, PR #603): editors in background tabs never registered themselves, so Execute fell back to running the whole script instead of the statement under the cursor.
• Single-database connections keep their controls (@gcapellib, PR #635): selecting exactly one database switched the sidebar to a layout that hid Manage databases and Refresh. The multi-database layout now stays on from one database up, and the lone database is set active and expanded so its tables are one click closer, not one click further.
• The Snap shows up in your launcher (@janpetto, PR #670, refs #669): the published snap exported no desktop entry, so after snap install tabularis the app could only be started from a terminal. A hand-written snap/gui/tabularis.desktop fixes that, and fixes what the .deb's copy got wrong on the way: a lowercase name, empty categories, an icon that doesn't resolve under confinement, and a tabularis:// scheme handler that was invoked without the URL.
• Release notes link to the announcement post: the release workflow now reads src/data/changelog.ts on the tagged commit and prepends the blog post link to the GitHub release body, above the auto-generated "What's Changed" list. tauri-action was bumped to 1.0.0 via Dependabot (#601).

Thanks

Six external contributors land in v0.21.0.

@DhruvShah-Dev is everywhere in this one: multi-statement exports with the truncation warning (#628), hidden SQLite virtual-table columns (#624), the manual TablePlus import path (#625), and copyable query errors plus the MariaDB JSON fix (#613). @adisusilayasa made PostgreSQL client-certificate authentication work (#666). @aesslinger closed the SSL-mode migration gap in the MCP process with a race guard that's worth reading (#643).

@GabrielMalava fixed run-at-cursor for background tabs (#603), @gcapellib kept the database controls visible for single-database selections (#635), and @janpetto gave the Snap a launcher entry, with a verification writeup precise enough to be a template (#670).

If you've scrolled past two hundred lines of seed data to find the one UPDATE you meant to edit, changed the global page size just to see 51 rows on one screen, or watched Cloud SQL reject a connection whose certificate fields you had filled in correctly, this is the upgrade.

v0.21.0 is available now. Update via the in-app updater, or download from the releases page.

Yesterday I opened a pull request to add a browser-hosted mode to Tabularis. The idea was to reuse the React UI and the Rust application services of the desktop client, but without starting a Tauri window. You run tabularis web, a local server starts, and you use the application from a browser.

The PR opened with 49 commits and a diff of 1,040 files, 50,159 additions and 8,351 deletions. A good part of the file count comes from moving the frontend into a workspace package, so the numbers look a bit more dramatic than the actual change, but it was still a very large migration. There were 227 frontend command names across 366 call sites, and more than one hundred files imported Tauri APIs. Connections, tunnels, plugins, credentials, queries, events, file dialogs and secondary windows all assumed that the UI was running inside the desktop application.

The first commit was made at 16:35 on August 21. The last commit of the planned work was made at 17:15 the next day. I used GPT-5.6-sol to do most of this work, but I did not give it a single prompt asking it to build the web version. I used a Ralph loop.

The name comes from the Ralph Wiggum technique popularized by Geoffrey Huntley. The basic idea is almost disappointingly simple. You prepare a plan and a list of small tasks, start a coding agent with a fresh context, ask it to complete one task, make it record what happened, and start again. It is mostly a shell loop around an agent.

I think this simple pattern is important because it continues a clear progression. Autocomplete suggested the next few lines and the programmer accepted or rejected them. Chat let us paste code into a conversation and discuss a bug. Coding agents added tools, and suddenly the model could inspect the repository, edit files, run the compiler and look at the test output on its own. Each step handed the model a bigger piece of the feedback loop a programmer works inside, and the outer loop is the next step in the same direction. I will come back to this progression at the end of the post; first, how the loop actually ran.

An agent is already a loop internally. The model asks to read a file, receives the file, asks to change it, runs a test, sees the failure and tries something else. OpenAI has a good technical explanation of this in its article about the Codex agent loop. However, this inner loop still lives inside one task and one context window. Ralph adds another loop around complete sessions.

In my case the outer loop was more or less this:

plan -> fresh agent -> change -> local tests -> commit -> CI
          ^                                      |
          |--------------- repair ---------------|

The two loops answer different questions. The agent decides what to do next while working on a task. The runner decides if the task is actually complete and whether the next one is allowed to start. I don't want the model itself to be the only authority on both questions, since models are quite capable of saying that everything is done when the interesting broken part is just outside what they tested.

Longer context windows help, but I don't think they remove this need. A long session accumulates useful information together with old test output, failed approaches, changed assumptions and a lot of tool calls that no longer matter. Compaction makes the conversation smaller by summarizing it, but the summary is still an interpretation. After enough hours, it can become hard to know if the model is reasoning from the current repository or from the story it has built about the repository.

Starting again with a clean context has the opposite problem: the new agent knows nothing. So the important information has to live elsewhere. Anthropic described a very similar approach in its work on long-running agent harnesses, where each new session reads a progress file and the Git history, implements one feature, tests it and leaves a clean handoff for the next session.

For this project the durable state was deliberately boring:

• one architecture document describing goals, constraints and the target design;
• 48 task files with narrow acceptance criteria;
• a tracked PROGRESS.md with status and verification evidence;
• Git commits as checkpoints and rollback points.

All of it is committed in the PR under web-ui-project/, together with the runner itself, so you can read the actual artifacts instead of trusting my description of them.

The architecture document described the intended boundary: one shared React UI, a typed client, a Tauri transport for desktop, an HTTP and WebSocket transport for browsers, and shared Rust services below both. It also listed things that were not acceptable, such as duplicating business logic, sending credentials to the browser or accepting server file paths supplied by a remote client.

The task files were intentionally much smaller. Their IDs are grouped by area, which is why the numbering runs from WEB-000 to WEB-103 across only 48 files. One task created the command inventory. Another added the typed client. Another extracted the shared runtime. Later tasks handled query execution, notebooks, backups, plugins, AI, remote authentication, packaging and browser E2E. The query task did not need to solve the whole application. It needed to make queries behave the same through Tauri and HTTP, including cancellation and bounded results, then prove this with the relevant tests.

This is the part that required the most thought before starting. In wall-clock terms, preparing the architecture document and the task list took me around two to three hours, working through the decomposition in conversation with Claude Fable 5 before the loop ever ran. If the task decomposition is wrong, the loop just repeats the wrong abstraction very efficiently. A model can usually compensate for a task that is a little too big or a specification that is missing a detail, but it is much harder for it to notice that the entire sequence of tasks will produce two competing architectures thirty iterations later.

I ran the tasks with Pi CLI. I have been using Pi a lot lately and I like it because it is small, open source and easy to automate. It has a non-interactive mode, accepts files directly as context and does not impose much structure of its own. The relevant part of my runner looked like this (the full script, with all its checks and the exact prompts, is in the PR):

for task in "${TASKS[@]}"; do
  pi --print --approve \
    --name "web-ui-${task}" \
    --thinking high \
    --model openai/gpt-5.6-sol \
    @web-ui-project/docs/WEB_UI_PLAN.md \
    @"web-ui-project/tasks/${task}.md" \
    @web-ui-project/tasks/PROGRESS.md \
    "$TASK_PROMPT"

  validate_progress_entry "$task"
  watch_task_ci "$task"
done

There was more code around this, mostly checks. In particular, the runner required that:

• every task ran in a brand-new Pi session, with Pi's session environment variables explicitly unset, so no conversational state could leak from one task into the next;
• only one copy could modify the branch at a time;
• the task updated the ledger with a summary, evidence and a date;
• the ledger update was included in the task commit;
• local checks passed before pushing;
• CI was green before the next task started.

Every task was a conventional commit, so every new session inherited a branch that was supposed to be both understandable and recoverable.

Each session was told to work only on its assigned task, inspect the worktree first, preserve unrelated changes, run focused tests before editing, review the final diff and keep desktop compatibility. It was not allowed to start the next task or spawn more agents. In theory I could have run many tasks in parallel, but on one branch this would have made the process harder to inspect. Serial execution also created useful pressure: task 31 could assume that task 30 had already passed CI.

The progress file was not just a checklist. For every completed task it contained what changed and the exact commands used to verify it. This turned out to be more valuable than session summaries. A new agent could read the same state that I could read, and the runner could validate parts of it without trusting the prose returned by the model.

The other important part was testing. The branch started with 3,838 frontend tests and 1,157 Rust tests. It ended with 4,023 frontend tests across 270 files and 1,292 passing Rust tests, plus contract tests, resilience checks, packaging checks and E2E tests against real databases in Chromium, Firefox and WebKit.

For the transport work, the same contract was executed against a Tauri mock and a real authenticated HTTP server. This caught a class of bugs that normal unit tests would probably miss, especially differences in serialization and errors. The packaging tests unpacked the artifacts to check that the web assets were really there. There was also a manual parity document with 29 rows, because not everything involving dialogs, windows and browser permissions can be reduced to a unit test in a useful way.

After each push the runner waited for GitHub Actions. If CI failed, it started a new repair session for that same task, with the failed logs included in the work. The repair had to amend the existing commit and watch CI again. There was a limit of three attempts, after which the whole loop stopped.

It also stopped during the real run. WEB-091, the task adapting plugin install links for the browser, failed on its first attempt. The next task did not start and the ledger remained unchanged. I fixed the runner, resumed it, and it continued from the first task that was not completed. That repair is also why the branch ended up with 49 commits for 48 tasks: the extra one is the commit hardening the runner itself. This sounds like a minor detail, but a loop that can only continue is not something I would leave running on a large codebase.

The 49 commits were produced in 24 hours and 40 minutes, around one every 31 minutes on average. Most of that time was not the model typing code. It was Rust tests, frontend tests, builds and CI. Some early commits took ten or fifteen minutes, while tasks involving queries, tunnels, remote authentication or cross-browser testing took much longer.

What came out of the loop is a shared application rather than a separate web rewrite. Running tabularis still starts the desktop client. Running tabularis web starts the same application services without a native window and serves the React UI. On desktop the typed client uses Tauri IPC. In the browser it uses HTTP and WebSocket. Both transports reach the same Rust services for connections, queries, plugins, settings, backups and AI.

The browser differences are handled as capabilities. A desktop file dialog may become an upload, a download or a server-side picker. A secondary window becomes a route. The updater becomes information about the server version. Local mode binds to 127.0.0.1 and exchanges a short-lived bootstrap token for an HttpOnly session. Remote mode is rejected unless authentication, HTTPS origin and allowed origins are configured.

A disclosure is due here. I use GPT-5.6-sol thanks to OpenAI supporting Tabularis through the Codex for Open Source program, which gives selected maintainers Codex access and API credits. It is worth mentioning because this was not a token-efficient experiment. Forty-eight high-reasoning tasks, full test suites and repair sessions consume real resources: in a single day, the run went through roughly 25% of the weekly usage limit of a ChatGPT Pro plan. The sponsorship allowed me to optimize for verification instead of trying to save every model call. With that said, the model did a very good job.

At the same time, I don't think the result is explained only by the model becoming stronger. GPT-5.6-sol was more capable than the models I used a few months ago, but it also found a repository prepared with examples, tests, rules and a very explicit sequence of changes. The same model with a single “build a web version” prompt would probably have produced something impressive in a few hours and unpleasant to maintain for years.

Looking back at the whole run, the clearest way I have found to describe the progression I mentioned at the beginning is where the durable state lives and who decides that the work is complete:

This is why I expect more AI development to move toward loops and what OpenAI calls harness engineering. As agents become able to work for longer, the interesting problem moves from getting them to write code to giving them an environment where wrong work is visible. The compiler, tests, Git history, browser, CI and code review all become feedback channels. The model tries something, the environment pushes back, and the next iteration starts from that result.

There is also a limit to this approach. The loop completed all 48 tasks, but the pull request is still open while I write this. After the planned run I changed the original --web flag into a web subcommand, added connection-specific editor routes and a secure server-side file picker, fixed CI details and resolved conflicts with main. External review found real security issues. The clearest one: user-uploaded SVG connection icons were served inline without any content security policy, a stored XSS, while the neighboring plugin asset endpoint applied every one of the missing protections. The loop knew the right pattern and used it where a task asked for it, but no task owned the invariant. Security is a property of the whole system, and a plan made of locally verified tasks does not automatically verify global properties. Four thousand tests are useful evidence, but they do not make a network listener correct by definition.

I still have to review the architecture, the threat model and the final diff, and I still decide if the feature is ready to merge. The loop changes where my time goes. I spend more time preparing tasks, making the codebase legible, deciding what evidence is sufficient and reviewing the result. I spend much less time writing each implementation line myself.

I would use this approach again for work that can be decomposed and verified. I would be more careful for a product whose behavior is still unclear, because a loop is not particularly good at deciding what people want. It is good at moving through a plan once the plan has enough structure.

I don't know what the right size of a task will be as models improve. What seems clear is that the useful unit is becoming less “give the model a prompt” and more “build a process where the model can try, observe and continue.” For me, this project was the first time that difference became very concrete.

v0.20.0 follows v0.19.0. The quick navigator grows into a real command palette that understands split view, and the data grid learns to paste: tab-separated, CSV, or a single value fanned across a range, always as staged edits you can still roll back. Underneath, the core learns to let go of its drivers. PostgreSQL, the flagship, becomes an independent plugin, developed and released in its own repository at full parity with the built-in driver, which it will most likely replace in an upcoming release. It's the first step of a migration we intend to repeat for every built-in driver. And binary data stops being a second-class citizen: small BLOBs render and edit as hex, and MySQL rows keyed by BINARY columns can finally be deleted.

The Quick Navigator Grows Into a Command Palette

The quick navigator could find a table. It could not run a command, and in split view it quietly searched whichever connection happened to be active rather than the pane you were actually looking at. PR #545, from @verbaux, replaces it with a Spotlight-style palette with two modes: the familiar object search (tables, views, routines, triggers), and a new action palette on Cmd/Ctrl+Shift+A, with a visible mode label in the header so you always know which one you're in.

The interesting work is under the surface. Both palettes and the explorer sidebar each used to build their own "open this in the editor" logic: assembling SQL, guessing the tab type, reading the active connection regardless of where you clicked. They now share one navigation contract, a single definition of what "open", "count rows" and "show definition" mean per object type, used by the sidebar's sixteen call sites and both palette modes alike. Each editor pane registers a command scope, and the palette resolves against the scope that owns the focus. In split view with two connections, the action palette from each pane targets that pane's connection and table. The same discipline reached the schema and generate-SQL modals, which used to inspect the active connection even when opened from a non-active pane; they now receive an explicit target. Palette strings shipped translated, including a contributed Brazilian Portuguese pass.

The action palette deliberately starts small (open settings, open the current table in the SQL console), because the point of this release is the registry, the scoping and the navigation contract; commands are now one item plus an i18n key to add. And the palette's one known data-freshness gap didn't survive the cycle: @DhruvShah-Dev fixed the multi-database object list to read the provider's live database selection instead of the stale saved params, so a database dropped on the server stops haunting the palette (PR #597, fixes #591).

Paste Lands in the Data Grid

Copy has been getting steadily smarter for two releases; paste didn't exist. PR #612, from @ymadd (closes #611), adds spreadsheet-style Cmd/Ctrl+V, and every pasted value goes through the existing pending-changes flow as a staged edit, never straight to the database. You still review, apply or roll back.

The parsing rules are chosen to round-trip real workflows. Tab-separated cells win, because that's what every spreadsheet puts on the clipboard. Multi-line text without tabs is parsed as CSV with double-quote escaping, preferring your configured CSV delimiter, so the grid's own copy formats round-trip cleanly. A single line without tabs is always one value, so hello, world lands in one cell instead of two. A leading header row is dropped only when it matches the grid's column names positionally from the paste anchor: the "export column names" option round-trips without swallowing external data that merely mentions a column name. A single copied value fills the whole selected range or row selection, the pasted matrix clips at the grid edges, and alias and computed columns are skipped under the same guard as inline editing. Pasting a cell's original value back clears its pending change, exactly like typing it would.

The prerequisite fix matters beyond paste: staging N cells in one tick hit a React batching bug where only the last cell survived, because the pending-changes handlers computed the next state from a snapshot. They now use functional updates, which hardens every rapid-succession staging path, not just this one.

PostgreSQL Moves Out of the Core

Tabularis has been moving toward drivers-as-plugins for several releases (#16 is the tracking issue), and this cycle the flagship makes the jump. PostgreSQL now lives as an independent plugin in its own repository, tabularis-postgresql-plugin, no longer developed inside the core. The in-tree copy is deleted; the plugin repo is the single source of truth, with its own security audit, its own CI, and its own 5-platform release builds. PR #577, from @aesslinger, lands the migration.

This is the model we intend to apply to every built-in driver, and it's worth spelling out why:

• Drivers ship on their own schedule. A PostgreSQL fix no longer waits for a Tabularis release. It ships as a plugin release, with its own version, its own changelog, its own cadence.
• The core gets smaller. Every driver that moves out is code the app no longer has to carry, build, and audit in-tree.
• Community drivers stop being second-class. If PostgreSQL itself can run through the plugin API, the API is proven complete. An external plugin has access to exactly the same machinery the flagship uses, because the flagship uses nothing else.
• Isolation. Plugin drivers run as separate processes behind JSON-RPC; a driver crash is a driver crash, not an app crash.
• Focused security surface. A driver in its own repo gets its own audit and its own hardened release pipeline, instead of inheriting whatever the monorepo does.
• It keeps the host honest. Migrating PostgreSQL flushed out every place the core was quietly special-casing itself, and those fixes benefit all drivers (more below).

The plugin is ready, and "ready" here is not a vibe, it's a test suite. The migration built a harness that spawns the real plugin binary and runs the same operations through both drivers against the same live PostgreSQL 16, comparing results: 83 parity tests, on top of a 181-test integration suite with golden-file snapshots for schema metadata. The harness is as paranoid as the thing it tests. A POSTGRES_PLUGIN_BIN pointing at a missing binary now panics instead of silently degrading to builtin-only, a missing golden file fails the test instead of skipping it with a warning, and a CI job that regenerated golden files before comparing against them (an assertion that could never fail) was caught and made opt-in. The manual sign-off ran a 24-item smoke test against the real plugin binary in the actual desktop UI, cross-checking every result directly via psql. It even shook out a real plugin bug along the way (execute_query returned null for enum values instead of the label), fixed upstream and pinned with a new parity test.

The honesty part is the piece built-in-driver users feel too. Several core checks were hardcoded on driver === "postgres", so the plugin's "postgresql" driver id silently fell through to wrong behavior, and issue #614 catalogs the damage: broken identifier quoting, wrong MCP schema defaults, a connection form that lost its host/port layout, and an SSL-mode dropdown that could leave a plugin connection in cleartext without saying so. All of these now key off the driver's declared SQL dialect and capabilities instead of its id, with a migration for already-persisted stale ssl_mode values, and sql_dialect made a true Option so an absent value is no longer silently treated as PostgreSQL. The host stops special-casing its own driver, which is the real architectural milestone: every future driver migration inherits these fixes for free.

Where this goes: the plugin will most likely replace the built-in PostgreSQL driver in an upcoming release. The removal is tracked in #631 and will happen deliberately, not by surprise. In v0.20.0 nothing changes for existing connections: the built-in driver is untouched and remains the default. But you can already try the plugin today: grab a release build from the plugin repository (Linux, macOS, and Windows builds are published per release); one-click install from the Plugin Center is the follow-up. Feedback from real databases now is what makes the eventual switch a non-event.

Binary Data: Hex You Can Read, Keys You Can Delete

Three threads landed on the same theme: binary and keyless data used to fail in opaque ways, and now doesn't.

BLOBs get an inline hex preview and editor (PR #648). Small generic binary values, think BINARY(16) identifiers, now render in the grid as a compact 0x… hex string (up to 64 bytes, then an ellipsis) instead of opaque Base64 transport metadata. In the row-editor sidebar, any complete BLOB up to 10 KiB opens in a monospaced hex editor: uppercase space-separated pairs, whitespace and an optional 0x prefix accepted, odd-length or non-hex input rejected, invalid edits reverted on blur, and the original MIME type preserved on write-back. Larger or truncated BLOBs keep the existing download/file editor, and the backend preview boundary moves from 4 KiB to 10 KiB so everything in the editable range arrives complete, with the truncation check corrected to account for Base64 padding so a truncated value can never sneak into the hex editor.

Rows with binary primary keys can be deleted on MySQL (PR #647, fixes #646). MySQL BINARY values reach the frontend in Tabularis' BLOB wire format, and row deletion passed that representation straight back into the primary-key predicate as a string, which matched nothing. The driver now decodes the wire value first, binds raw bytes on prepared statements, renders hex literals on the text protocol, and carries a Docker-backed regression test against MySQL 8.4.

Keyless-table edits stop tripping over PostgreSQL's type strictness (PR #618). The keyless editing shipped in v0.19.0 identifies rows by all their columns, so the WHERE predicate can target numeric and temporal columns, whose values arrive as JSON strings and were bound as plain TEXT, which PostgreSQL rejects with operator does not exist: numeric = text. The predicate builder now routes known column types through the same numeric and temporal coercions the SET path already used. The same PR adds a small mercy to every failure after this one: the error modal gains a Copy button.

Package-Managed Builds Stop Fighting Their Package Manager

If a distribution packages Tabularis, the in-app updater is at best noise and at worst a fight over who owns the binary. PR #621 (closes #617) lets package maintainers set PACKAGE_MANAGER_SRC and PACKAGE_MANAGER_NAME at build time: the build then skips automatic update checks, disables the built-in installer, and names the managing package manager in the Info settings page, joining the existing Snap and Flatpak detection.

The concrete occasion is a happy one: this was built for Solus, which plans to integrate Tabularis into its own repositories. Solus is an independent, curated rolling-release Linux distribution ("The Personal OS for Personal Computers") with its own package manager, eopkg, and a philosophy of shipping software that works out of the box with sensible defaults. A distribution with that level of curation choosing to package Tabularis natively is exactly the kind of adoption we hoped for, and we're glad to meet them halfway. The feature was tested end-to-end with a real Solus eopkg build, and any other distribution can use the same two variables to ship a build that behaves like a proper citizen of its package manager.

Smaller Things

• Query results survive switching connections (@iamthenuggetman, PR #586, closes #292): switching to another connection and back replaced live tabs with their persisted copies, which are saved result-stripped; the grid came back empty. The storage reload is now skipped when a connection's tabs are already live in memory, which also kills the loading flash on the way back.
• macOS stops autocorrecting your SQL (@iamthenuggetman, PR #634, closes #633): WKWebView inherits Safari's autofill pill, predictive text, autocorrect and spellcheck, and 102 technical fields across 57 files were still exposed. All of them now opt out; the three natural-language prose fields (AI prompts, markdown cells) deliberately keep their spellcheck.
• One failing metadata query no longer takes down a database's tree (PR #638, closes #637): when a server rejects the information_schema.routines lookup, the explorer used to treat the whole expand as failed and retry it forever in a loop. Routine metadata is now optional: tables, views and triggers load, Routines gets an error indicator with the full copyable server error, and failed loads stop auto-retrying unboundedly.
• SQLite generated columns appear, and stay read-only (@DhruvShah-Dev, PR #581, fixes #162): column metadata moves to table_xinfo, so generated columns show up in table grids, flagged as generated and excluded from insert and update paths.
• PostgreSQL Visual Query Builder follow-ups (@DhruvShah-Dev, PR #588): the table list routes through the same reference formatter as FROM generation, HAVING aggregate references are formatted correctly, SELECT aliases are quoted when they need it, and all of it applies to both the postgres and postgresql driver ids.
• Notebook parameters accept ${name} (@fuleinist, PR #602, closes #550): alongside the existing @name, and both syntaxes can mix in one query.
• URI-first connection forms, and FK creation params for plugins (@jonaspm, PR #619): the connection modal optimizes its layout when a driver declares raw-URI connections, and get_create_foreign_key_sql now receives ConnectionParams through the driver trait and the RPC layer, unblocking foreign-key creation in plugins like libSQL.
• Add Row survives an empty table (PR #642, closes #641): an empty result without column metadata used to drop the tab out of data mode, taking the manipulation toolbar and Add Row with it, which made an empty table impossible to fill from the grid.
• Plugin icons finally render (@aesslinger, PR #645, closes #632): getDriverIcon never checked for a URL or data: manifest icon, so every external plugin fell back to the generic plug glyph in 7 of the 8 places icons render. The check now runs first, scheme-matched case-insensitively, and the documented priority holds: connection custom icon, then manifest icon, then built-in fallback.
• Plugins live in the same data directory as everything else (PR #258, closes #257): on macOS and Windows, plugins were stored under a legacy com.debba.tabularis path that contradicted the documented location, so a plugin placed where the docs said was never discovered. Storage is unified under tabularis with a one-time, non-clobbering migration at startup.
• CI stops recompiling the world (@aesslinger, PR #644, closes #640): the test job spent ~6.5 of its ~10 minutes cold-compiling the Rust dependency graph to run 19 seconds of tests; it now reuses the same pinned rust-cache step the release build already trusted.

Thanks

Seven external contributors land in v0.20.0.

@aesslinger carried the biggest change: the PostgreSQL driver's move out of the core, at full parity, plus the host-side dialect and capability fixes (#577), the plugin manifest icon fix (#645), and a CI test job that stopped recompiling everything (#644). @verbaux built the command palette and the unified navigation contract underneath it (#545). @ymadd gave the data grid paste, with the pending-changes batching fix it needed (#612).

@iamthenuggetman kept query results alive across connection switches (#586) and silenced macOS text assistance on every technical field (#634). @DhruvShah-Dev landed three fixes: SQLite generated-column metadata (#581), PostgreSQL Visual Query Builder follow-ups (#588), and the palette's live database selection (#597). @fuleinist added ${name} notebook parameters (#602), and @jonaspm threaded connection params through foreign-key SQL generation for plugin drivers and made URI-first connection forms possible (#619).

If you've ever hit Cmd+V on a grid out of spreadsheet habit and watched nothing happen, worked in split view and had the palette search the wrong connection, or stared at a Base64 blob that you knew was just sixteen bytes, this is the upgrade.

v0.20.0 is available now. Update via the in-app updater, or download from the releases page.

The import was supposed to create 144 child rows, eight for each of 18 parents. It created 83.

Two parents had no children. One parent's first child appeared five times. Two others got 14 and 10 rows instead of eight. Auto-increment IDs from unrelated parents were interleaved. The broken child IDs also fed a schedule table that was supposed to receive 1,008 rows.

There was no useful error. Every SQL statement looked successful in the UI.

This happened in Tabularis v0.10.2 against MySQL. The execution path was open source, which made the failure straightforward to reconstruct once we stopped looking for a mistake in the SQL.

The same file produced the correct data outside the application's multi-statement path. The SQL was not the problem. The transaction was not the problem either, at least not in the way we first suspected.

The application had taken one SQL script and executed it as a collection of unrelated, concurrent database sessions.

The script depended on a session

The original report involved a longer MySQL import, but its essential dependency fits in four statements:

INSERT INTO parent (name) VALUES ('A');
SET @parent_id = LAST_INSERT_ID();
INSERT INTO child (parent_id, name) VALUES (@parent_id, 'A-1');
INSERT INTO child (parent_id, name) VALUES (@parent_id, 'A-2');

This is valid MySQL. LAST_INSERT_ID() returns the auto-increment value generated by the most recent insert on the current connection. User-defined variables such as @parent_id are also scoped to the current session. The MySQL documentation is explicit about both properties: user variables are session-specific, and the server maintains LAST_INSERT_ID() on a per-connection basis.

The word "connection" is doing all the work there.

In the editor, the user had selected one saved connection and clicked Run All. At the UI level, it looked like one destination. At the driver level, that saved connection referred to a pool containing up to ten physical MySQL connections. Those are ten independent server sessions.

There is nothing wrong with that. A pool is supposed to let concurrent work borrow different connections. The bug was treating a sequence that required one session as concurrent work.

Promise.allSettled was the transaction coordinator

The old execution path split the script into statements and mapped each one to a separate Tauri command:

await Promise.allSettled(
  statements.map((statement) =>
    invoke("execute_query", {
      connectionId,
      query: statement,
    }),
  ),
);

That code was originally concerned with result rendering. Each query got its own result tab, execution time and error state. Promise.allSettled was convenient because one failed statement did not prevent the UI from collecting the others.

It also meant every statement started independently.

On the Rust side, every execute_query call did what a normal single-query path should do: resolve the pool and acquire a connection from it.

let pool = get_mysql_pool(params).await?;
let mut conn = pool.acquire().await?;
execute_on(&mut conn, query).await

SQLx returns the connection to the pool when the checkout is dropped. Another statement may later get the same physical connection, but that is an implementation detail, not a guarantee. With several calls in flight concurrently, multiple physical connections are exactly what the pool is there to provide.

The four-statement script could therefore become this:

INSERT INTO parent ...       connection 17
SET @parent_id = ...         connection 24
INSERT INTO child ...        connection 31
INSERT INTO child ...        connection 42

Connection 17 owned the new auto-increment value. Connection 24 could not see it. Connections 31 and 42 could not see the variable set on connection 24.

An uninitialized MySQL user variable evaluates to NULL. Because parent_id in the affected import accepted it, the child insert was still valid SQL. Other pooled connections could carry stale session state from earlier work. Concurrency also removed statement ordering, so a dependent statement could reach the server before the statement it depended on.

The database was doing exactly what each client asked. We had accidentally created several clients.

Why the failure looked healthy

Most database failures are kind enough to produce an error code. This one often produced plausible data.

The statements were individually valid. A child row with a nullable or incorrect foreign key can still be inserted. Promise.allSettled waited for every invocation and let the interface render successes alongside failures. Worse, the MySQL, PostgreSQL and SQLite execution paths were returning affected_rows: 0 for every non-result statement, regardless of what the server reported.

So a successful insert and an insert that did nothing had the same summary: zero rows affected.

That hardcoded value did not cause the session bug, but it removed one of the few signals that might have exposed it. It was fixed in the same change.

This is a particularly unpleasant class of corruption because the output retains structure. Eight missing rows are easy to notice. Sixty-one missing rows spread across several parents, mixed with duplicates and valid inserts, look like an error in the source data or in the import logic. By the time somebody counts the records, the script is no longer running and the pool has long since returned every connection.

Serial execution is necessary, but not sufficient

The obvious first fix is to replace Promise.allSettled with a loop:

for (const statement of statements) {
  await invoke("execute_query", { connectionId, query: statement });
}

That restores ordering. It does not restore session identity.

Each invocation still calls pool.acquire(). The pool is free to return connection 17 for the first statement and connection 24 for the second. Under light load it may happen to return the same idle connection repeatedly, which is worse than a deterministic failure because the broken implementation appears correct in development.

There are two separate invariants:

1. Statement B must start after statement A finishes.
2. Statement B must execute in the same database session as statement A.

Awaiting each query gives you the first. Holding one connection for the lifetime of the script gives you both.

This distinction matters far beyond SQL editors. Any abstraction that accepts a pool and exposes a sequence of calls can get it wrong: migration runners, background jobs, import tools, home-grown transaction helpers and repository layers. If the API does not make connection affinity visible, a loop can look safe while still changing sessions between iterations.

The fix was one checkout, then a loop

We replaced the per-statement command fan-out with one execute_query_batch call. The built-in drivers acquire one physical connection before the first statement and keep it until the last result has been collected.

The core of the fix is deliberately boring:

let mut conn = pool.acquire().await?;
let mut results = Vec::with_capacity(statements.len());

for statement in statements {
    let result = execute_on(&mut conn, statement).await;
    results.push(result);
}

Ok(results)

The important part is not the loop. It is where acquire() sits.

Previously it was inside execute_query, so it ran once per statement. In the batch path it runs before the loop, so all statements share the same checked-out connection. The UI still receives one result per statement and can show partial failures, but execution order and session state now agree with what Run All means to a person reading the script.

MySQL, PostgreSQL and SQLite each implement the batch operation against their native connection type. External plugin drivers get a sequential default implementation for compatibility, but must override it if they promise connection-local continuity. That limitation is documented in the driver trait rather than hidden behind a method named execute_batch.

The full change is in commit 8eed14b2. The original report, including the damaged row counts and minimal reproduction, is issue #199.

Fixing the connection exposed a protocol problem

Keeping one connection alive made transactions structurally possible, but MySQL added another constraint.

SQLx normally sends sqlx::query() through MySQL's prepared-statement protocol, using COM_STMT_PREPARE and COM_STMT_EXECUTE. In our path, preparing transaction control still surfaced MySQL error 1295 on commands outside the protocol's supported set. MySQL documents COMMIT as preparable, but does not list the whole family, including BEGIN, START TRANSACTION and savepoint operations.

The driver now routes the complete transaction-control family through the text protocol with sqlx::raw_sql(), which uses COM_QUERY. Regular statements continue through the prepared path. Sharing a connection was the semantic fix; selecting the correct wire protocol was required to make explicit MySQL transactions actually use it.

This was not visible while every statement had its own connection. A transaction could not work correctly in that model anyway. Removing one broken assumption exposed the next one.

Testing session identity instead of query success

The regression tests do not merely assert that each statement returns Ok. That was already happening when the data was wrong.

The MySQL test creates a parent, stores LAST_INSERT_ID() in @pid, inserts two children and then verifies that both children reference the parent that was just created. A second test wraps two inserts in BEGIN and COMMIT and checks the committed rows.

The PostgreSQL test uses a temporary table:

BEGIN;
CREATE TEMP TABLE batch_tmp (id serial primary key, value text);
INSERT INTO batch_tmp (value) VALUES ('a'), ('b'), ('c');
SELECT count(*) FROM batch_tmp;
COMMIT;

PostgreSQL requires each session to create its own temporary table. A later statement on another connection cannot see it. That makes the table a useful assertion about session identity, not just query ordering. PostgreSQL also exposes pg_backend_pid(), while MySQL exposes CONNECTION_ID(), if you want a minimal diagnostic that prints the server session used by each statement.

These are integration tests against live MySQL and PostgreSQL instances, so they are ignored in the ordinary unit test run. That is worth stating because a test existing in a repository is not evidence that somebody ran it against a server. The issue reproducer and the fixed execution path are the primary evidence; the tests preserve the invariant for future driver changes.

A script is a conversation

Connection pools encourage a useful mental model: take a connection, perform one independent unit of work, return it quickly. Problems start when "independent" is inferred from an API boundary instead of from database semantics.

These operations all depend on session identity:

• BEGIN, COMMIT, savepoints and transaction-scoped locks
• MySQL user variables and LAST_INSERT_ID()
• PostgreSQL currval() and prepared statements
• temporary tables
• session settings such as search_path, sql_mode or FOREIGN_KEY_CHECKS
• advisory locks and other connection-owned resources

A pool may choose any suitable connection for the next operation. It cannot infer that two strings originated from the same editor buffer, migration file or job. If continuity matters, the application has to express it by holding a connection or transaction handle across the whole unit of work.

That is the general lesson from this bug:

A SQL script is not a Vec<String>. It is a conversation with one database session.

We had preserved the strings and discarded the conversation. The database accepted every sentence. It was listening on four different calls.

v0.19.0 follows v0.18.0 and is a release about guardrails. The headline teaches connections which environment they belong to — with a permanent red banner and a confirmation before any write while you're on production — and adds free-form colored tags for organizing everything else. The results grid learns to render password, token and email columns as •••••• until you deliberately reveal them. The oldest editing limitation in the data grid falls: tables without a primary key accept cell edits, NULLs and row deletions instead of silently ignoring you. Underneath, the plugin pipeline closes most of its feature gap with the built-in drivers, plugin installs stop being able to clobber a working installation with a corrupt archive, and the Linux AppImage stops shipping the stale libwayland that produced black windows on up-to-date distros.

Tags, Environments, and a Warning Before You Write to Production

Every connection list eventually turns into a minefield: the local scratch database and the customer-facing one sit two rows apart, distinguished by nothing but a name. PR #473, from @pokertour, closes #472 with two complementary features, following the DBeaver model.

Free-form colored tags. Tags live in connections.json alongside groups; connections carry a list of tag ids. The connection modal's appearance tab gets a tag picker with inline creation on the shared accent palette and a manage mode to rename, recolor or delete. Tags render as colored chips on connection cards and list rows, and tag names participate in the connection search filter. They also ride along in export, import and backups — selective exports only include the tags actually used, and imports merge by id first, then by name, remapping tag_ids onto the existing tag. Re-creating "prod" on another machine never duplicates it.

Environment classification. Each connection can optionally declare itself development, staging or production, picked in the modal title bar and preserved across duplicate and import. Production identity is loud on purpose: a PROD badge on cards and rows, a red ring on open sidebar entries, and a permanent red banner while the active connection is production.

The write guard. Any statement that isn't provably read-only prompts for confirmation on a production connection, with a SQL preview and a per-connection "don't ask again" that lasts for the session. Detection is deliberately conservative — only SELECT, SHOW, DESCRIBE, PRAGMA and EXPLAIN of a SELECT count as read-only. Data-modifying CTEs, EXPLAIN ANALYZE <write> (which executes the write on PostgreSQL) and unknown statement types like CALL or SET all prompt. The guard covers editor runs, staged grid-edit commits, immediate cell edits, row insertion and notebook cells, and it stacks with the destructive-query guard from v0.14.0 rather than replacing it.

Sensitive Columns Come Up Masked

Screen-sharing a results grid used to mean hoping nobody could read fast. PR #587, from @iamthenuggetman, closes #485: columns whose name matches a sensitive pattern — password, email, token, ssn and friends — now render as a •••••• placeholder in the results grid.

• Per-cell reveal. A masked cell shows an eye button that reveals just that cell; revealed cells get an eye-off to re-mask. Column headers carry the same toggle for the whole column. Reveal state is grid-local and resets when the result data changes.
• The mask actually holds. Masked cells can't be edited — double-click, Enter and F2 are guarded until you reveal — and the hover tooltip is suppressed so it can't leak the value.
• Display-only, by design. Copy and export keep the real values, as the issue requested; write-path anonymization for exports is tracked separately in #483.

Configuration lives in a new Settings → Privacy tab: an on/off toggle (default on), the column-name patterns as an editable list of case-insensitive substring matches, and per-connection overrides as table.column entries — Always mask and Never mask lists per connection, where never-mask wins over always-mask, which wins over the name patterns. A review round moved the per-connection overrides into the connection modal as well, so a saved connection can manage its own exceptions from a Privacy tab in edit mode. Strings are translated across all eleven locales.

Tables Without a Primary Key Are Now Editable

A table with no primary key refused every edit and never said why: double-click did nothing, the row-editor sidebar accepted input but never showed a submit button, and Set NULL, Set EMPTY and Delete Row were silent no-ops. This wasn't a regression — row addressing has always required primary-key columns, and every path that needed them bailed out silently. PR #600 (closes #598) makes keyless tables editable, carefully.

Rows of a keyless table are now identified by the values of all their comparable columns. Binary, geometric, json and hstore columns are excluded — their grid representations wouldn't survive an equality comparison — and so are approximate numerics (FLOAT, DOUBLE, REAL), whose stored values may not match the grid's decimal rendering. Excluded columns stay editable; they just don't take part in addressing. The fallback only activates when the result set exposes every physical column of the table: a partial SELECT a, b FROM t stays non-editable, because it couldn't distinguish rows that differ only in the omitted columns — and the grid now says so in an explanatory alert instead of ignoring the double-click.

The mechanics are fussy and worth getting right. Without a key, each UPDATE invalidates the value its own WHERE clause will need next time, so updates to the same row run sequentially with already-applied values threaded into each step. Columns set to DEFAULT — whose stored result the client can't know — are ordered last and dropped from later WHERE maps, so applying DEFAULT to two columns of one row works instead of failing halfway. Deletions repeat until every duplicate the grid marked is gone: MySQL and MariaDB delete one copy per statement with LIMIT 1, PostgreSQL and SQLite sweep identical rows in one statement, and every driver converges on the state the grid displayed. And when the row no longer matches — someone changed the data underneath you — a zero affected-rows result raises a clear error instead of pretending it worked.

On the driver side, the pk map can now legitimately carry a whole row: NULL entries render as IS NULL instead of being rejected, booleans bind natively across MySQL, PostgreSQL and SQLite, and MySQL updates and deletes by pk map carry LIMIT 1 so duplicate rows are never swept by a single statement. The changes were verified live against MySQL 8.4, PostgreSQL 16, SQLite, and a MariaDB 11 container loaded with the reporter's actual dump.

The Plugin Pipeline Closes the Gap

Five threads landed this cycle that together move plugin drivers from "supported" toward "indistinguishable from built-in".

BLOB, materialized views and type mappings reach plugin drivers (@aesslinger, PR #576). The RPC adapter now forwards save_blob_to_file and fetch_blob_as_data_url — the plugin writes the file directly, since it runs on the host machine — plus all four materialized-view methods. A plugin that doesn't implement a method returns JSON-RPC -32601 and the host falls back to the existing "not supported" error, so nothing changes for current plugins. A new optional type_mappings manifest field lets a plugin resolve map_inferred_type() locally, which matters because that method is synchronous and can't issue an RPC call. These are the prerequisites for migrating the PostgreSQL driver itself to a plugin (#16).

Plugins get their own connection fields (@fuleinist, PR #596). ConnectionParams gains an opaque extra string map — persisted verbatim, forwarded to the driver, absent from JSON when empty — and a new connection-modal.extra_fields slot renders plugin UI below the host/port section, with setExtraField(key, value) to edit the map. The concrete beneficiary is the DynamoDB plugin, which needs an AWS region without asking core for a schema change. The host API version moves to 0.2.0.

Plugin READMEs open in the app (PR #615). Deciding whether to install a plugin used to mean a detour to GitHub. A WordPress-style details modal now shows the plugin's README — from the connection install gate and from every Plugin Center card the registry knows. The registry serves the README locale-aware, relative image and link paths are resolved against the plugin's repository, the HTML is sanitized with DOMPurify, and links open in the OS browser. The install gate also declutters: while the driver isn't installed yet, the connection-name input and environment selector stay out of the way.

A bad archive can no longer eat a good install (PR #609). The manifest id and version are now verified against what the registry advertised while the bundle is still in the temp directory — previously the check ran after the archive had already replaced the plugin folder, so a corrupt download could wipe out a working installation. Uninstall resolves plugins by manifest id even when the folder name differs, and the install-error modal gains "Open plugins folder" and "Reload plugins" buttons, so a broken half-install is recoverable from the UI instead of requiring a restart and a file manager safari.

.tabularium is the canonical manifest, and the scaffold finally validates (@NewtTheWolf, PRs #594 and #595). The manifest create-plugin scaffolded failed live registry validation on four counts — missing engine and paradigms, a forbidden id field, and a display name where the slug belongs. It now renders a manifest the registry accepts, and the in-repo plugin docs stop describing the old manifest.json world: slug name, optional legacy id, publishing pointed at registry.tabularis.dev/submit. Relatedly, the twelve plugins already migrated to the hosted Tabularium registry were removed from the legacy registry.json, which keeps only the five not yet migrated — and the MongoDB Atlas entry now points at the official TabularisDB repository and its published v0.1.0 release (@Robbyfuu, #496).

The AppImage Stops Bundling a Time Bomb

If Tabularis gave you a black window on Arch or Solus since v0.13.3, this is the fix. The AppImage bundled the build container's libwayland (Ubuntu 22.04, ~1.20); on distros with a recent Mesa, the host libEGL bound to that stale libwayland-client, protocol marshalling mismatched, and WebKitWebProcess aborted with EGL_BAD_PARAMETER. This is a known-enough failure class that the upstream AppImage excludelist added libwayland-client.so.0 for exactly this reason — but the linuxdeploy binary pinned by tauri-cli predates that entry, and upstream has declared the linuxdeploy bundler unmaintained.

PR #599 (fixes #423) attacks the root cause and the process failure behind it. The stable build path pre-seeds a patched linuxdeploy-plugin-gtk.sh that strips libwayland-*.so* from the AppDir before the squashfs is packed — the produced AppImage contains zero libwayland files where v0.18.0 shipped four. And release.yml is rewritten as a thin dispatcher over the same reusable build.yml matrix the nightlies use, because the regression existed at all only because the two workflows had drifted apart: nightlies kept a working configuration for months while releases shipped the broken one. Two channels, one build definition, no more drift.

Smaller Things

• The MySQL Visual Query Builder qualifies its tables (@DhruvShah-Dev, PR #582, fixes #480) — tables dragged from the sidebar keep their schema, and generated FROM and JOIN clauses are schema-qualified, so a query built against a non-default database runs instead of erroring on the wrong one.
• Visual EXPLAIN understands parameterized queries (@DhruvShah-Dev, PR #580, fixes #565) — explaining SQL with @params now opens the same parameter modal the editor uses, reuses saved tab values when complete, and saves submitted values back to the tab. A follow-up fix gave the modal's submit button a label that exists in the locale files instead of a raw i18n key.
• SQLite paths starting with ~ work (@DhruvShah-Dev, PR #579) — ~/ and ~\ are expanded before file validation, shared between pool creation and new-database creation, so a home-relative path no longer fails as "file not found".
• Closing your last connection sticks (@fuleinist, PR #578, closes #548) — the persistence effect skipped empty states, so disconnecting everything and quitting brought the connections back on next launch. Empty is now a state worth saving too.
• Engine cards in the connection catalogue got a cleanup (PR #605) — cards are titled after the engine with proper spellings (PostgreSQL, MongoDB Atlas, SQL Server) instead of whichever plugin sorts first, the layout stops truncating names and clipping the meta line mid-word, the unavailable badge shrinks to one word with the full sentence in a tooltip, and a registry icon that fails to load falls back to the generic database icon.
• The DynamoDB plugin reached v0.1.5 (@fuleinist, PR #607) — two registry bumps this cycle, the latest adding the official DynamoDB brand icon to the manifest.

Thanks

Seven external contributors land in v0.19.0.

@pokertour built the headline feature for the second release running: colored tags, environment classification and the production write guard (#473). @iamthenuggetman gave the results grid column masking with per-cell reveal and a Privacy settings tab (#587). @fuleinist added plugin-owned connection fields to ConnectionParams (#596), fixed disconnects that didn't persist (#578), and kept the DynamoDB plugin moving (#607).

@aesslinger closed the plugin driver feature gap with BLOB, materialized-view and type-mapping forwarding (#576). @DhruvShah-Dev landed three fixes: schema-qualified MySQL visual queries (#582), parameters in Visual EXPLAIN (#580), and SQLite home-path expansion (#579). @NewtTheWolf made the plugin scaffold pass registry validation and rewrote the manifest docs around .tabularium (#594, #595). @Robbyfuu pointed the MongoDB Atlas registry entry at the official release (#496).

If you've ever run a script against production that you meant for staging, screen-shared a grid full of email addresses, or double-clicked a cell in a keyless table and watched nothing happen — this is the upgrade.

v0.19.0 is available now. Update via the in-app updater, or download from the releases page.

Heads up for Arch users: after the malware wave that hit 200+ AUR packages, the Arch team temporarily disabled package adoption. Our tabularis-bin package is unaffected and still on the AUR, but a few of you asked how to install without going through an AUR helper. Fair enough, and honestly it's the safer habit anyway since you get to read the PKGBUILD before it builds anything.

Building straight from our repo

You can build straight from our GitHub repo, the PKGBUILD lives in the aur/ folder:

curl -O https://raw.githubusercontent.com/TabularisDB/tabularis/main/aur/PKGBUILD
sed -i 's/^pkgver=.*/pkgver={{APP_VERSION}}/' PKGBUILD
updpkgsums          # fills in the real sha256, needs pacman-contrib
less PKGBUILD       # read it, that's the whole point
makepkg -si

The version in the repo is a placeholder (x.y.z) because our release workflow substitutes it, so set it to whatever the current release is ({{APP_VERSION}} at the time you're reading this). All it does is pull our official .deb from the GitHub release and unpack it, nothing exotic.

If you'd rather skip makepkg entirely, the .deb and the AppImage are right there on the releases page, both signed.

Read the PKGBUILD — every time

Whatever you install from the AUR these days, take thirty seconds to read the PKGBUILD:

• check that source= points at the real upstream,
• be suspicious of any curl or wget inside prepare()/build(),
• and of post_install hooks.

If you did install one of the compromised packages, assume the box is dirty and rotate your SSH keys and API tokens.

Article with the details: Arch Linux disables AUR package adoption to stop malware flood (BleepingComputer).

v0.18.0 follows v0.17.0 and moves the attention from reading a database to administering and reaching one. The headline is a full Users & Privileges view for MySQL and MariaDB — list accounts, create them, edit grants scope by scope — contributed from outside the core team. Around it, the connection modal stops failing with one truncated red line: it tests the SSH tunnel on its own, classifies what went wrong, streams the steps as they run, and hands you a copyable diagnostics report. A connection can now be saved with no database selected at all and browse whatever the server has. The data grid gains arrow-key navigation, discoverable select-all, and copy actions that are explicit about whether they cover the page or the whole result. The ER diagram exports to Mermaid and DBML and stops stacking wide tables on top of each other. And PostgreSQL learns to write hstore back.

Users & Privileges for MySQL and MariaDB

Tabularis could read your schema in detail and tell you nothing about who was allowed to read it. PR #478, from @pokertour, adds a Users & Privileges tab, opened from the Explorer sidebar on any connection whose driver declares the user_management capability — today MySQL and MariaDB.

• The account list shows every server account with its locked flag, and degrades gracefully: when mysql.user isn't readable, it falls back to CURRENT_USER rather than showing an empty pane.
• Create, change password, drop — creation can grant an initial set of privileges on a chosen scope in the same step, and dropping asks for confirmation first.
• The privilege editor renders one card per scope — global, database, table — with checkboxes reflecting the parsed output of SHOW GRANTS. Checking grants, unchecking revokes, and the editor revokes before granting so narrowing ALL PRIVILEGES down to a subset actually works.
• Nothing is hidden. Grants the editor can't model — roles, column-level privileges, proxy grants — are kept and shown as the raw SHOW GRANTS output, so the UI never implies a privilege set it isn't representing.

The SQL builders validate every privilege against a per-scope allow-list and escape literals according to the server's sql_mode; builders and the grant parser are unit-tested. Just as importantly, the design is extensible rather than MySQL-shaped: the privilege catalog comes from the driver, and all seven trait methods are forwarded over JSON-RPC, so an external plugin can opt in via capabilities.userManagement. PostgreSQL support is the planned follow-up.

The Connection Test Tells You Where It Failed

Connecting through a tunnel used to fail in the least useful way possible: one truncated red line in the modal footer, no indication whether the SSH hop, the port-forward or the database handshake was the thing that broke, and a 3-second auto-reset that raced you while you were still reading it. PR #570 rebuilds that whole path.

• Test SSH, on its own. A dedicated button in the SSH tab verifies host, credentials and tunnel without touching the database. The success state invalidates the moment you edit any SSH field, and a Stop button abandons a test that hangs. For a saved connection whose SSH secrets live in the keychain under the database connection id, the test resolves them correctly — unless you've edited the password field, in which case it tests exactly what you typed.
• Errors get a category. A new classifier maps raw backend strings onto ssh-auth, ssh-unreachable, ssh, db-auth, network and db-not-found, each with a translated summary and an actionable recovery hint. Credentials embedded in raw error text are redacted. With a tunnel active, "connection refused" is attributed to the tunnel rather than blamed on the database host — which is the single most common misdiagnosis in this whole flow.
• The steps stream live. test_connection now emits progress events — sshTunnel → k8sForward → dbConnect, with start/ok/error per step and a per-run id so a superseded run's late events are discarded. The footer shows the current step, so a hanging test tells you where it hangs instead of just spinning.
• A diagnostics modal opens on failure or on Stop: classified summary, recovery hint, timestamped step log, sanitized raw error, and a copy-to-clipboard report worth pasting into an issue. A "Show log" link reopens it.

All new strings are translated across the eleven supported locales.

All-Databases Mode: Leave It Empty to Browse Everything

Until now a multi-database connection had to name its databases up front, and every new database on the server meant editing the connection. PR #572 makes an empty selection meaningful: the Databases tab gains a mode switch between All databases — the default for new connections — and Choose databases, and the "select at least one database" save block only applies to the explicit mode.

An all-databases connection persists an empty database param and resolves the real list at connect time through get_available_databases. New databases appear on their own, dropped ones disappear, and the sidebar refresh button re-syncs without persisting anything, toasting what was added and removed. Narrowing to a subset from the sidebar's manage popover persists that choice and exits the mode. Pasting a connection URI with no database in it switches to all-databases mode automatically.

Two smaller consequences worth naming. Editing an all-databases connection no longer auto-fetches the database list when the dialog opens — which could silently spawn an SSH or Kubernetes tunnel just because you clicked Edit. And the seven scattered selectedDatabases.length > 1 checks that decided whether to show the multi-database layout are replaced by one shared helper keyed on "is there a runtime selection at all", so a connection with a single database still issues database-qualified queries — it has no default schema — and a multi-database connection narrowed to one database keeps its tree and manage button instead of losing them.

The Data Grid Gets a Real Selection Model

Three pieces landed here, and together they change how the grid feels under the hands.

Select All becomes discoverable, and copying becomes explicit (@iamthenuggetman, PR #549, closes #546). Select-all already existed behind a click on the # header cell — undiscoverable, and it silently wrote to the clipboard. Now Cmd/Ctrl+A selects all loaded rows (guarded to the last-interacted grid, since a notebook mounts one grid per cell, and never inside a text input or an open cell editor), the row context menu carries a Select All / Deselect All entry, and selection is cleanly separated from copying. Copy Selected (N) and Copy All (M) sit next to each other as a pair, and Copy All re-runs the query unpaginated with the tab's total-limit clause stripped, preserving the on-screen sort order — so "all" means all. Every copy path toasts its row count, and a page-only copy of a larger result says "Copied N of M", so a partial copy is never silent.

Selection extends past whole rows. The same PR adds DBeaver-style multi-column selection — Cmd/Ctrl+click a header to toggle, Shift+click to range-select, plain click still sorts — and cell range selection via Shift+click, which highlights a rectangle and offers a Copy Range (R×C) entry. Row, column and cell-range selections are mutually exclusive, so what Cmd/Ctrl+C copies is never ambiguous.

Arrow keys move the focused cell (@ymadd, PR #552, closes #551). The grid has tracked a focused cell for a while, but only a click could ever move it. Now the arrow keys move one cell clamped at the edges, Home/End jump to the first and last column of the row, PageUp/PageDown move a viewport of rows, and Enter/F2 open the focused cell for editing through the same path as a double-click. The first keypress in a grid with no focused cell enters at the top-left. The handler is bound to the scroll container rather than to document — otherwise every mounted grid in a notebook would move at once — and keys are left alone for anything that handles them itself: text inputs, the FK and BLOB buttons inside cells, and the sortable column headers.

The Run Button Says What It Will Run

With no selection, Run and Cmd/Ctrl+Enter execute only the statement under the cursor. The button said "Run" regardless, so pasting a multi-statement script and pressing Run executed one statement and skipped the rest — no error, no warning, nothing in the UI admitting it. @ymadd hit this against a production database: a 21-statement script where only the statement the caret landed in ran, surfacing later as a foreign key violation because the parent rows the rest of the script depended on were never inserted.

PR #532 labels the button with its actual target: Run Selection when text is selected, Run Statement when the buffer holds several statements and nothing is selected, plain Run otherwise. Behaviour is untouched — this only makes it visible before you commit to it. And when the button would run one statement out of several, the tooltip surfaces Run All (Cmd/Ctrl+Shift+Enter), a shortcut that was already bound and mentioned nowhere. The decision lives in one pure function, resolveRunTarget, so the label can't drift from the behaviour it describes.

Editor Tabs Reorder by Drag

PR #517, from @maximumbreak, makes the editor tab bar draggable. Console, table, query-builder and notebook tabs all share one flat tabs array, so any tab type can be dragged — no console-only restriction — and reordering is scoped to the active connection: dragging reshuffles only that connection's tabs and leaves everyone else's slots alone. It reuses the native HTML5 drag-and-drop pattern already behind notebook cell reordering, down to the edge auto-scroll and the insertion-line indicator, and needs no new persistence code, because the existing tab-save effect already writes to preferences.json whenever the tabs array changes.

A follow-up fix renders editor panes in a stable order, so a reorder can't shuffle which pane is which.

The ER Diagram Exports, and Stops Overlapping

Export to Mermaid or DBML (@gcapellib, PR #521) — the ER diagram had no export at all. An Export button now generates two text formats from the schema data already in memory, no new dependency. Mermaid (erDiagram) renders natively on GitHub, GitLab and most docs tools, so the output pastes straight into a README, at the cost of entity-level relationships where the FK column is only a label. DBML keeps relationships at column level (Ref: orders.client_id > clients.id) and round-trips through dbdiagram.io and dbml-to-sql, with composite primary keys expressed via an Indexes block. The same PR fixes a permissions bug that made every permission-gated call fail in the ER diagram window: the capability allow-list named the literal window er-diagram, while the window is actually created as er-diagram:{connectionId}:{database}:{schema}.

Nodes stop landing on top of each other (PR #558) — the dagre layout was fed a fixed 240px width for every node, but the table node only has a minimum width and grows with its content, so a table with a wide enum(...) column overlapped its neighbours. Node width and height are now estimated from the actual content, the real width is used when centering, and node separation gets a little more room. The same PR adds a lock toggle for pinning a node where you dragged it.

PostgreSQL: Editable hstore, Expression Indexes, Catalog-Based Keys

Four PostgreSQL fixes land this cycle, three of them from outside the core team.

hstore columns are editable (@arturbent0, PR #427, closes #395) — reading worked, writing failed with "Cannot bind a JSON object to a non-JSON column", because hstore has no fixed OID and information_schema reports it as a generic USER-DEFINED. The driver now resolves the real per-column hstore OID through pg_type before binding and binds JSON objects as a string map, which the client encodes natively. udt_name is exposed on the column metadata so the frontend can identify hstore precisely — data_type can't, since every extension type shares it — and hstore columns route through the JSON editor in the row-editor sidebar. As a bonus, the inline cell editor stops showing [object Object] for any object-valued cell.

Functional and expression indexes render (@Davydhh, PR #499) — an index like CREATE INDEX ON users (lower(email)) was invisible. Every driver dropped expression columns for its own reason: Postgres joined pg_attribute on an attnum that expression columns don't have, MySQL and SQLite only read plain column names. Mixed indexes lost their expression columns and all-expression indexes vanished from the sidebar entirely. The expression text is now recovered per driver — pg_get_indexdef, information_schema.STATISTICS.EXPRESSION, and SQLite's CREATE INDEX DDL — with an is_expression flag so DDL export emits the expression raw instead of identifier-quoting it. MySQL's EXPRESSION column only exists from 8.0.13, so the driver probes for it and falls back on MariaDB and older MySQL.

Key metadata survives a read-only user (@DhruvShah-Dev, PR #543) — primary-key detection read information_schema.table_constraints, which returns nothing for users who can nonetheless see pg_constraint. Detection moves to a pg_catalog query, reused across single-table, batch-table and view column loading.

The Visual Query Builder quotes reserved identifiers (@DhruvShah-Dev, PR #553) — generated SQL emitted raw table and column references, so a perfectly legal table named user or order produced a query PostgreSQL rejected. The generator now takes the active driver and quotes identifiers when the dialect requires it.

Create a SQLite Database from Inside the App

PR #523, from @Jishnu-Prasad888, addresses #131: you can now create a SQLite database without leaving Tabularis. New SQLite Database… appears in the Connections menu and empty state, and the SQLite file picker in the connection modal gains a + New button. The quick-create flow auto-names the file and opens it; the modal flow just fills in the path and leaves the usual Test/Save alone.

The safety rules are the interesting part: existing files are never overwritten, create_if_missing stays disabled so a typo in a path can't silently conjure an empty database, failed quick-creates clean up after themselves, and duplicate connections are prevented.

Notebook SQL Generation, Hardened

PR #559 started as a README correction and turned into a security pass on how notebooks generate SQL.

• Parameter values are inserted literally. They were passed as the replacement string to String.replace, so a value containing $&, $' or $$ was expanded as a replacement pattern — quietly producing SQL that differed from what you were shown.
• Cell-reference CTEs escape their identifiers. Column names were interpolated into quoted identifiers without doubling embedded quotes, so a crafted column alias in a referenced cell could break out of the identifier and inject arbitrary SQL into the generated CTE.
• MySQL and MariaDB string values escape backslashes, not just single quotes.

The README also described a notebook syntax that never existed. The real syntax is {{cell_N}}, expanded to a CTE at run time, and @paramName — documented correctly now, closing the documentation half of #550.

DynamoDB in the Plugin Registry

@fuleinist registered tabularis-dynamodb-plugin in the official registry (PR #574) and shipped it to v0.1.3 within the same cycle (PR #589). The two fixes in between are the kind you only find against a real account: get_tables issued its DescribeTable calls serially, so an account with hundreds of tables took over a minute and blew the GUI's connection timeout — describes now run with bounded concurrency and results are re-sorted to preserve ListTables ordering. And execute_query responses now carry a complete pagination object instead of only a next_token, which the app was rejecting outright.

Install it from the connection catalogue when creating a new connection; it requires Tabularis 0.15.0 or newer and ships builds for Linux and macOS on both x64 and arm64, plus Windows x64.

Smaller Things

• MariaDB temporal tables appear in the tree (@gustavomelo-dotgroup, PR #568) — the MySQL driver filtered information_schema.tables on table_type = 'BASE TABLE', but MariaDB reports tables created WITH SYSTEM VERSIONING as SYSTEM VERSIONED. They were silently excluded from the explorer with no error anywhere, making it look like the tables didn't exist. Both types are now accepted.
• Raw connection URIs reach plugin drivers (@Robbyfuu, PR #495, closes #494) — pasting a real MongoDB Atlas connection string failed on the import path, starting with the protocol being rejected outright because the protocol registry only derived protocols from two per-driver sources. Plugin drivers now receive the URI as given, mongodb+srv:// included.
• Array cells open the JSON editor (@Davydhh, PR #489) — double-clicking a text[] or uuid[] cell opened the inline textarea, which renders String(array) and crams the values into a comma-joined string in a 120px box. Array cells already rendered as JSON; now they edit that way too, in the same dedicated viewer window json/jsonb columns use.
• DML submits against the right schema (@DhruvShah-Dev, PR #542) — inserts, updates and deletes now use the table tab's schema on schema-capable drivers, while multi-database drivers keep receiving the tab value as the database.
• The connection modal keeps a stable height (@DhruvShah-Dev, PR #538, fixes #462) — the dialog is bounded to the viewport and driver-specific form content scrolls inside it, so switching between MySQL, PostgreSQL and SQLite no longer resizes the whole modal under your cursor.
• Sidebar accordion actions stop crowding the scrollbar (@DhruvShah-Dev, PR #539, fixes #310) — section headers reserve a padded action lane, so long titles truncate instead of squeezing the refresh and add buttons.
• The MCP approval modal stops blanking the window (PR #567, fixes #566) — the preflight stored the driver's raw explain output verbatim, and the approval modal cast it straight to a parsed plan. The object is truthy, so the plan view rendered and then walked an undefined root: black window, approval impossible, MCP request timing out after 120s — and a crash loop on restart, since the pending approval was replayed. The payload now goes through the same client-side resolver everything else uses.
• MiniMax regional endpoints (@octo-patch, PR #498) — the current OpenAI- and Anthropic-compatible endpoints are defined for both the global and cn_zh regions, and model listing tries both official regional endpoints so mainland China API keys work.
• JetBrains Mono ExtraBold, bundled (@GabrielMalava, PR #547) — two more weights of a typeface already in the font picker, shipped locally rather than fetched. Selecting a freshly bundled font also forces Monaco to re-measure its glyph widths: it measures once and never re-measures when a webfont finishes loading, so the editor used to render the new font with stale fallback metrics.
• Third-party GitHub Actions pinned to commit SHAs (@jeffersongoncalves, PR #540) — every third-party action reference is pinned to a full 40-character SHA with the resolved tag kept as a comment. A tag-pinned action can be silently re-pointed at malicious code by a compromised maintainer, which is exactly what happened to tj-actions/changed-files in March 2025. A dependabot.yml now keeps those pins moving, and the first four bumps (#554, #555, #556, #557) landed in this release.
• Nightly version numbers make sense again (PR #585) — the counter after the dash was github.run_number, monotonic per workflow and never reset, so the first nightly after v0.17.0 was 0.17.1-18 and gaps appeared on runs where the gate decided no build was due. It's now derived from the highest suffix already published for the current version base.

Thanks

Fifteen external contributors land in v0.18.0.

@pokertour built the release's headline feature: user and privilege management for MySQL and MariaDB (#478), designed from the start so plugin drivers can opt in. @iamthenuggetman gave the data grid a real selection model — discoverable select-all, explicit copy scopes, multi-column and cell-range selection (#549). @ymadd contributed both keyboard navigation in the grid (#552) and the Run button that admits what it's about to run (#532), the latter written up from a production incident.

@DhruvShah-Dev landed four fixes: PostgreSQL key metadata from pg_catalog (#543), Visual Query Builder identifier quoting (#553), DML schema selection (#542), and the connection modal and sidebar accordion layout fixes (#538, #539). @gcapellib added ER diagram export to Mermaid and DBML and fixed the window permissions bug behind it (#521). @Davydhh made functional and expression indexes visible across every driver (#499) and routed array cells to the JSON editor (#489).

@arturbent0 made PostgreSQL hstore columns editable (#427). @maximumbreak made editor tabs draggable (#517). @Jishnu-Prasad888 added SQLite database creation (#523). @gustavomelo-dotgroup found the table_type filter hiding MariaDB temporal tables (#568). @Robbyfuu got raw connection URIs through to plugin drivers (#495). @jeffersongoncalves pinned every third-party action to a commit SHA (#540), @octo-patch fixed MiniMax regional endpoints (#498), @GabrielMalava bundled two more JetBrains Mono weights (#547), and @fuleinist registered and hardened the DynamoDB plugin (#574, #589).

If you've ever had a connection through a tunnel fail with one unreadable red line, wanted to grant a colleague SELECT without opening a terminal, or pressed Run on a 20-statement script and watched one statement execute — this is the upgrade.

v0.18.0 is available now. Update via the in-app updater, or download from the releases page.

Last week I wrote about why Tabularis runs on Tauri. That post was about the frame: a Rust backend, a web frontend, and the seams between them. It said almost nothing about what the Rust side is actually made of.

This post is the guided tour. The compressed 0.17.0 release artifacts range from 12 MB (the Windows NSIS installer) to 17 on Linux and 18 on macOS; the Windows MSI sits at 15.8. Roughly fifteen is useful shorthand for the download, not a claim about the larger installed footprint.

The main [dependencies] table in Cargo.toml has 53 entries, before platform-specific and build dependencies. Most looked free the day they entered the tree. None stayed free, because dependencies are also boundaries — to protocols, platforms, formats and other people's decisions.

Every abstraction boundary is a decision, and every decision eventually sends an invoice.

Here are the invoices I found worth reading twice.

Two database stacks, on purpose

The most common assumption about Tabularis's backend is that everything goes through SQLx. It does not. MySQL and SQLite do. PostgreSQL runs on tokio-postgres with a deadpool pool, and the split is deliberate.

SQLx earns its place on two engines: shared pool APIs, query builders and a common route into the grid's row model. But a database client has a problem a typical CRUD application does not. The application usually knows the types in its own schema. A client must decode whatever the user's schema throws at it, including extension types its database library does not know yet.

With tokio-postgres we can implement FromSql by hand, byte by byte, at the boundary of Postgres's binary wire format. That is how Tabularis got pgvector support: vector, halfvec and sparsevec decoded straight from pgvector's *_send format. For halfvec that meant half-precision floats, and since no direct dependency in the tree decoded IEEE 754 binary16, the driver now contains this:

/// Decode an IEEE 754 half-precision (`binary16`) value into `f32`.
fn f16_bits_to_f32(bits: u16) -> f32 {
    let sign = if (bits >> 15) & 1 == 1 { -1.0f32 } else { 1.0f32 };
    let exp = (bits >> 10) & 0x1f;
    let mant = bits & 0x3ff;
    match exp {
        0 => sign * (mant as f32) * 2f32.powi(-24), // zero / subnormal
        0x1f if mant == 0 => sign * f32::INFINITY,
        0x1f => f32::NAN,
        _ => sign * (1.0 + (mant as f32) / 1024.0) * 2f32.powi(exp as i32 - 15),
    }
}

A hand-rolled float16 decoder in a database GUI. We did not plan for this line item, and we are strangely fond of it.

The cost of owning those codecs arrives as pull requests: binding temporal and UUID values with explicit wire types, casting enums back to their column type so dropdown editing works, keeping routine introspection alive on PostgreSQL older than 11. SQLx can support custom Decode implementations too; this was a choice of API surface, not a capability SQLx lacks. In fact, SQLx's postgres feature is still enabled in the manifest even though the runtime path no longer uses its PostgreSQL pool. That build-time baggage is an invoice still waiting to be cancelled.

rustls, and the OpenSSL that stayed

The TLS section of Cargo.toml has a fifteen-line comment, which is usually the sign of a scar.

The short version: tls-native-tls is deliberately not enabled. On macOS its path through Apple's deprecated Secure Transport APIs failed in Tabularis on real-world CA bundles — the AWS RDS regional bundle among them — with errors like "One or more parameters passed to a function were not valid." The same bundle validated with openssl s_client and with mysql --ssl-mode=VERIFY_IDENTITY. Debugging that path through an opaque error string is not a hobby I recommend.

So every TLS path controlled by Tabularis's Rust code now speaks rustls, using platform roots where appropriate. That second choice matters as much as the first: it keeps the operating system's trust store live, so a corporate CA sitting in the macOS keychain still works. A bundled web PKI root set would not include that private CA, and "silently" is the worst word in that sentence.

Then comes the part rustls does not give you for free. Users expect familiar sslmode choices — prefer, require, verify-ca, verify-full — while rustls provides verification mechanisms rather than database-client policy. Reproducing those choices took two custom ServerCertVerifier implementations plus the standard platform and WebPKI verifier paths. The custom verify-CA-but-not-hostname verifier calls verify_server_cert_signed_by_trust_anchor directly, so the "skip hostname check" intent is explicit instead of buried in error recovery.

One of those semantics is a confession. Before v0.10.3, Tabularis's require mode validated the certificate chain. It now means "encrypt without authenticating the server", the common interpretation of require, which made the application less strict. libpq has a backward-compatibility wrinkle: when a root CA file exists, its require behaves like verify-ca, so Tabularis does not claim byte-for-byte compatibility with every libpq configuration.

Real-world deployments added their own complications: PlanetScale's Vitess rejects the sql_mode SQLx sets on every connection, so pool creation detects it and retries; AWS RDS wanted IAM authentication; Postgres needed ssl_mode honored in one more code path than we remembered existed.

And yet, after all this rustls conviction, there is still an openssl = { version = "0.10", features = ["vendored"] } in the tree. Today the only place Tabularis's own code calls it is one module, and what that module does is the next section.

The crypto shelf

Secrets never touch Tabularis's config files. Passwords go to the OS keychain through the keyring crate — Keychain on macOS, Credential Manager on Windows, the Secret Service on Linux.

But a keychain is a place, not a format, and connections need to move: exports, and automatic encrypted backups to a local folder or a WebDAV server. The envelope is argon2 plus aes-gcm: Argon2id at 64 MiB and three iterations derives the key, AES-256-GCM seals the payload, and the KDF parameters travel inside the envelope so future versions can raise them.

A self-describing envelope has a failure mode that took us longer to see than to fix: the parameters are attacker-supplied. A malicious file could ask the decrypting machine for 100 GiB of Argon2 memory, and the DoS would arrive dressed as your own backup. So the decrypt path rejects requests above 1 GiB of memory, 32 iterations or parallelism of 8. Those caps are bounds, not proof that decryption cannot hurt a smaller machine; keeping them low, and expensive derivation off the UI thread, is still worthwhile. Plaintext backups are not supported. There is no checkbox to turn encryption off, because someone would eventually tick it by accident.

The same shelf holds the strangest tools in the codebase. Tabularis imports connections from TablePlus, Sequel Ace, DBeaver, Beekeeper Studio and DataGrip, which meant learning each client's storage format: plist for the macOS clients, roxmltree for DataGrip's XML, and OpenSSL's AES-CBC for the two encrypted stores.

DBeaver's credentials file uses a fixed key; Beekeeper uses Node's simple-encryptor format with a per-install key unwrapped by a fixed bootstrap key. These are local files on the user's own machine and the threat models differ. But it does mean the vendored OpenSSL's last remaining duty in a rustls application is reading other database clients' secrets. Some dependencies retire; this one became a locksmith.

russh and ssh. Both.

SSH tunnels have two implementations, and the function that picks between them is three lines long: if the user typed a password, use russh in-process, because system ssh under BatchMode=yes cannot do interactive password auth. Otherwise, spawn the system ssh binary.

Shelling out sounds like the lazy option. It is actually the compatible one: the system client brings the user's ~/.ssh/config, agent, jump hosts and FIDO2 support with it, subject to the explicit options and GUI environment Tabularis supplies. russh does not try to reproduce every corner of decades of OpenSSH behavior, and Tabularis does not need it to.

The invoice came anyway, in two currencies. On Windows, ssh.exe popped a visible console window with every tunnel until the flags said otherwise. And a GUI app spawning ssh has nowhere to type a key passphrase — so Tabularis registers itself as the SSH_ASKPASS helper, re-executing its own binary in a thin client mode that forwards the prompt to the running app over a private local socket. Our app's process tree occasionally contains our app, asking itself for a passphrase. That story deserves its own post.

The 2⁵³ toll booth

One dependency does not appear in Cargo.toml, because it is a language: every query result crosses Tauri's IPC boundary as JSON and lands in JSON.parse. Beyond 2⁵³ − 1, JavaScript numbers no longer guarantee that distinct integers remain distinct. A database client that rounds your BIGINT is not a client, it is a rumor.

So the serializer checks the range: in-range integers cross as JSON numbers, out-of-range ones cross as strings. Write-back is harder. Column metadata decides the binding where it is available; some paths otherwise use a narrow heuristic that recognizes only integer strings outside the safe range. That reduces accidental coercion, but cannot eliminate the ambiguity: a large numeric value in a VARCHAR column is still text, and a leading zero still matters. A tagged wire value, or type-directed binding on every path, is the durable end state. The current range policy fits in roughly fifty lines of safe_int.rs; the boundary does not.

The dependency we wrote ourselves: 31 lines of JSON-RPC

Plugin drivers — DuckDB, Redis, MongoDB, Elasticsearch, Cloudflare D1 — are separate executables speaking JSON-RPC 2.0 over stdin and stdout. The entire wire-type module is 31 lines. I have spent more lines configuring loggers.

The driver and process-management machinery is much larger, but keeping the wire types small is the point: any language that can read a line and write a line can be a Tabularis driver, and the registry already has drivers in Go and in Rust. A protocol whose transport is stdout has one commandment — nothing else may write to stdout — and the plugin guide warns every third-party author about it in bold.

Then we shipped an MCP server that logged to stdout and corrupted its own transport. The rule we wrote for other people, broken in the same protocol and the same repo. The fix was one line. The same subsystem also taught us that "read-only" is a property of a SQL dialect, not of a protocol: EXPLAIN ANALYZE executes the statement it explains, and bypassed the read-only gate until the gate started classifying the wrapped statement instead of the EXPLAIN prefix. EXPLAIN ANALYZE SELECT remains a read; EXPLAIN ANALYZE DELETE does not.

The supply-chain boundary

The last set of decisions concerns code Tabularis downloads but does not write. The plugin registry never hosts binaries; it signs author-provided hashes of release assets with Ed25519. Tabularis verifies that registry signature with ed25519-dalek before installing anything, and it rejects a valid signature whose plugin, version or registry does not match the requested release. CI actions are pinned to commit SHAs, not mutable tags.

Would I choose them again?

Almost all of them, yes. Not because cost is virtuous, but because the expensive choices bought capabilities users actually need.

SQLx where uniformity helps, tokio-postgres where explicit type codecs help. rustls with platform trust, plus custom and standard verifier paths for familiar sslmode choices. Two SSH clients chosen by a three-line predicate. Argon2id that puts bounds on its own envelope. A 31-line wire module that let other people write database drivers in Go before we finished documenting it.

A dependency is not just code you do not have to write. It is a boundary you agree to operate, often before you have read the code on the other side. Choose the boundaries whose failure modes you are willing to understand, and budget for the invoices — they are not optional, only deferred.

The vendored OpenSSL, meanwhile, is still here. Nobody has had the heart to tell it.

v0.17.0 follows v0.16.0 and is the release where the tools around your SQL get smarter about what your SQL is actually doing. Visual EXPLAIN stops ranking plan nodes by figures that always point at the root and starts computing what each node itself costs — then tells you, in plain findings, which nodes deserve your attention. The editor learns which clause your cursor is in and suggests accordingly, formats your SQL on Shift+Alt+F with a style you configure, and stops mistaking 'x:y' inside a string for a query parameter. Around that core: the row editor becomes a proper right sidebar that follows your selection, split view grows to four panes, updates gain an opt-in nightly channel, PostgreSQL learns pgvector, the sidebar reacts to DROP DATABASE the moment it happens, and Tabularis speaks Brazilian Portuguese.

Visual EXPLAIN: Exclusive Metrics, Findings, and Two New Views

The plan views used to rank and colour nodes by the figures the database reports directly. Those figures are inclusive of children, and Postgres' Actual Total Time is an average per loop — so the plan root was the "slowest step" in essentially every plan, the heat colour was a gradient by depth rather than by work done, and a node executed 50,000 times at 0.2 ms each looked cheap next to a node that ran once for 20 ms. PR #529 rebuilds the whole thing.

• Exclusive (self) metrics. Every node's figures are restated once per plan before any view renders: inclusive time becomes Actual Total Time × Actual Loops (a total, not a per-loop average), exclusive time subtracts the children's inclusive time, and the same treatment applies to cost, rows and buffers. Graph nodes, the table view and the overview bar now rank and colour on these values — by exclusive time when the plan ran with ANALYZE, by exclusive cost otherwise. InitPlan/SubPlan children are excluded from the subtraction, and exclusive values clamp at zero for the drivers and text dumps that don't satisfy parent ≥ Σ children.
• Per-node findings. Ten diagnostic checks run on every node — hotspot (≥ 25% of plan time), row estimates off by 4x/10x, sorts that spilled to disk, filters discarding ≥ 90% of rows, large sequential scans, heavy heap fetches, fewer parallel workers than planned, nodes executed thousands of times, block accesses missing shared buffers, and never-executed nodes. Findings render as labelled chips on the graph, as icons in the table and diagram rows, and with a one-line explanation in the node details panel.
• A diagram view — one row per node in plan order with a bar proportional to the selected metric (time, rows, cost or buffers; only metrics the plan actually carries are offered). Selection is shared with the graph, so a node picked in one view stays picked in the other.
• A stats view — plan-wide aggregates: node counts and depth, time by operation, relations accessed with rows and self time, and indexes used with scan counts.

Underneath, the explain core moved out of the app into a standalone npm package (#531, #536) — the how and why of that extraction has its own write-up: Visual EXPLAIN beyond the app.

The Row Editor Becomes a Sidebar That Follows You

The row editor used to open as a fixed overlay: it covered your results, stayed pinned to the row you opened it on, and had to be reopened from the context menu for every other row. PR #510, from @aesslinger, replaces it with a right sidebar that behaves like the Explorer on the left — a first-class layout citizen that pushes content aside instead of covering it, resizes with a drag handle (width persisted), toggles with Cmd/Ctrl+Shift+B, and follows your row selection by default. A pin button locks it to a specific row when you want the old behaviour, and the underlying panel system is generic, so future panels get the same treatment for free.

A Polished Rail, and Split View Grows to Four

The rail on the far left got a matching polish in PR #511: active items are marked by a pill indicator that follows the current view, connection badges grew so the driver logo is actually readable, and split view now holds up to four connections instead of two — join a group from the context menu or by dragging a connection onto the group badge, swap panes by dragging the icons, remove one with a right click.

SQL Formatting, Your Way

A request as old as the repo — issue #23 — lands in this release. PR #500, from @aesslinger, adds Format SQL to the editor: Shift+Alt+F (Shift+Option+F on macOS), a toolbar button, and a right-click entry. Select text first to format only the selection, the dialect follows the active connection (PostgreSQL, MySQL, SQLite, T-SQL, PL/SQL), and formatting pushes to the undo stack so Cmd+Z reverses it.

The follow-up PR #504 makes the style configurable in Settings: keyword and function case, indent style and width, tabs vs. spaces, blank lines between queries, dense operators. Settings apply on the next format action, no restart.

The Editor Knows Where Your Cursor Is

Two changes teach the editor to actually parse what's around the cursor instead of pattern-matching the whole buffer.

Clause-aware autocomplete (PR #505) replaces the offer-everything-everywhere completion with a context analyzer that classifies the cursor into one of 29 clause contexts. After FROM or JOIN you get tables, after WHERE or ON or inside function arguments you get columns, inside an INSERT INTO t (...) column list you get columns only, and inside a string literal or comment you get nothing at all. The analyzer handles subqueries (clause scoped per parenthesis frame), CTEs, nested CASE … END, quoted identifiers and escape sequences — and degrades to the old behaviour on anything it doesn't recognize, so a miss can never hide valid suggestions.

Query parameters stop firing inside strings (@ymadd, PR #519, fixes #458) — WHERE value = 'x:y' no longer pops the parameter modal for :y, and filling in a value no longer rewrites the inside of your string literal. The detection now reuses the dialect-aware tokenizer that already powers the statement splitter, so URLs, timestamps and JSON-in-text stop being mistaken for parameters.

An Opt-In Nightly Channel in the Updater

Signed nightly builds have existed since v0.16.0 — but installing one meant finding it on GitHub. PR #497, from @NewtTheWolf, wires them into the app: a release channel selector in Settings switches the updater between stable and nightly, and the update check resolves the newest nightly and installs it in place.

The versioning under it is carefully boring: a nightly is stamped as the next patch with a prerelease suffix, so it always supersedes the current stable, any real release supersedes the nightly, and comparisons run through semver so nightly users can always come back to stable when a release ships. If you want to see where Tabularis is going a few weeks early, this is the switch — and if you don't touch it, nothing changes.

PostgreSQL Learns pgvector

If your tables hold embeddings, they stopped rendering as USER-DEFINED columns full of nulls. PR #450, from @jonatannietoa, teaches the PostgreSQL driver the three pgvector types — vector, halfvec and sparsevec: values decode from their binary send formats to canonical text, column metadata reports the real type name (in tables and views), and editing works — vector literals are inlined with a strict validation allow-list, since pgvector registers no text cast for bound parameters. In the grid, vector columns render as expandable long-text previews instead of a bare ellipsis.

The Sidebar Notices When a Database Disappears

Three changes in this cycle close the same gap from different sides: a database dropped mid-session used to stay in the sidebar until you disconnected.

• Dropped databases are pruned on connect (PR #524) — reconnecting reconciles the saved selection against what the server actually has.
• A manual refresh button (@gcapellib, PR #530) runs that same reconciliation on demand, next to "Manage databases" — with an in-flight lock and a cooldown so rapid clicks don't stack toasts.
• DROP DATABASE inside the app is detected as it happens (@gcapellib, PR #535, fixes #525) — a small dedicated parser recognizes a successfully executed DROP DATABASE/DROP SCHEMA (failing closed on anything ambiguous), and the sidebar clears the database and notifies you the moment the statement succeeds. Dropping a database that wasn't selected stays silent.

Tabularis Fala Português

@jeffersongoncalves contributed a complete Brazilian Portuguese (pt-BR) locale in PR #537, plus a translated README linked from every language switcher. That makes eleven UI languages — and the same PR fixed a resolution bug where any region-coded locale (pt-BR → pt) was silently stripped before matching and fell back to English.

Fittingly, the language picker itself stopped scaling: a button group doesn't survive eleven entries, so it's now a searchable select showing each language's native name alongside its label in your current UI language.

Smaller Things

• Copy column values as a list or an IN clause (@pokertour, PR #482, closes #459) — the grid's cell and column-header menus gain two entries: newline-separated values, or a ready-to-paste SQL list with numbers raw, strings quoted and escaped, and NULL for nulls.
• PostgreSQL ssl_mode honored everywhere (@darkrideroffate, PR #378) — the connection-test path ignored the SSL mode and attempted TLS even when set to Disable, so Load Databases succeeded while connecting failed with "bad protocol version" against servers like CloudNativePG. Both paths now agree.
• Cut and Copy work in the editor's context menu again (@gcapellib, PR #520) — Monaco's built-ins go through document.execCommand, which fails on WebKitGTK/Wayland; both actions now use the Tauri clipboard API, the same treatment Paste already had.
• SQL file import runs once, against the right database (@gcapellib, PR #513, fixes #512) — Run SQL file on a right-clicked database imported into the connection's primary database instead, and a re-firing effect executed the whole dump twice.
• Load Databases no longer requires a username (PR #533, fixes #528) — Redis authenticates with a password only, so the button could never enable and the connection could never be saved.
• Scrolling stays where it belongs (@verbaux, PR #493) — document-level scrolling and overscroll are disabled, nested lists stop propagating scroll gestures to their parents, and the phantom empty area at the right edge of data grids is gone.
• Modal borders are visible again (PR #509) — modals get a visible border and properly clipped rounded corners.

Thanks

Nine external contributors land in v0.17.0.

@aesslinger built two of the release's headline features: the row editor right sidebar (#510) and SQL formatting with configurable style (#500, #504). @gcapellib closed the dropped-database gap with the manual refresh (#530) and live DROP DATABASE detection (#535), fixed editor Cut/Copy on WebKitGTK (#520) and the double-executing, wrong-target SQL import (#513).

@NewtTheWolf wired the nightly channel into the updater (#497). @jonatannietoa brought pgvector support to PostgreSQL (#450). @jeffersongoncalves translated the entire app into Brazilian Portuguese (#537).

@ymadd stopped query-parameter detection from reaching into string literals (#519), @pokertour added column-values copy as list and IN clause (#482), @verbaux contained scrolling and grid overflow (#493), and @darkrideroffate made the PostgreSQL connection test honor ssl_mode (#378).

If you've ever stared at an EXPLAIN graph wondering which node is actually the problem, wanted your SQL formatted the way you format it, or wished the row editor would just follow your selection — this is the upgrade.

v0.17.0 is available now. Update via the in-app updater, or download from the releases page.

Visual EXPLAIN is the Tabularis feature people screenshot. You run a query and it turns the database's EXPLAIN output into a graph, a diagram, a table and a statistics view. It also reports findings for individual nodes, which is usually where the useful work begins: finding the bottleneck in a large plan.

For a few months I had wanted the same views on the web. There are already websites that let you inspect an EXPLAIN plan online, but none of them worked quite the way I wanted. I wanted to copy the output from psql or the MySQL shell, paste it into a page and inspect the plan without installing anything. I also did not want the site to store anything people pasted. I see little practical value in collecting queries for what should be a temporary analysis session. For a persistent workflow, there is the Tabularis desktop app. Since parsing a plan does not need a server, the page could be static and keep all the data in the browser.

Claude Opus 5 had just been released, and I wanted to give it a real task in this codebase. This was a useful test for an agent because I could state the architectural rule in one sentence and verify the mechanical work with 3,286 tests. The judgement calls were still mine. This was the rule:

A plan visualiser needs a plan, not a database.

The rest of the work was that sentence applied to one file after another.

That page now exists at explain.tabularis.dev. Its engine is a public npm package, @tabularis/explain, and the desktop app uses the same package.

How the feature was tied to the app

Before the extraction, Visual EXPLAIN could not leave the desktop app. Not because it needed a database connection. It never did. The problem was where the code lived.

On the Rust side, parsing was treated as part of the database driver. A driver did two different jobs: it ran the right EXPLAIN statement against the database, then translated the returned payload into a common plan model. The second job was pure data transformation, but placing it next to database access made the two responsibilities look inseparable.

The frontend had the same problem in a different form. Plan types, metrics, diagnostics and rendering logic had grown together. Analysis code depended on UI types, some statement logic lived beside plan logic, and two analysis modules imported each other at runtime. Diagnostics were also recomputed for every node on every render because the graph could not reuse work already done by its parent view.

None of this stopped the feature from working inside one application. The second host turned it into an architectural problem.

The first step was to make the dependencies point in one direction. Analysis could depend on the plan model, views could depend on analysis, and the host could depend on the package. Nothing inside the package should need to reach back into the host.

The extraction test

The rule I used for every file is now the first line of the package's description:

Takes raw EXPLAIN output; never runs a query.

Anything that passed this test moved to the package. Anything that failed stayed in the app. Statement building and the version fallback chains remained in the drivers. Tauri commands, the standalone window and file reading remained in the host. The AI plan explanation also stayed because it uses a provider configured by the host. The Monaco raw-output tab depended on the host theme, so it stayed too.

The decisions were not difficult once the rule existed. The problem was that these host features were threaded through otherwise portable code.

I moved the plan analysis and all the views into a @tabularis/explain workspace package. One important question remained: what should happen to the parsers?

Where should the parsers live?

The parsers were written in Rust, so my first implementation kept them there. I moved them into a standalone crate with no dependencies beyond serde, then compiled it to WASM for the browser. The desktop app and the web visualiser parsed plans with literally the same implementation. It looked like the clean architecture.

Once it was working, the bill became clearer. The plan model would still exist twice: as serde structs in Rust and as TypeScript types in the package. Analysis, metrics, diagnostics and all the views are written in TypeScript, so they need those types regardless of where parsing happens. We would have two definitions of the same model, in two languages, kept in sync by hand. A parser change or support for a new database engine could require changes on both sides. The browser would also need a WASM artifact for the only part of the package that was not TypeScript.

The same parser in two hosts was attractive. One plan model was more valuable.

The parsers did not need to run where Rust runs. They needed to run where the views run.

So I moved the parsers into the package behind a common interface. They cover Postgres JSON and text, MySQL and MariaDB FORMAT=JSON and ANALYZE trees, and SQLite EXPLAIN QUERY PLAN. The existing parser tests moved with them, so the change of language did not also become a change of behaviour.

The Rust side kept the part that actually depends on the database. Drivers run the statement, handle the version fallbacks, and return a small envelope containing the engine, format and raw payload. Row-based formats are serialised without interpreting their meaning. From that boundary onward, the package owns the plan.

In the Tauri post I wrote that every result page pays the IPC tax. Plans still pay it, but now they cross as a payload instead of a parsed tree. Parsing happens once, on the side that owns the types. Any host holding raw EXPLAIN output now takes the same path from text to view.

What the extraction exposed

Once the parsers stood alone, an assumption became obvious. The old API tried to detect the payload format from its contents, but this only worked for the two Postgres forms. A MySQL EXPLAIN FORMAT=JSON document also starts with {, so it was treated as Postgres and then rejected because it did not have the expected shape.

The fix was to let the caller provide the database engine when it is known, while keeping format detection as a fallback. The bug had been present in the app for some time, but separating the parsers made the weak assumption much easier to notice.

The tests revealed a different gap. We had unit tests for the parsers, but no test for the fallback chain that chooses which EXPLAIN statement to run. The driver uses EXPLAIN ANALYZE on MySQL 8.0.18 and newer, ANALYZE FORMAT=JSON on MariaDB, and plain FORMAT=JSON when neither is available. This logic can only be tested properly against a server. It now has live tests that exercise all three branches using MySQL and MariaDB containers.

Once these parts were in place, version 0.1.0 went to npm.

Three entry points, and the bill

The package has three entry points. The split is the architecture:

• @tabularis/explain: parsers, plan types, exclusive metrics, diagnostics, stats and formatters. It has no runtime dependencies, so plan analysis can run in a browser, a worker, a Node script or a test.
• @tabularis/explain/react: the graph, table, diagram, stats, node details and bars.
• @tabularis/explain/flow: the ReactFlow and dagre adapter, kept separate so the analysis core does not pull in a graph library.

All peer dependencies are optional, so a consumer only needs the dependencies required by the parts it imports. Inside the monorepo, the app can use the TypeScript source directly. Published consumers receive the compiled package instead. This keeps local development immediate without changing the public package contract.

Now for the bill. ./react is not a component kit you can drop into any application. The host must provide Tailwind with the colour tokens used by the desktop app, an initialised react-i18next instance with the editor.visualExplain.* namespace, and the ReactFlow stylesheet when rendering the graph. The package is portable, but its views are not independent of their host.

The desktop app provides the strings in eleven languages, while the standalone site currently provides only English. The two consumers also update differently: the app tracks workspace:*, while the site tracks releases on npm. This is a synchronisation cost that did not exist while everything lived in one codebase.

One repository or two?

For now, @tabularis/explain remains a workspace package inside the Tabularis monorepo. This is excellent during development. The desktop app resolves the package directly to its TypeScript source, so a change to a parser, a diagnostic and the view that displays it can all happen in one commit. The app tests the package as part of its normal test suite, and I can change both sides of the boundary without publishing an intermediate version to npm.

The monorepo becomes less convenient when the package is considered as a product of its own. It needs releases and a changelog that make sense to people who do not follow the desktop app. A change may be internal to Tabularis, public for package consumers, or relevant to both. The current application changelog is not a particularly good place to explain all three. Versioning and release notes also become easier to get wrong when the app and the package move in the same repository but publish on different schedules.

A separate repository would make that independence explicit. The package could have its own issues, documentation, changelog and release cadence. On the other hand, every change that crosses the driver and parser boundary would then cross repositories too. Testing an app change against an unpublished package version would require more work, and a refactor that is atomic today could become a pair of coordinated pull requests.

I do not yet know which cost matters more. Keeping the package in the monorepo gives the best development experience today. Moving it out may give it a clearer life as a public library. Now that there are two hosts and external consumers are possible, this is no longer just a question about where the files look tidier.

The second host

The standalone visualiser is mostly a page shell, examples and translations around the package. It runs entirely in the browser. It does not execute queries or upload plans to a server. The deployed site is just a static bundle.

The same extraction rule also guided a product decision for the site. AI plan analysis does not take only a plan: it depends on a provider configured by the host. For this reason, the online visualiser does not offer it. Instead, the corresponding tab explains that the feature is available in the desktop app.

The extracted analysis had also improved shortly before this work. In the same period, #529 added exclusive metrics. Previously, views ranked nodes using the figures reported by the database. Those figures include the work of child nodes and are often averages per loop, so the plan root appeared to be the most expensive node in nearly every plan.

This was technically accurate and practically useless.

The package now recalculates metrics for each node before displaying them. It also reports hotspots, row estimates that are wrong by more than 10x, sorts spilling to disk and filters discarding nearly every row. In a tool where you paste a plan, these findings are a large part of the product.

The extraction was merged as #536, with the app's 3,286 tests passing.

Would I draw the boundary again?

Yes, and earlier.

I started the extraction because the online visualiser needed it. But most of the immediate value appeared in the desktop app before the site existed. The import cycle is gone. Diagnostics are computed once per plan instead of once per node on every render. The format detection bug is fixed, and the fallback chain finally has tests. The code that answers "what does this plan mean?" no longer depends on the code that draws it.

This does not mean that moving code into a package automatically improves it. A bad boundary in its own repository is still a bad boundary. What helped was having a rule that described ownership instead of directories.

That rule is still the most useful result for me: takes raw EXPLAIN output; never runs a query. It sorted the files, determined what the drivers should return, chose the language for the parsers, and guided the decision about the AI tab on the standalone site. When one sentence makes that many decisions, the boundary was already real. The code had simply failed to express it.

The plan visualiser needed a plan, not a database. Now it does not even need Tabularis. You can paste a plan and see, although I would still prefer you used Tabularis.

In January I had to choose how to build Tabularis. Electron was the obvious option. Three native applications were the romantic option. Tauri looked like the compromise.

Six months and 64 releases later, I still think it was the right choice. But not for the reason usually printed at the top of Tauri comparison pages.

Yes, the Windows installer is 12 MB. This is nice. It is also the least interesting part.

The sentence that decided the architecture was this:

A database client is a systems program with a UI problem, not a web app with a database problem.

That sentence explains why I chose Tauri. It does not explain the bill. This post is about both.

The program behind the pixels

Below the data grid, Tabularis speaks MySQL, PostgreSQL and SQLite through SQLx. It opens SSH tunnels, asks the OS keychain for credentials, invokes kubectl for port forwarding, encrypts connection backups, and starts plugin drivers as subprocesses speaking JSON-RPC over stdin and stdout.

You can build all of this in Electron. Of course you can. But then I would either implement the backend in JavaScript, maintain native Node modules for every target, or add a Rust sidecar and recreate the same architectural split while still shipping Chromium. Electron's own documentation says native modules usually need to be rebuilt after an Electron upgrade. I did not want the database engine of the application to depend on how well node-gyp felt that morning.

With Tauri, the backend is an ordinary Rust program. SQLx, Tokio, rustls, keyring, AES-GCM: they are normal Rust dependencies, with normal Rust types between them. The backend is not a helper attached to the product. It is the product.

Then the frontend gets the part web technology is genuinely good at: Monaco, a virtualized data grid, forms, diagrams, themes. This separation felt natural to me. More importantly, it was a separation I could maintain alone.

There is also a security argument, but it is easy to exaggerate it.

Code in a Tauri webview has normal web capabilities, including network requests. What it does not get by default is Node.js or arbitrary access to the operating system. Privileged work crosses a defined IPC boundary through Tauri commands and plugin capabilities. In Tabularis I can inspect the command registration and capability files and see what the frontend is allowed to ask for.

This does not make a Tauri application secure by magic. A bad command is still a bad command. A loose capability is still loose, XSS still matters, and the Rust and npm dependency trees are still part of the attack surface. But for an application holding production credentials, I prefer starting from an explicit privilege boundary instead of adding one later.

And then there is size.

These are decimal megabytes from the Tabularis 0.16.0 and Beekeeper Studio 5.9.2 release assets. Beekeeper is a good database client. Its package sizes are not a failure of Beekeeper; they are the price of shipping Chromium, and shipping Chromium also buys you consistency.

Still, a 12 MB Windows installer for a database IDE makes me smile.

The harder comparison is native

Electron is the easy comparison. Native applications are the ones that made me hesitate.

An AppKit application does not care which WebKitGTK version Arch happens to ship. Native controls can offer better input latency, scrolling, text rendering and platform integration. Tauri does not ship a browser engine on most targets, but it certainly runs one, and the webview's memory does not disappear because the installer is small.

Size is not even a native-versus-Tauri argument. Sequel Ace is small too. The small-package story is mostly an anti-bundled-Chromium story.

So why not native? Because native to what?

Sequel Ace gives the honest answer: macOS. It is a focused application and a very good one. TablePlus began on macOS; when its small team built the Windows version, it rewrote the application in C# and C/C++. That is not a criticism. It is what “native on two platforms” actually means.

For Tabularis, native meant three user interfaces: three grids, three editors, three settings screens, three sets of bugs. A cross-platform widget toolkit would move the compromise somewhere else, not remove it.

The web has a component economy that is hard to ignore. Tabularis uses Monaco, the editor inside VS Code. I get multi-cursor editing, folding, search and the keyboard behavior developers already know. I can render an ER diagram and a visual EXPLAIN plan with the DOM. Reproducing that experience with native widgets on three platforms would not be a side quest for me. It would become the project.

When Tabularis started, one person was working on it: me. Yet it had to run on Linux, macOS and Windows, and it now ships in ten languages. Native might win the benchmark while losing the more important test: whether I could actually ship the application and keep it moving.

This is the trade I eventually wrote down:

Electron charges you for the runtime. Native charges you for the platforms. Tauri charges you for the seams.

Now for the seams.

You do not ship a browser. You inherit three.

Tauri uses the webview already available on the platform: WKWebView on macOS, WebKitGTK on Linux and WebView2 on Windows. WebView2 is based on Chromium. The other two are WebKit, but that does not make them identical. Tauri maintains a useful webview version guide; the Linux table alone explains why “works in my browser” is not a test plan.

So I do not ship a rendering engine, but I answer for three of them.

WebKitGTK has its own graphics path and is distributed on the cadence of each Linux distribution. WKWebView comes with the OS. WebView2 updates independently and is usually the least surprising because most frontend work is tested in Chromium first.

The differences are not always impressive technical failures. Sometimes macOS simply decides it is an editor. A user typed a straight quote in a table filter, the system changed it to a curly quote, and the resulting SQL stopped parsing. The fix in PR #439 normalizes typographic quotes before the clause reaches the database.

An Electron developer targets one rendering engine. I target three webview implementations that can disagree about CSS, input and GPU compositing. The small installer is partly financed by this work.

The Linux webview lottery

Most of the reports where Tabularis opens a broken window, or no useful window at all, have come from the Linux webview and graphics stack. A short history:

• #9: a Wayland protocol error on Arch, very early in the project.
• #45: libEGL fatal: did not find extension DRI_Mesa. The Snap package failed; the .deb worked.
• #54: a blank AppImage window. Preloading the host's libwayland-client.so made it render.
• #423: an AppImage WebKit process abort on Solus. It is still open while I write this.

The workaround in #54 deserves to be read twice. The portable bundle worked after it was forced to use a library from the system it was supposed to be portable across.

Electron applications have Linux and Wayland bugs too. What they generally do not have is the question “which WebKitGTK did this distribution compile, and how does it interact with this compositor?” Bundling Chromium removes that variable. This is a real advantage, not marketing.

It is also the structural weakness of Tauri's shared-webview bet. Anybody describing Tauri as a free lunch has not shipped an AppImage to enough Linux users.

The 94 MB exception

The first chart contains the whole story if you look at the last pair of bars.

Same release, five representative x64 package formats. Four are between 15.8 and 18.3 MB. The AppImage is 93.7 MB.

An AppImage cannot assume that the target distribution provides the dependencies it needs, so Tabularis's portable build carries WebKitGTK and much of its dependency closure. Tauri's own documentation warns that an AppImage can take an application from a few megabytes to 70 MB or more.

The size advantage came from borrowing the webview from the operating system. When the package cannot safely borrow it, part of the advantage goes away. Tabularis is still much smaller than the Electron AppImage in the chart, but the clean “12 MB versus 200 MB” story is gone.

Flatpak has a better model for this particular problem: common runtimes can be shared between applications. The less pleasant part is publishing on Flathub. Source-available submissions are normally built from source without network access, so every Cargo and npm dependency must be described ahead of the build. This is solvable, and work on #326 is ongoing. It is not a one-line manifest.

You own the glibc floor

I learned another Linux lesson in the traditional way: by shipping the bug.

At one point the Linux release ran directly on GitHub's ubuntu-24.04 runner and linked against glibc 2.39. The binary then refused to start on Ubuntu 22.04, which has glibc 2.35 and was still in standard support.

The fix was to build inside an ubuntu:22.04 container. The container pins the compatibility floor even when GitHub eventually changes or removes its runner images. This is also what the Tauri AppImage guide recommends: build on the oldest base system you intend to support.

Electron largely chooses this baseline for you through its prebuilt runtime. Native Node modules can still reintroduce the same problem, but if your Electron application is pure JavaScript, a decade of packaging knowledge is already encoded in the toolchain.

When you compile a native Rust backend, you own its system compatibility. Rust gives you systems programming, including the systems.

Every result page pays the IPC tax

The most important seam is not packaging. It is in the architecture.

The Rust core and the React UI live on opposite sides of Tauri's IPC boundary. Today a query result in Tabularis is a Rust QueryResult containing rows of serde_json::Value. Tauri serializes the response, the webview receives JavaScript values, and only then can React render the grid.

For a settings screen this cost is noise. For query results it shapes the product.

The UI asks for paged results, 500 rows by default, instead of moving an unbounded result set into the webview. Large exports stay on the Rust side and stream from the database to a file, avoiding the UI bridge altogether. The virtualized grid matters not only because the DOM is expensive, but because moving and retaining data is expensive too.

Electron has an IPC boundary in its secure default architecture as well. You can put a native module in an unsandboxed renderer and avoid some of it, but Electron's documentation is explicit that this disables an important security boundary. The shortcut exists. It is not free.

This is the same fence seen from two sides. Keeping credentials and database access out of the webview is a security benefit. Serializing every visible row across that fence is a performance cost. I want both facts in the same paragraph because they come from the same decision.

Would I choose Tauri again?

Yes.

Not because Tauri is “Electron without the bloat.” That description is too small, and on Linux AppImage it is not even particularly convincing.

I would choose it again because the hard part of Tabularis is where I want it: database protocols, TLS, tunnels, credentials, encryption, plugins and exports are Rust. The editor, grid, diagrams and interaction design change much faster, and web technology fits them well. The boundary between the two costs real work, but it is a boundary I understand and want.

Some costs can be paid once: pin the build container, drop a broken package, add the right workaround. Others recur forever. I will keep testing three webviews. New compositors and distro combinations will produce bugs I cannot reproduce. Every page of rows will still cross IPC.

That is acceptable to me. What would not be acceptable is maintaining three interfaces, or wishing the database core were not JavaScript after the application had already grown around it.

If your desktop application is mostly a frontend for HTTP APIs, Electron may be the simpler and better choice. If you support one platform and care deeply about native behavior, build native. If you need identical rendering everywhere, shipping Chromium is a feature. And if your application is a systems program that needs a rich cross-platform interface, Tauri is a very interesting compromise.

Just budget for the seams.

The AppImage users may now open an issue.

v0.16.0 follows v0.15.0 and is the release where the plugin ecosystem stops being a JSON file in a git repo and becomes infrastructure: a hosted registry, a searchable driver catalogue built into the New Connection flow, one-click installs from a browser link, and two new community drivers — Elasticsearch and Cloudflare D1 — to install through it. Around that core: Kubernetes tunnels learn to use your kubectl and your kubeconfig, connections back themselves up encrypted to a folder or a WebDAV server, the SQL editor runs the statement under your cursor, and MySQL connections can authenticate against AWS RDS with IAM.

A Hosted Plugin Registry and a New Connection Catalogue

Until now, discovering a Tabularis plugin meant knowing it existed: the registry was a static registry.json, and installing meant finding a GitHub release yourself. PR #299, a long-running effort from @NewtTheWolf, replaces that with the hosted Tabularium registry at registry.tabularis.dev — and rebuilds the New Connection flow around it.

• A driver catalogue is now step one. Creating a connection starts from a searchable grid of every engine Tabularis can talk to — built-in drivers and registry plugins merged into one view, with paradigm facets to filter by. Built-ins lead, and drivers your platform can't run are badged and dimmed instead of being a click-through dead end. An uninstalled driver is install-gated: pick it, install it inline, connect.
• Deep-link installs. tabularis://install/<slug> links open the app with a version-aware confirmation — Install, Update when a newer version exists, or an already-up-to-date notice. Plugin pages on the web can now be one click from a working driver.
• Fully backwards compatible. The legacy registry.json is still merged in (the API wins on conflicts), so older plugins stay visible and already-shipped app versions keep working. All of the compatibility code is marked COMPAT(registry-ga) so it can be removed mechanically once migration completes.
• Tooling for authors. @tabularis/create-plugin 0.2.0 scaffolds the new .tabularium manifest format, adds a migrate command that converts legacy manifest.json plugins, and emits a registry-ready release workflow that publishes the manifest as a release asset the registry resolves directly.

The weeks after the merge hardened the transition paths: installed plugins that drop out of the hosted listing stay updatable instead of silently losing their update button, legacy manifest.json bundles install and list again, legacy-only plugins no longer link to a 404 on the API, and the Installed tab finally has an Update button next to the plugin it's telling you to update.

Two New Community Drivers: Elasticsearch and Cloudflare D1

Two community-built drivers joined the registry this cycle.

Elasticsearch, by @erwin-lovecraft (repo, added in PR #476), brings cluster inspection to Tabularis: index browsing with stats, a mapping viewer for fields and nested structures, and document sampling. Queries run in three modes selected by a shebang on the first line — Elasticsearch SQL by default, #!esql for ES|QL, and #!rest for raw REST requests with the method and endpoint on the first line and the body below. It requires Tabularis 0.15.0 or newer.

Cloudflare D1, by @GabrielMalava (repo, registered in PR #430), talks to Cloudflare's serverless SQLite over the D1 HTTP API with per-connection credentials: browse every D1 database in your account, inspect tables, indexes, foreign keys and views, run paginated queries, edit rows, and manage tables, indexes and views — ER diagram included.

Plugin drivers also got more capable underneath: batch query RPCs are now forwarded to external plugin drivers (@haos666, PR #443), and a new explain driver capability (PR #491) means the Visual EXPLAIN button only appears for drivers that actually implement it, instead of failing at click time.

Kubernetes Tunnels, With Your kubectl and Your kubeconfig

Tabularis's Kubernetes port-forwarding always used whatever kubectl was first on the PATH and the default kubeconfig. If you juggle multiple clusters, wrap kubectl in a corporate shim, or keep per-project kubeconfig files, that assumption was the feature's ceiling. PR #365, from @metalgrid, adds advanced settings to Kubernetes connections — both inline and saved — that override the kubectl binary and the kubeconfig file per connection.

The override paths are validated before they're used: an on-blur preflight checks that the pair actually works, incomplete pairs are refused before apply, and cancelling the modal cancels the validation instead of letting it land on a closed form. Tunnel cache keys now include the overrides, so two connections pointing at the same host through different kubeconfigs no longer collide on the same cached tunnel. The new settings are translated across all supported locales.

Backups That Take Themselves

v0.15.0 gave connection exports proper encryption. v0.16.0 makes them automatic. PR #470, from @pokertour, adds a dedicated Backup tab in Settings that periodically writes an encrypted export of your connections — same AES-256-GCM / Argon2id envelope as the manual export, and deliberately only that: plaintext automatic backups are not an option.

• Triggers: manual, on an interval (6h/12h/daily/weekly presets or a custom value, with the next run time shown), on app launch, or on app close — the exit backup is bounded by a timeout so the app can always quit.
• Destinations: a local folder, or a WebDAV collection (Nextcloud and friends). Rotation honors your retention count and only ever touches tabularis-backup-*.json files, so it can't eat anything else living in the same directory.
• Secrets stay in the keychain. The encryption password and the WebDAV credentials live in the OS keychain, never in config.json, and the scheduler re-reads its config every minute so settings changes apply without a restart.

Run the Statement Under Your Cursor

The single most-used editor action got the TablePlus treatment. PR #464, from @maximumbreak, makes Cmd/Ctrl+Enter run the SQL statement the cursor is inside when nothing is selected — no more whole-file execution or a "pick a statement" popup. A subtle highlight shows which statement is armed, Explain follows the same rule, and Run All moves to Cmd/Ctrl+Shift+Enter with a dedicated entry at the top of the Run dropdown. Selecting text still runs exactly the selection.

Making back-to-back statement runs easy exposed two long-standing result bugs, fixed in the same PR: an in-flight column-metadata fetch could resolve late and stamp the wrong table's primary key onto the current result, and pagination or post-edit refresh re-sent the whole editor buffer — which PostgreSQL rejects as "multiple commands in a prepared statement" once the buffer holds more than one. Both paths now track the exact last-run statement per tab, and stale async responses detect themselves and drop out.

And if you liked the old picker: @GabrielMalava added a Query Execution toggle in Settings → General in PR #487 — running the statement under the cursor stays the default, but switching it off brings back the query-selection dialog for multi-statement scripts.

AWS RDS IAM Authentication for MySQL

If your MySQL lives on RDS behind IAM database authentication, Tabularis can now speak it. PR #404, from @p4pupro, adds a Use AWS IAM Authentication (RDS) option to MySQL connections: the password field carries a generated RDS auth token (they expire after 15 minutes, so the token must be supplied per connect — the keychain is deliberately bypassed), and TLS is mandatory and enforced on every path, so a token can never travel in the clear. Connections with IAM enabled and a CA bundle configured are auto-escalated to certificate verification, empty-token mistakes fail fast with an actionable message instead of an opaque 1045 Access denied, and a macOS-specific TLS handshake failure with the RDS regional CA bundle was fixed by moving the MySQL TLS backend to rustls with the OS trust store kept active — so corporate CAs in the system keychain keep working on every platform.

Stored Procedures Show All Their Result Sets

A MySQL CALL to a stored procedure with several SELECTs streams back several result sets — and Tabularis only ever showed the first one. PR #415 (fixes #414) rebuilds the MySQL execution path around result-set boundaries: every set now arrives, rendered through the multi-result tab UI with one tab per result set, and the per-page row cap applies to each set independently. The extra sets travel in a new optional field that other drivers and plugins simply never see, so nothing else changes shape. One known limit: a result set with zero rows is indistinguishable from the statement's OK packet at the driver level, so empty sets are still dropped.

Tabularis Speaks Korean

@moduvoice contributed a complete Korean locale in PR #463 — all 1,574 strings, every interpolation placeholder intact, plus a translated README linked from the language switchers. That makes ten UI languages.

Smaller Things

• Copy rows as a Markdown table (@pokertour, PR #481, closes #474) — the grid's copy and export menus gain a Markdown table format, ready to paste into a PR description or a wiki page.
• MCP transport no longer corrupts itself (PR #488, fixes #486) — keychain lookups and SSH/K8s tunnel setup logged to stdout, which in MCP mode interleaves with the JSON-RPC frames; clients like Warp dropped the connection with "Transport closed" on queries that had actually succeeded. All runtime logging now goes to stderr.
• JSON in the row editor, not [object Object] (@NewtTheWolf, PR #475, closes #428) — JSON/JSONB values from JOINs, UNIONs and aggregates arrive without column metadata; the row editor now recognizes structured values on their own and opens the JSON editor for them.
• Smart quotes normalized in filters (@Davydhh, PR #439) — a WHERE name = “foo” pasted from a chat app no longer fails; curly quotes in filter and sort clauses are normalized to the straight quotes SQL expects.
• MiniMax key status (@octo-patch, PR #454) — the AI settings now show whether a MiniMax API key is configured, like every other provider.
• Nightly builds, properly gated (@NewtTheWolf, PR #419) — signed nightly builds now ship as one tag per build (nightly-<date>-<sha>), cut only from the newest commit that passed CI, laying the groundwork for a selectable nightly update channel.
• Linux builds run on older distros again (PR #490) — release and nightly Linux builds moved into an Ubuntu 22.04 container, lowering the glibc baseline so the .deb and AppImage keep working on older LTS systems.
• Plugin uninstall no longer trips on empty config (PR #501) — uninstalling a plugin that never wrote a config crashed on macOS; the null case is now handled.

Thanks

Eleven external contributors land in v0.16.0.

@NewtTheWolf built the release's centerpiece: the hosted Tabularium registry and the connection catalogue (#299), plus the gated nightly pipeline (#419) and the row-editor JSON fix (#475). @metalgrid made Kubernetes tunnels configurable with kubectl and kubeconfig overrides (#365). @pokertour added automatic encrypted backups (#470) and Markdown table export (#481).

@maximumbreak brought run-at-cursor to the editor (#464). @p4pupro added AWS RDS IAM authentication for MySQL (#404). @erwin-lovecraft built the Elasticsearch driver plugin (#476) and @GabrielMalava the Cloudflare D1 one, registered in #430 — and also made the cursor-run behavior configurable (#487).

@moduvoice translated the entire app into Korean (#463). @haos666 forwarded batch query RPCs to plugin drivers (#443), @Davydhh normalized smart quotes in filters (#439), and @octo-patch surfaced the MiniMax key status (#454).

If you've been waiting for plugins you can discover and install without leaving the app, if your databases live behind a corporate kubectl, or if you've ever wished your connections backed themselves up — this is the upgrade.

v0.16.0 is available now. Update via the in-app updater, or download from the releases page.

Our React data grid was already virtualized, but it still stuttered on wide tables. In a headless benchmark, a 30-column table took 29.2 ms of React render work on each scroll tick. After the fix, the same test took 4.4 ms.

The problem was not the 1,000 rows in the result set. It was the 38 rows in the virtual window. Every scroll update rendered all of them again, including cells that had not moved.

I fixed this in June for v0.13.2, initially based on the very scientific observation that it felt smoother. For this post I went back, ran the old and new code through the same benchmark, and published the harness and raw results.

The short version: at 30 columns, the old grid called formatCellValue 3,420 times per tick. After PR #287, the same tick calls it 90 times.

Virtualized, and still janky

The Tabularis results grid has used TanStack Virtual since its early versions. With a 600px-tall viewport, 35px rows, and overscan, the DOM holds roughly 28 rows at rest, whether the result set has 500 rows or 100,000. Total row count was not the source of the scrolling problem, and this fix did not change the windowing strategy.

The problem showed up on wide tables. A few hundred rows and 30 to 40 columns is a normal shape for a denormalized reporting table, and scrolling visibly dropped frames. That was confusing at first because "virtualize your list" is the standard answer to slow grids, and we had already done it.

Virtualization limits how much UI exists at once. It does not make the visible subtree cheap. We had bounded the number of rows, but the work per visible row was still too high.

Where the work was going

The old DataGrid.tsx rendered rows inline, right inside the component body:

{rowVirtualizer.getVirtualItems().map((virtualRow) => {
  // ~560 lines of row and cell JSX, inline in DataGrid
})}

Scrolling updates the virtualizer, the virtualizer re-renders DataGrid, and because the row JSX is inline, re-rendering DataGrid re-executes the render of every visible row and cell. There was no memo boundary anywhere between "the scroll offset changed" and "re-run the JSX for cell 37 of row 214, which did not change."

There was more work inside each cell. The old code reached formatCellValue, which turns a raw database value into display text, through three call sites per normal cell render:

1. the TanStack Table cell: renderer,
2. the title attribute used for the hover preview,
3. the main display path, which eventually called the column renderer again.

I originally described this as three direct calls in the row loop. That was imprecise. Two calls were explicit in the row loop; the third came through flexRender and the column renderer. The benchmark sees all three because it wraps formatCellValue itself. The duplication accumulated across separate features, and each call site looked reasonable in isolation.

There was another cost too. Every row carried data-index and ref={rowVirtualizer.measureElement}, asking the virtualizer to measure rows dynamically even though normal data rows have a fixed 35px height. MiniResultGrid, the smaller grid in the visual query builder, already used fixed sizes.

The fix is one memo boundary

The main change in PR #287 was conceptually small: extract the row into DataGridRow.tsx and make React.memo actually hold. You can read the GitHub diff or the raw .diff.

export const MemoRow = React.memo(function MemoRow(rowCtx: MemoRowProps) {
  // renders one <tr>
});

The second half of that sentence is the difficult part. React.memo with the default shallow comparison is only as good as the identity of the props you pass. A row needs column metadata, pending edits, handlers, foreign keys, and a translation function. If any one of those props gets a new identity on every parent render, the memo silently does nothing and you are back to rendering everything.

So the props are split by volatility.

Everything that is stable for the whole grid goes into one object, memoized once in DataGrid:

/**
 * Stable, per-grid dependencies shared by every row. Bundled into a single
 * object that is memoized in DataGrid so React.memo's default shallow compare
 * on MemoRow only sees a new `ctx` reference when one of these actually changes.
 */
const rowCtx: RowCtx = useMemo(
  () => ({ columns, pkColumns, pendingChanges, columnTypeMap, /* … */ }),
  [columns, pkColumns, pendingChanges, columnTypeMap, /* … */],
);

Everything that varies per row is computed in the parent's .map and passed as primitives:

<MemoRow
  ctx={rowCtx}
  rowIndex={rowIndex}
  isSelected={isSelected}
  isPendingDelete={isPendingDelete}
  editingColIndex={isRowEditing ? editingCell!.colIndex : null}
  focusedColIndex={isRowFocused ? focusedCell!.colIndex : null}
/>

The primitive part matters more than it looks. The obvious thing to do is pass editingCell, the {rowIndex, colIndex, value} object from state, straight down. But that object gets a new identity on every keystroke, and shallow compare would then invalidate every row, not just the one being edited. Passing editingColIndex as a number means row 214 receives null before the keystroke and null after it, so the memo holds. The row selection set and pending-deletion map stay out of rowCtx for the same reason: they change identity when one row changes, so each row instead receives its own isSelected and isPendingDelete booleans. The actual MemoRow call site shows the full prop split.

Handlers needed one more trick. handleEditCommit and handleKeyDown read the current editing state. Putting editingCell in their useCallback dependencies would give them a new identity per keystroke and invalidate rowCtx, which contains them. I used a ref:

// Mirror of editingCell so the commit/keydown callbacks can read the latest
// value without listing editingCell in their deps; this keeps their identity
// stable so the memoized rows don't re-render on every keystroke/scroll.
const editingCellRef = useRef(editingCell);
useEffect(() => {
  editingCellRef.current = editingCell;
}, [editingCell]);

The callbacks read editingCellRef.current and keep a stable identity for the life of the grid.

While the row render was being extracted, the three formatter paths collapsed into one call per cell. Dynamic measurement also went away: the data <tr> gets style={{ height: 35 }}, measureElement and data-index are gone, and the virtualizer keeps its estimateSize: () => 35.

Proving it, not vibing it

At the time, I verified this the way most frontend performance work gets verified: opened a wide table, scrolled, said "yeah, that's better." For this post I wanted actual numbers, so I built the benchmark I should have built in June.

The setup uses a git worktree pinned to 7def318b, the commit immediately before the memoization change, and another worktree on main at v0.15.0. Both run the same Vitest file. The harness renders the real DataGrid, TanStack virtualizer, and cell components in jsdom, wraps the grid in a React <Profiler>, then drives it with synthetic scroll events and keystrokes.

main has picked up smaller grid changes since the original fix, including precomputed result-color classes. The after numbers therefore describe v0.15.0, not commit 61794dc2 in isolation. For the original code change, use the before/after diff.

The harness records two metrics:

• React render duration per scroll tick, from the Profiler's actualDuration. I called this "commit time" in the first draft, but that was wrong. React documents it as the time spent rendering the committed update, not the duration of the commit phase.
• Calls to formatCellValue per tick, counted by wrapping the real function. In the new code this equals the number of rendered cells because each cell calls it once. In the old code each normally displayed cell called it three times, so this metric is an exact call count, not a direct cell-render count.

Both sides run React 19.2.4 on the same machine and Node version. The figures are medians over 7 runs of 30 scroll ticks each. Every tick scrolls 105px, or three rows.

There are important limits. jsdom has no real layout, paint, or GPU. The Profiler figures measure React render work, not browser frame time, style recalculation, or compositing. The dynamic-measurement change is therefore not represented faithfully by this harness. The test also uses React's development build, so the absolute timings should not be read as production timings. Both variants run in the same environment, which makes the comparison useful, but this is still a bundled before/after benchmark. It does not isolate how many milliseconds came from row memoization, formatter deduplication, fixed row height, or the smaller changes added after PR #287.

Getting jsdom to virtualize at all took some digging. TanStack Virtual measures the scroll container via offsetWidth and offsetHeight, which jsdom reports as zero, so the virtualizer rendered no rows. The harness stubs those getters with a 1200 by 600px viewport and 35px rows. That produces about 38 rendered rows including overscan. It reproduces the windowing behavior needed for this test, but it is not a substitute for a browser benchmark.

The numbers

Scrolling, 1,000-row table:

At 30 columns, React's actualDuration fell from 29.2 ms to 4.4 ms per scroll update. At 50 columns it fell from 43.9 ms to 10.0 ms. These are development-build figures from the headless harness, so the comparison matters more than the absolute values.

The call counts explain the ratio:

The call counts decompose exactly. The old result is 38 rendered rows × 30 columns × 3 formatter calls per cell = 3,420. A 105px tick brings 3 rows into the new render window, so the new result is 3 × 30 × 1 = 90. The other 35 rows do not render again. The 38-fold reduction combines two changes: unchanged rows now bail out, and each rendered cell formats its value once instead of three times.

Typing is the case I find more satisfying, because it's where the editingCellRef trick earns its keep:

Before the fix, every keystroke in the inline editor re-rendered all 28 rows in the window. That produced 2,517 formatter calls to display one character: 28 × 30 × 3, minus the three calls for the cell showing an <input>. In the headless test, a 50-column table took 54.9 ms per keystroke. After the fix, only the edited row re-renders, producing 30 formatter calls and a 3.7 ms update at 30 columns.

One mount-time number is also useful. The old grid made 2,520 formatter calls on mount, three per rendered cell. The new grid made 840. Both call counts were identical with 1,000 and 100,000 result rows, confirming that virtualization bounded the rendered window. Total mount time still grew with the result set because TanStack Table had to build its row model, which is a separate cost this change did not address.

A bad mock invalidated every row

The first benchmark run exposed a mistake in my setup: the memoized grid re-rendered all 38 rows on every tick, exactly like the old one. It made 1,140 formatter calls where I expected 90. There was no error and the test still passed.

The cause was one line in the shared Vitest setup. It mocked react-i18next like this:

useTranslation: () => ({
  t: (key: string) => key,   // a NEW function on every call
}),

A fresh t function was created on every render. t is a member of rowCtx because the row uses it for NULL labels. A new t produced a new rowCtx, the shallow comparison failed, and every row rendered again. The application did not show this behavior because its t reference remained stable in this scenario. I changed the harness to return a singleton mock, then the expected gap appeared.

A context-object memo is only as strong as its least stable member. One prop with per-render identity, such as a translation function, inline callback, or freshly filtered array, can turn the memo into a no-op. Nothing breaks and React does not warn you. I wrote the component and still got the benchmark wrong on the first run, so reading the code was not enough. The corrected singleton mock is in the published harness.

What's deliberately not done

Column virtualization. The grid renders every column of every visible row, so a 200-column table still does 200 columns' worth of cell work per new row. At 50 columns, the headless result was 10.0 ms per tick. The demo stack includes perf_demo.wide_table, with 50 columns and 50,000 rows, seeded for MySQL and Postgres by demo/generate-perf-sql.py, so the case is easy to test in a real browser.

Horizontal virtualization has to coexist with a sticky header, a sticky row-number column, and an expansion row that uses colSpan. Virtualizing columns would break that expansion layout unless the editor became an overlay. I have left it out until a real workload justifies that complexity. If you have one, open an issue.

If you have a slow virtualized grid

The checklist I wish I'd had before shipping the janky version, in the order I'd apply it:

1. Count renders before timing them. Wrap something every cell calls and count invocations per scroll event. If the count tracks visible cells instead of newly visible cells, inspect component invalidation before changing the virtualizer.
2. Put the memo boundary at the row, not the cell (too many boundaries) and not the body (too few).
3. Split props by volatility. Grid-stable values go in one memoized context object; per-row volatile values go in as primitives, computed in the parent. Never pass the raw editingCell/focusedCell state objects into memoized children.
4. Stabilize handlers with refs, not by widening dependency arrays.
5. If your rows are a fixed height, tell the virtualizer and delete measureElement. Measurement is for content that actually varies.
6. Re-verify after refactors. The memo is invisible when it stops working. A render-count assertion is cheap insurance.

Source and reproduction

• PR #287 and its Files changed view
• Before/after GitHub diff and raw diff
• Old DataGrid.tsx and extracted DataGridRow.tsx
• Benchmark README, test harness, raw results, and chart generator

v0.15.0 follows v0.14.0 and has one clear theme: the Connections page stops being a flat list you retype things into and becomes something you can actually manage. You can now import your saved connections from five other SQL clients, file them into folders inside folders, select twenty of them and act on all twenty, and hand a teammate an export that is actually encrypted instead of a JSON full of plaintext passwords. Around that core: ENUM columns become dropdowns on both MySQL and PostgreSQL, the MCP safety layer closes an EXPLAIN ANALYZE loophole, and Windows users stop seeing phantom console windows. Fourteen external contributors land in this tag.

Import Connections From the Client You're Leaving

The biggest friction in trying a new database client is retyping every connection you've accumulated over the years. PR #393 removes it: a new Import dropup next to Add Connection reads saved connections from DBeaver, Beekeeper Studio, TablePlus, DataGrip and Sequel Ace — plus Tabularis's own JSON exports.

Each source is parsed into a neutral envelope, and credentials are decrypted or read from the source client's keychain when you ask for them. Nothing is merged blindly: a preview lists every connection found, flags duplicates against what you already have (keep, replace, or skip — the duplicate's existing name shown so you know what you're replacing), and lets each new connection pick a target group — or create one on the fly, with defaults seeded from the source app's own folder structure.

The feature ships marked beta, with a visible badge and a direct link to file an issue — parsing five other apps' formats across three platforms is exactly the kind of surface where real-world files will find edge cases. One already got fixed before release: Beekeeper payloads containing non-ASCII characters used to abort the whole import on a byte-boundary panic; they now parse or skip gracefully.

Folders Inside Folders

Connection groups were single-level since the day they shipped. PR #405, from @p4pupro, makes them a real tree: groups can contain groups, to arbitrary depth, in both grid and list view.

The workflow got the attention the data model change deserved:

• Create paths, not just names. Typing clients/acme/staging in the New Group input creates the whole chain, reusing existing segments case-insensitively — the same / syntax works in the inline subfolder input on each group header.
• Drag to re-parent. Dropping a group onto another group's header past one indent step moves it inside; dropping near the left edge keeps the plain reorder. A cycle guard refuses to move a folder into its own descendant, with a clear error rather than silent corruption.
• Cascade delete. Deleting a group now removes its entire subtree — nested groups and their connections included — instead of quietly orphaning children to the root.
• Counts that add up. A folder's badge sums direct and descendant connections, so a collapsed tree still tells you what's inside.

Existing connections.json files keep working unchanged — parent_id is optional and defaults to root — and the export/import path preserves the hierarchy, demoting any dangling parent reference to root instead of rendering ghost trees.

Select Many, Act Once

With imports and folders in place, you need a way to move things around in bulk. PR #468 adds multi-select to the connections list: a checkbox appears on hover, selected cards get a ring, and a pinned action bar shows the count with three actions — Move to group (a submenu built from the nested tree, plus Ungrouped), Delete selected behind a confirmation with the count, and clear.

@pokertour immediately wired the selection into the export flow in PR #469: the action bar gains an Export button that writes only the selected connections. The filtering happens before secrets are resolved, so credentials for unselected connections never leave the keychain, and the exported group list is pruned to just the ancestor chains the retained connections actually need.

Exports That Don't Leak Passwords

Until now, exporting connections wrote database, SSH and Kubernetes credentials in plaintext behind a single warning dialog. PR #447, also from @pokertour, replaces that with a proper export modal offering three modes:

• Encrypted with a password (the default) — the payload is encrypted with AES-256-GCM under an Argon2id-derived key.
• Plain text without passwords — secrets stripped entirely; fine for sharing a topology.
• Plain text with all passwords — the old behavior, with the warning now attached to the option that deserves it.

Import detects the encrypted envelope and prompts for the password before merging. The decryption path is hardened too: the Argon2 parameters read from the envelope are bounded, so a malicious import file can't request unbounded memory or CPU. Plain exports from older versions import unchanged.

ENUM Columns Become Dropdowns — on Both MySQL and PostgreSQL

Editing an ENUM cell used to mean remembering the allowed values and typing one exactly. Two PRs fix that end to end.

On MySQL, @fhriz introspected the full column_type from information_schema in PR #455 (closes #452), so a column shows as enum('pending','approved','rejected') instead of a stripped enum — and both the inline grid editor and the row sidebar render a dropdown of the allowed values, with a NULL option on nullable columns. SET types get the same treatment, ENUM joins the column-type picker for new tables, and the sidebar now matches column metadata by name rather than position, fixing type mismatches when a query's SELECT order differs from the table's.

PostgreSQL followed in PR #471 (fixes #465), where the problem ran deeper: editing an enum cell failed outright with SQLSTATE 42804 — column is of type X but expression is of type text — because the bound value was never cast to the enum type. The binding layer now wraps enum parameters in a CAST($N AS "schema"."type") with the qualified type name resolved from pg_catalog, mirroring the existing temporal/UUID coercions. And since column introspection now aggregates labels from pg_enum into the same enum('a','b',...) shape MySQL uses, the dropdown editor kicks in for PostgreSQL automatically — grid and sidebar both.

MCP Safety: EXPLAIN ANALYZE Is Not a Read

The MCP safety layer classifies queries so read-only mode and the write-approval prompt can gate them. Its classifier mapped anything starting with EXPLAIN to the read-only path — but EXPLAIN ANALYZE DELETE ... actually executes the DELETE. An AI agent could therefore slip a write past both gates by wrapping it. Thanks to @daniel-mertz for reporting it; PR #456 makes classification option-aware: a plain EXPLAIN stays a read (it only plans), while the presence of the ANALYZE option classifies the wrapped statement as if it had been submitted directly. Matching is word-boundary aware — a table named analyze_runs doesn't trip it — and unbalanced option lists fail closed.

Two more MCP improvements landed alongside it. @erneztox fixed list_connections to serialize all of a connection's databases instead of collapsing them, and added a dedicated list_databases tool in PR #426, complete with AI Activity filtering and documentation across all translated READMEs. And the repo now has a security policy documenting how to report vulnerabilities privately — with MCP safety-layer bypasses under an untrusted-input threat model explicitly called in scope.

Windows Stops Flashing Terminals

Two independent contributors fixed the same class of Windows papercut in the same release. Launching a console executable from a GUI app on Windows allocates a visible console window — so an SSH tunnel popped an ssh.exe terminal, and starting a plugin popped another.

@kennelken fixed the SSH side in PR #418 (fixes #413), spawning ssh.exe with the CREATE_NO_WINDOW flag — and went further: SSH child processes used to outlive the app, so the fix also hooks Tauri's exit event to tear down every active tunnel when Tabularis closes. No more orphaned ssh.exe in Task Manager. @erwin-lovecraft applied the same CREATE_NO_WINDOW treatment to plugin processes in PR #451, keeping the stdin/stdout pipe communication intact.

Grid and Editor Refinements

• Column headers actually stay pinned. @thomaswasle fixed the result grid's sticky header in PR #433 — the old implementation fought the virtualizer with a counter-transform that desynced after ~40 rows of scrolling. The grid now uses spacer rows so position: sticky works unconditionally, and a Sticky column headers toggle in Settings → Appearance keeps the old behavior available.
• Hover a header, see the type. @benedettoraviotta added a DataGrip-style tooltip in PR #436 (closes #435) showing name: type — e.g. id: uuid — on column header hover, read from metadata already in hand, so it costs no backend round-trip.
• Set Empty knows its limits. The quick action used to write a single space to any non-BLOB column, which strongly-typed columns rejected (column is of type uuid but expression is of type text). PR #442 gates it to textual columns, writes a real empty string, and swaps its icon for an eraser.
• Summon IntelliSense on demand. @GabrielMalava added a configurable shortcut in PR #371 to force the SQL editor's suggestion widget open (⌘I on macOS, Ctrl+I on Windows, Ctrl+Space on Linux) — remappable in Settings → Keyboard Shortcuts, working in both the editor and notebook cells — plus a new rebindable refresh table keybinding.
• Disconnected means disconnected. Disconnecting your last open connection didn't persist the change, so the next launch auto-reconnected and restored its tabs anyway. PR #467 persists the session at disconnect time; the saved tab file stays on disk, so manually reconnecting later still restores your queries.

Tabularis Speaks Tagalog

@chriscupas contributed a complete Tagalog locale in PR #457 — 1,574 translated strings, a translated README, and browser-locale detection that maps Filipino (fil) systems to it automatically. That makes nine UI languages. @pokertour also brought French back to parity in PR #445, adding the 66 keys that had accumulated in English only — triggers, result colors, timezone settings and more.

Smaller Things

• Typo-tolerant connection search (@Davydhh, PR #444) — the connection search joins the table filters and Quick Navigator on Fuse.js fuzzy matching, so postgre prod finds what you meant, ranked by closeness.
• SSH connections get a Settings tab (PR #441) — saved SSH tunnels are now manageable from Settings, not just from inside the connection-creation modal, and deleting one warns how many database connections still reference it.
• No more autocorrect in filters (@Necriso, PRs #432 and #437) — spellcheck, autocorrect and autocapitalize are off in the table toolbar and filter inputs, where they never belonged.
• Visual fixes (@math-krish, PR #461) — auto-pagination colors (fixes #448), dropdown menu font (fixes #446), and the save menu that appears on edit.
• Modal consistency pass (PR #440) — the last window.confirm() calls replaced with the app's ConfirmModal, Escape now closes the trigger/routine/explain modals like every other one, primary fields autofocus, and a batch of hardcoded strings moved to i18n across all locales.

Thanks

Fourteen external contributors land in v0.15.0 — the widest tag yet.

@pokertour owns the export story: password-encrypted connection exports (#447), export-only-the-selection (#469), and the French translation catch-up (#445). @p4pupro built nested connection groups (#405). @chriscupas translated the entire app into Tagalog (#457).

@fhriz brought ENUM dropdown editing to MySQL (#455). @kennelken silenced the Windows SSH console window and cleaned up tunnels on exit (#418); @erwin-lovecraft did the same for plugin processes (#451). @thomaswasle fixed the sticky result headers (#433), @benedettoraviotta added the column-type tooltip (#436), and @GabrielMalava added the IntelliSense trigger shortcut (#371).

@erneztox fixed multi-database serialization in MCP and added list_databases (#426). @Davydhh made the connection search fuzzy (#444), @Necriso killed autocorrect in the filters (#432, #437), and @math-krish cleaned up pagination colors, the dropdown font and the save menu (#461). And thanks to @daniel-mertz for responsibly reporting the EXPLAIN ANALYZE safety bypass.

If you've been meaning to switch from DBeaver but dreaded retyping thirty connections, if your team shares connection files, or if your database leans on ENUMs — this is the upgrade.

v0.15.0 is available now. Update via the in-app updater, or download from the releases page.

If you've ever installed Tabularis on Windows, you've probably met the blue screen. Not that blue screen — the other one. "Windows protected your PC." The one where a perfectly ordinary open-source database client gets treated like something you downloaded from a forum signature in 2009, and the install instructions have to include the phrase click "More info", then "Run anyway".

That screen exists because unsigned binaries are, from Windows' point of view, anonymous. And it goes away with a code signing certificate — which, for years, has been the single most disproportionate expense an open-source desktop project can face. Hundreds of dollars a year, identity validation paperwork, and increasingly a hardware token requirement, all to prove that a project whose entire source code is public is not hiding anything.

So here's the news: Tabularis has been accepted into the SignPath.io open source program. The SignPath Foundation provides free code signing certificates to qualifying open-source projects — and over the next few weeks, we'll be working on integrating SignPath into our release pipeline so that Windows builds ship signed.

What SignPath actually does (and why it's clever)

The obvious version of this program would be "here's a certificate file, good luck." SignPath's version is better, and it's worth explaining why.

The private key never touches our machines. It lives on SignPath's Hardware Security Modules, and signing happens as a step in the release pipeline: CI builds the artifacts from the public repository, SignPath verifies that the binary being signed actually came from that repository, and only then applies the signature. The certificate doesn't just say "someone signed this" — it says this exact binary was built from that exact public source tree, and the SignPath Foundation vouches for the link.

For users, that's a stronger promise than most commercial software makes. You can read the code, and you can verify the thing you downloaded is that code. No trust-us step in the middle.

For us, it means no key material sitting on a build machine waiting to be leaked, no USB token taped inside someone's desk drawer, and no yearly renewal invoice for a nights-and-weekends project.

The honest part: it's not wired up yet

Being accepted is the milestone; the engineering starts now. That provenance guarantee — this binary came from that repository — is exactly what makes the integration non-trivial. SignPath doesn't sign whatever you upload; it signs what your pipeline provably built. Which means the work ahead of us looks like this:

• Restructuring the release workflow so the Windows artifacts flow from CI through SignPath and back before they're published — signing becomes a pipeline stage, not an afterthought.
• Getting the build to verify cleanly. The link between the public repo and the submitted binary has to hold up to SignPath's checks, and desktop app builds have a way of accumulating steps that make provenance harder to trace than it should be.
• Not breaking releases while we do it. Tabularis ships roughly every two weeks, and that cadence doesn't pause for plumbing work.

We'd rather tell you this now and write the "it's live" post when it's actually live, than quietly flip a switch and hope nobody checks the dates. If you're curious how it goes, the work will happen in the open like everything else — watch the repo.

What will change for you

Once the integration lands, if you're on Windows:

• SmartScreen stops interrogating you. The installer will carry a valid signature, so new releases install like any other signed software — no "unknown publisher", no "Run anyway".
• The publisher name means something. The signature identifies the build as coming from the Tabularis open-source repository, certified by the SignPath Foundation.
• Tampering is detectable. If a downloaded installer has been modified anywhere between our CI and your disk, the signature breaks and Windows tells you.

If you're on macOS or Linux, nothing changes today — but fewer scary dialogs on any platform makes the whole project easier to recommend, and that helps everyone.

In line with the program's terms, we'll be adding the credit to our README: free code signing provided by SignPath.io, with a certificate from the SignPath Foundation. It's the easiest attribution requirement we've ever agreed to, given that the alternative was a recurring bill.

The usual thank-you, because it keeps being deserved

To the SignPath team: thank you for running a program that fixes a genuinely broken part of open-source distribution, and for an acceptance process that was thorough about the right things — code provenance and project health — rather than paperwork.

And to everyone who's starred the repo, filed a bug, built a plugin, or translated a string: programs like this accept projects that look alive, and Tabularis looks alive because of you. One "Run anyway" at a time, we're becoming real software.

The Tabularis Team

v0.14.0 bumps the minor line because it stops being a database viewer in a few more places and starts being a database client. It manages stored procedures and functions the way it already manages tables and views, it lets a connection live in its own window, it browses PostgreSQL materialized views, and — the change everyone will feel eventually — it asks before you run the query that wipes a table. It follows v0.13.4, and like that release most of the surface area came from the community: @Davydhh alone lands six of the changes below.

Manage Stored Routines, Not Just Tables

Stored procedures and functions have always been visible in the sidebar. As of v0.14.0 you can actually do something with them. PR #416 adds full routine management — run, create, edit, and drop — behind a new routine_management driver capability enabled for MySQL and PostgreSQL out of the box.

• Run with parameters. A modal collects each IN/INOUT value — with a NULL checkbox and a raw-value toggle that defaults on for numeric types — and the driver assembles a reviewable invocation script before anything executes. MySQL OUT/INOUT parameters are threaded through session variables (SET / CALL / SELECT @var); PostgreSQL functions run as SELECT * FROM fn(...), so a set-returning function comes back as an actual result set.
• Create from a template. A dialect-aware starter script — DELIMITER-wrapped for MySQL, CREATE OR REPLACE with dollar-quoting for PostgreSQL — so you're editing a valid skeleton, not a blank buffer.
• Edit the definition. A re-runnable script: MySQL wraps SHOW CREATE in a DROP IF EXISTS + DELIMITER block, PostgreSQL reuses pg_get_functiondef.
• Drop with confirmation. PostgreSQL resolves the exact identity signature via pg_get_function_identity_arguments and refuses to guess between overloads rather than dropping the wrong one.

For plugin drivers the four new methods are optional JSON-RPC calls: when a plugin doesn't implement one, the host falls back to the same generic SQL, so a driver only overrides what its dialect actually needs. The manifest schema documents the capability.

A Connection in Its Own Window

The results panel learned to detach in v0.13.4. In v0.14.0 the connection itself can. PR #409 adds an Open in New Window action to both connection context menus — the open-connections sidebar rail and the Connections page — that spins a connection out into its own standalone OS window.

The plumbing is the interesting part. Connectivity is validated before the window is spawned: the connection is test-connected first and the window is only created on success, so a failing connection surfaces its error in the window you're already in rather than a freshly-opened empty one. A connection opened in a new window is owned by that window and detached from the originating sidebar rail, though its process-global pool stays warm and is reused. Open-state is shared across every window — a connection open anywhere shows as open in every window's Connections page, broadcast via a new connections:active-changed event. Disconnecting closes the dedicated window (the main window is never auto-closed), and closing a dedicated window tears its connection down so nothing leaks.

Confirm Before You Wipe a Table

A DELETE or UPDATE with the WHERE clause forgotten is one of the oldest ways to lose data with no way back. PR #429 puts a guard in front of it. Both the SQL editor and notebook cells now detect a DELETE/UPDATE with no WHERE, as well as DROP and TRUNCATE, and ask for confirmation before the query is sent.

The detection isn't a naive substring match: it looks past comments and string literals (including backslash-escaped quotes), understands data-modifying CTEs, and handles multi-statement batches. The dialog shows kind-specific copy and a read-only preview of the exact statement it flagged, and the confirm button stays disabled for a five-second countdown — long enough that the warning is actually read instead of reflexively dismissed.

PostgreSQL Materialized Views

@Davydhh added first-class materialized view support for PostgreSQL in PR #342. They show up as their own sidebar group (collapsed by default), gated on a driver capability so only databases that have them render the section. You get an in-flight spinner while a refresh runs, the same index-list rendering that tables use, and the view's columns — resolved against the active schema. They're read-only in the data grid, as a materialized view should be.

Find Things by Typo

Three changes, all from @Davydhh, make finding an object forgiving of how you actually type.

The table and trigger filters swapped their substring match for Fuse.js fuzzy matching in PR #417, so ordrs still finds orders and the closest names rank first — applied across the schema, per-database, and flat sidebar layouts through one shared helper. The Quick Navigator got the same treatment in PR #421. And PR #412 adds a rebindable focus-table-filter shortcut (⌘⇧F / Ctrl+Shift+F) that jumps straight to the filter box in whichever layout is showing, even while another input has focus.

Know Exactly How Many Rows

The pager used to tell you which page you were on but not how big the result was. PR #410, also from @Davydhh, displays the exact {total} rows next to the page indicator — and counts the right query. The old count ran against the base table and ignored the filter box's WHERE, so a filtered grid reported the unfiltered total; it now counts the reconstructed filtered query. The count resets when the query or filter changes so a stale number from a previous run never lingers, but it's preserved across pagination.

MySQL Through Warpgate

@pokertour added an opt-in cleartext password plugin toggle for MySQL/MariaDB in PR #337 (closes #336), so connections can authenticate through bastions like Warpgate that require the mysql_clear_password auth plugin. Because those bastions proxy MySQL without implementing the prepared-statement protocol, any prepared query failed with server error 1047; when the toggle is on, the driver routes everything through the text protocol instead. The option is gated on an enforced TLS mode — cleartext credentials are refused over a link that could silently fall back to plaintext — and string literals become sql_mode-aware so NO_BACKSLASH_ESCAPES targets escape correctly. A pool cache-key collision that let two Warpgate targets behind one host:port share a pool was fixed at the same time.

Correctness, Across the Board

• Temporal and UUID cell edits on PostgreSQL (@NewtTheWolf, PR #408, fixes #401) — editing a timestamp/timestamptz/date/time/interval cell failed with error serializing parameter because the client inferred the parameter type from the cast target and rejected the bound string before PostgreSQL's own parsing ran. Every bound parameter now declares its wire type explicitly via prepare_typed/execute_typed, which also finishes the UUID-shaped-string fix that #394 only started. Verified against a live PostgreSQL 16.
• Composite indexes in generated SQL (@snvtac, PR #373) — multi-column indexes are preserved in the SQL Tabularis generates instead of being flattened to single-column ones.
• MySQL view DDL through the text protocol (@danielnuld, PR #390) — view DDL is routed through the text protocol so it executes correctly.
• MySQL routine DDL through the text protocol (@Stiwar0098, PR #348) — the same treatment for routine DDL, and compound routines are now classified as DDL in the MCP layer (#385).
• Qualified view definitions on PostgreSQL (@debba, PR #400) — pg_get_viewdef was called with $1::regclass directly, which failed for a bound text value; casting through text first (($1::text)::regclass) resolves qualified view names correctly.
• Plugin driver filters in the connection modal (@debba, PR #424) — a missing driver field made serde silently drop the filter on ui_extensions manifest entries, so every plugin's connection-content contribution rendered for every driver and plugins could overwrite each other's connection state. The filter is preserved now.

Smaller Things

• Node 24 (@Davydhh, PR #422) — the toolchain moves to Node 24.
• Sidebar filter clear button (@viniciusmelocodes, PR #403) — the clear (X) button no longer overlaps the scrollbar in the table filter.

Thanks

Most of v0.14.0 is community work again.

@Davydhh carried an outsized share of this release: PostgreSQL materialized views (#342), fuzzy matching for the table and trigger filters (#417), fuzzy search in the Quick Navigator (#421), the focus-table-filter shortcut (#412), the total-row-count display (#410), and the Node 24 upgrade (#422).

@pokertour added MySQL cleartext-auth support for Warpgate bastions (#337). @NewtTheWolf fixed temporal and UUID cell edits on PostgreSQL via explicit wire types (#408). @Stiwar0098 routed MySQL routine DDL through the text protocol (#348) and classified compound routines as DDL in the MCP layer (#385).

@snvtac preserved composite indexes in generated SQL (#373), @danielnuld routed MySQL view DDL through the text protocol (#390), and @viniciusmelocodes fixed the sidebar filter's clear button (#403).

If you manage stored procedures, spread work across monitors, run against PostgreSQL materialized views or a Warpgate-fronted MySQL, or have ever typed a DELETE faster than you meant to — this is the upgrade.

v0.14.0 is available now. Update via the in-app updater, or download from the releases page.

There's a small loop closing here that we find genuinely funny: several of the people who write Tabularis do it inside a JetBrains IDE, and now JetBrains is backing the project on the other side of that screen. We've been accepted into the JetBrains Open Source Support program, which comes with a free annual All Products Pack for the maintainers — every IDE they make, one license.

IntelliJ IDEA, WebStorm, PyCharm, GoLand, RustRover. Chances are you've had one of these open recently too. Unlike some of the sponsors we've written about here, this isn't a product we discovered because of the deal. We already had it installed.

That's really the whole story, and it's a short one, so we'll spend the rest of this post on the part that's more interesting than the announcement itself.

When the tool sponsors the tool

DigitalOcean's credits went into infrastructure nobody using Tabularis will ever see. Vercel's program upgraded the pipeline behind this very website. Both are real and useful and mostly invisible. This one is different in a way that's hard to put a dollar figure on: it's not infrastructure, it's craft. Faster indexing on a codebase that's grown past what "small project" used to mean. Refactors that don't require holding the whole call graph in your head. A debugger that doesn't fight you. None of that ships a feature by itself, but all of it is the difference between an evening of focused work and an evening of fighting the tool instead of the problem.

We build Tabularis because we think working with data shouldn't be this painful. Turns out the editor felt the same way about us.

The terms, for anyone curious how these programs actually work: stay open source, stay maintained, put a small credit somewhere visible. No equity, no roadmap say, nothing that changes what we ship or when. Just one more expense a nights-and-weekends project doesn't have to carry anymore.

The part we say every time because it's still true

To the JetBrains Open Source team specifically, for turning an email exchange into licenses with zero friction, thank you.

And to everyone who's starred the repo, opened a plugin, filed a bug, or translated a string: a four-month-old project doesn't get picked up by the tools it's built with unless it looks like it's going somewhere. That impression is entirely yours. We just write the code — increasingly, apparently, on someone else's dime.

The Tabularis Team

These days most of the SQL entering a codebase was written by a language model. I don't think this is a problem in itself: models have read more SQL than any of us ever will, and for the everyday query, the three-way join with a couple of aggregations, they are fast and usually correct. I use them for this all the time. The writing was never the sacred part of the job.

What worries me is a second-order effect that I started noticing in code reviews, my own included. A pull request arrives with a forty-line query in the middle, the tests pass, the data looks plausible, and the review comment says "LGTM". The reviewer did not really read the query. Often the author did not read it either, in any meaningful sense, because an agent wrote it and the output looked reasonable. Every single step of this is a rational decision, and the sum is a query in production that no human being has ever actually understood.

For most languages I would shrug at this. But reading skill and writing skill, while different things, were historically funded by the same activity: you learned to read queries by writing bad ones first and debugging them. Now the writing is gone, so the reading is decaying, and at the same time the volume of generated SQL is going up. Fewer readers, more text. That's a bad combination anywhere — but SQL is a special case, and I want to explain why I believe it is the worst possible language for this to happen to.

SQL fails differently

The cost of a query is invisible in its text. SQL is declarative: the query says what you want, the database decides how to get it, and two queries that look almost identical can differ by three orders of magnitude at runtime. You cannot see a sequential scan over four million rows by staring at the SELECT statement, no matter how experienced you are. With imperative code, a triple nested loop at least looks suspicious. In SQL the truth is simply not on the page: it lives in the execution plan — a thing almost nobody looks at voluntarily, and which the model that generated the query has never seen at all.

Wrong SQL usually works. A subtly wrong query does not crash: the LEFT JOIN that should have been an inner join silently multiplies rows, the WHERE clause that mishandles NULL silently drops records, and the result set still looks completely plausible. The dashboard renders. Somebody makes a decision based on it. Your test suite does not catch this, because the fixture has forty rows and the bug needs four million, or needs that one customer with two addresses. This is the category of bug that surfaces months later as a number that has been wrong since March — and it is exactly the category where a human reading the query carefully would have helped.

The inversion

So my feeling is that we are heading into a strange inversion. For twenty years "can write SQL" was the skill you put on a resume. That is now table stakes, the agent writes it. The skill that is becoming scarce, and therefore valuable, is being able to look at a query you did not write and answer two questions: does it mean what we think it means, and what is it going to cost? The first is a question about semantics — row multiplicity, NULL behavior, what that DISTINCT is papering over. The second is not a question about the query at all: it is a question about the plan.

The developers who can answer both are turning into the editors of what the machines write, and editors were always rarer than writers. Maybe I'm wrong and models will get good enough at self-reviewing that human reading will stop mattering; but for now they can't even see the plan, so I would not bet on it yet.

Reading has to get cheaper

The standard prescription at this point would be that developers should study SQL more, and I don't believe in it, for the same reason virtue-based prescriptions never work: nobody has slack for homework, and willpower loses against deadlines every single time. If reading matters more than before, reading has to become cheaper. That's a tooling problem, not a discipline problem.

This is, honestly, a big part of why I build Tabularis the way I do. The visual query builder works in both directions: you compose a query visually, and it always shows you the SQL it is generating, so the tool doubles as a reading tutor without asking anything from you. The AI assistant can explain a query you inherited instead of just writing new ones. And for the cost question — the one the text cannot answer — visual EXPLAIN renders the execution plan as an interactive graph where the expensive node is red and the estimate that is off by 40x is highlighted, instead of buried at line 60 of a text dump:

(There is a longer walkthrough in the visual EXPLAIN wiki page.)

Note that none of this is an anti-AI position — there is a model in the loop right there in the previous paragraph. The position is narrower: generation without inspection is debt, and since the generation became effortless, the inspection has to become effortless too, otherwise it simply stops happening. Which is what we are watching happen.

If you want to keep the muscle without doing homework, there is a very small habit that I can suggest. Next time an agent hands you a query, before running it, spend thirty seconds making two predictions: roughly how many rows it should return, and which table will dominate the cost. Then run it and check. When you are right, you spent thirty seconds. When you are wrong, you found either a bug or a hole in your mental model of your own data, and both are worth much more than the time.

The machines write well now, better than most of us on a Tuesday afternoon. Someone still has to be able to tell when what they wrote is not what we meant. For the moment, that someone is necessarily human, and there are fewer of them every year. It seems like a good year to be one.

v0.13.4 follows v0.13.3, which was about making the app feel like yours. This one is about the moments where the app has to get out of your way: an SSH tunnel that can finally ask you for a PIN instead of failing silently, query results that pop into their own window when one screen isn't enough, and an editor that completes, formats, and confirms what you typed. It's another release carried by the community — nine external contributors land in this tag, including a wave of new database drivers.

SSH That Knows How to Ask

Until now an SSH tunnel could only authenticate non-interactively — a key on disk, an agent, a password you'd stored. If your key lived on a hardware security token (a YubiKey or any FIDO/PKCS#11 device) that wants a PIN or a touch, or your private key was passphrase-protected and not in an agent, the connection just couldn't get off the ground. v0.13.4 fixes that by letting SSH prompt.

@robertpenz contributed the core support for security-key authentication in PR #262: when the token needs a PIN to unlock, Tabularis now surfaces that request instead of giving up (tested against a hardware key on Fedora 43). To make the prompt safe and native rather than a terminal popup, the maintainer built a small in-app askpass service around it — an isolated askpass server and protocol that intercepts SSH's credential requests and serves them through a proper in-app modal, with forced interactive auth so passphrase- and PIN-protected keys are actually usable.

The result: when a tunnel needs a passphrase, a security-key PIN, or a password mid-connect, you get a clean modal asking for exactly that, and the secret goes straight to SSH without touching disk. A per-connection "allow interactive prompts" toggle in the connection modals keeps the behavior opt-in, and the prompt strings are localized across all eight languages. If you've been stuck unable to use a YubiKey-backed jump host, this is the release that unblocks you.

Detach Your Results Into Their Own Window

The query results panel had a single chevron to collapse it and not much else. PR #369 turns its header into the familiar set of window controls — and lets you pop results out entirely.

The right side of the results bar now carries Minimize, Maximize, Detach, and Close. Minimize and Close collapse the panel without losing data — the existing "Show Results" button brings it back. Maximize hides the editor so results take the full height, and clicking it again restores the split. Manual drag-to-resize is untouched. The new one is Detach: it pops the active tab's results into a separate OS window, so you can keep the grid on a second monitor while you keep editing SQL on the first. The detached window stays in sync with the tab it came from, and closing it folds the results back into the main layout.

A Smarter SQL Editor

Three changes converge to make the editor read your intent better.

Autocomplete, rebuilt. @m-tonon (Matheus Tonon) reworked how SQL autocomplete is wired up in PR #267: a shared useSqlAutocompleteRegistration hook now manages the Monaco completion provider for both the editor and the notebook, so there are no more stale or duplicated providers when you switch connections or open a new cell. The same work fixes aliased PostgreSQL columns — SELECT u."FirstName" FROM users u now completes u. against the real quoted column names — and @NewtTheWolf folded in a fix so accepting a completion for an already-quoted identifier no longer doubles the quotes.

Beautify in the view editor. @danielnuld added a one-click Beautify button to the view editor (create and edit) in PR #372. Databases hand back view definitions as a single dense line — MySQL stores SELECT c.id,c.name,... with no whitespace at all. The button runs the definition through sql-formatter with the active driver's dialect, so it's actually readable before you start editing.

Success feedback for non-SELECT statements. Also from @danielnuld, PR #391 replaces the misleading "0 rows retrieved" empty grid you'd get after an INSERT/UPDATE/DELETE or a DDL statement with an explicit success panel — a check icon, "Query executed successfully", the affected-row count when there is one, and the execution time. It works for both single statements and multi-statement batches.

Collapse Notebook Sections Individually

Notebook cells could only be collapsed as a whole. PR #399 adds independent collapse for the three areas inside an SQL cell — the query editor, the results grid, and the chart — on top of the existing master cell collapse. Each area gets a thin labelled header with a chevron, the chart section appears only when the result is chartable, and the collapsed state of every section is saved with the notebook so it sticks across reloads. Chart visibility is persisted too now — it used to reset on every reload — defaulting to whether a chart config already exists, so older notebooks keep showing their charts exactly as before.

A Startup Script Per Connection

@boredland added an optional startup script to a connection in PR #352 (closes #350). It's SQL that runs on every new pooled connection, so session-level settings stick across the whole pool no matter which physical connection serves a given query — the DataGrip-style behavior people asked for. The motivating case is RLS-bypass-in-dev: a SELECT set_config('app.bypass_rls', 'on', false); (or any SET) now applies to every query instead of randomly depending on which pooled connection you landed on. It's executed per physical connection — MySQL/SQLite via sqlx after_connect, Postgres via deadpool post_create — blank scripts are skipped, and the script is stored with the connection as non-secret config.

Three New Community Drivers

The plugin ecosystem keeps growing. Three drivers join the registry this cycle, all community-built and installable from Settings → Plugins:

• MongoDB by @danielnuld (#368) — connects to MongoDB 6.0+ via the official Rust driver (rustls, no system dependencies). Multi-database browsing, schema inference by sampling, native shell queries (db.coll.find/aggregate/... and CRUD), SQL grid-filter translation to MongoDB filters, index management, and ObjectId-aware inline editing. Ships for Windows, Linux (x64 + arm64), and Apple Silicon. Source.
• Cloudflare D1 by @NewtTheWolf (#376) — browse and manage Cloudflare's D1 serverless SQLite databases. Linux and Windows builds in its v0.1.0 release.
• DM (Dameng) by @haos666 (#382) — the Dameng database driver, with macOS, Linux, and Windows assets. The Dameng JDBC driver jar stays user-provided.

That brings the community driver roster — alongside the built-in MySQL, Postgres, and SQLite — to a long and growing list, with Dameng also added to the README's supported-databases section.

Oracle and Dameng SQL Block Splitting

@haos666 extended the SQL splitter to understand Oracle- and DM-style blocks in PR #325 (a follow-up to the earlier splitter work). Behind the existing oracle dialect, it now treats a line-leading / as a statement terminator, folds PL/SQL-style source units instead of splitting on internal semicolons, understands Oracle q/nq-quoting so a ; or / inside a quoted literal doesn't split a statement, and recognizes DM-specific block openers (CREATE CLASS, CREATE CLASS BODY, CREATE JAVA CLASS). Every change is dialect-gated, so the other presets are structurally unchanged.

Correctness, Across the Board

A run of fixes that quietly make queries do the right thing:

• Composite primary keys in edits (@thomaswasle, PR #324) — editing or deleting a row in a table with a composite primary key used to send only the first PK column, so the UPDATE/DELETE could hit every row sharing that partial key. The frontend now carries the full PK as a map and every command and driver (MySQL, SQLite, Postgres) builds a compound WHERE col1 = ? AND col2 = ? AND … clause.
• Vitess / PlanetScale connections (@debba, PR #387, closes #383) — connecting failed immediately with setting the PIPES_AS_CONCAT sql_mode is unsupported because sqlx sets that mode on every connection and Vitess rejects it. Tabularis now auto-skips PIPES_AS_CONCAT and NO_ENGINE_SUBSTITUTION so Vitess-backed databases connect.
• MySQL pagination after semicolons (@Stiwar0098, PR #389, closes #388) — paginated SELECTs no longer leave LIMIT/OFFSET stranded after a trailing semicolon or comment, with hardened scanning for MySQL/MariaDB comment and quoting syntax.
• PostgreSQL < 11 routine introspection (@earmellin, PR #377, fixes #375) — pg_proc.prokind only exists from PG 11, so routine browsing threw 42703 on 9.x/10. Introspection now picks a version-appropriate query; tested against PostgreSQL 9.6.
• UUID-shaped keys in varchar columns (@NewtTheWolf, PR #394) — a primary key that looks like a UUID but lives in a varchar column is now bound as text, so editing those rows no longer fails a type check.

Smaller Things

• Accessibility for screen readers (@arturbent0, PR #355, fixes #86) — Monaco's accessibility support is on so screen readers read typed text without focus jumping to suggestions, the Run button announces its shortcut, DataGrid headers gained role/aria-sort/keyboard support, the connection-test result is an aria-live region, and sidebar expanders are real buttons.
• Manual update check unblocked (@debba, PR #398) — "Check for Updates Now" kept reporting "You're up to date" after you'd dismissed an earlier update notification. A dismissed version no longer suppresses an explicit manual check.
• Export from plugin-driver connections (@danielnuld, PR #366) — Export as CSV/JSON used to fail with Unsupported driver for export on any external plugin driver. It now pages through the driver's own execute_query so plugin-backed connections (Informix, MongoDB, …) can export too.
• Informix 32-bit Windows build (@danielnuld, PR #367) — the Informix plugin ships its 32-bit build on the Windows slot.
• Plugin trigger capability docs aligned (@haos666, PR #317) — external-plugin trigger capability and metadata documentation now match the implementation.

Thanks

Nine external contributors land in v0.13.4 — once again, most of this release is community work.

@robertpenz contributed SSH security-key authentication (#262), the feature the whole interactive-prompt flow is built around.

@m-tonon (Matheus Tonon) rebuilt the SQL autocomplete registration and fixed aliased PostgreSQL column completion (#267), and @NewtTheWolf fixed quoted-identifier double-quoting, added the Cloudflare D1 driver (#376), and bound UUID-shaped varchar keys as text (#394).

@danielnuld landed the view-editor Beautify button (#372), non-SELECT success feedback (#391), plugin-driver export (#366), the Informix 32-bit build (#367), and the MongoDB driver (#368).

@haos666 extended the SQL splitter for Oracle/Dameng blocks (#325), aligned plugin trigger docs (#317), and added the DM (Dameng) driver (#382).

@boredland added per-connection startup scripts (#352), @thomaswasle fixed composite-PK edits (#324), @Stiwar0098 fixed MySQL pagination after semicolons (#389), @earmellin restored routine introspection on PostgreSQL < 11 (#377), and @arturbent0 improved screen-reader accessibility (#355).

If you authenticate over SSH with a hardware key, work across two monitors and want results on their own, lean on autocomplete, run against Vitess/PlanetScale or an older Postgres, or connect to MongoDB, Cloudflare D1, or Dameng — this is the upgrade.

v0.13.4 is available now. Update via the in-app updater, or download from the releases page.

Secrets are invisible right up until they leak. Nobody opens a project and admires how tidily its signing keys are stored; they only ever notice the opposite: a token committed by accident, a certificate that expired over the weekend, a "who even has access to this?" message in a thread at 2am. It's unglamorous, easy-to-postpone work, and like localization it quietly decides how much you trust the thing you shipped.

Tabularis is open source and funded out of pocket, which means the boring infrastructure is all ours to get right. And the part we'd been putting off was the most boring of all: where the project keeps its secrets.

The mess we'd been living with

A desktop app that ships real builds accumulates real secrets. For Tabularis that's a Tauri updater signing key, an Apple Developer certificate plus notarization credentials, a Windows code-signing setup, an npm token, a Vercel deploy hook, a handful of GitHub tokens. None of it is exotic. All of it is sensitive, and all of it has to be reachable from CI to cut a release.

The default way you end up doing this is: paste each value into Settings → Secrets on GitHub, one repo at a time, and move on. It works, and that's exactly the problem. It works just well enough that you never fix it. The values live in a place you can't read back. Rotating one means remembering every repo and workflow that uses it. There's no audit trail worth the name, "access" is whoever has admin on the repo, and the canonical copy of a signing key ends up being a text file in a downloads folder, because that's the only place you can actually still read it.

We didn't want a tidier spreadsheet of secrets. We wanted the pasted-into-GitHub copies to stop being the source of truth at all.

1Password, and being honest about what this is

Here's the part we want to be upfront about. 1Password runs a free plan for open-source projects, we applied like anyone can, and we qualified. That's the whole story: we asked, and they gave Tabularis the paid product for free. We'd rather say it plainly than dress it up.

And 1Password asks for nothing in return. They require no blog post, no homepage logo, no "sponsored by" badge, nothing at all. The credit we give them, here and on our site, is entirely our choice and not a deliverable anyone asked for. We're doing it for one reason: the product is genuinely good, the program is a genuinely generous thing to offer maintainers who are footing the bill themselves, and more of them should know it exists. Credit where it's due, freely given.

And 1Password really is the good kind of tool. It's been the quiet standard for a long time because it gets the fundamentals right: strong, audited cryptography; your data encrypted with a key only you hold; a UX polished enough that using it is easier than not using it, which is the only property that actually makes a security tool get used. For a maintainer it turns "where's that key" from a small recurring panic into a non-event. That alone would have been worth the thank-you.

It's quietly fixed the un-glamorous day-to-day, too. A project is more than a codebase: there are the social accounts we post from, a domain registrar, analytics logins, the npm org. Those used to live in the worst possible place: a couple of reused passwords and a notes file. Now they're in a shared vault. The X, Bluesky and Mastodon accounts get handed off securely instead of pasted into a DM; weak and reused passwords are gone; and where a service supports it we're on passkeys and 1Password-generated one-time codes instead of an SMS or a PIN someone could guess. It's the kind of upgrade you only notice the first time you don't have to ask "wait, what's the login for the Mastodon account again?"

But the reason it changed how we work is the developer side.

1Password is genuinely built for developers. You can integrate it across a whole workflow: managing SSH keys and signing Git commits, authenticating CLIs with biometrics instead of pasted tokens, and securing secrets throughout your projects. Several of those have already earned a place in how we build Tabularis, and one more is next on the list. Here's the one every developer should steal first.

1Password as a secret manager for GitHub

This is the part every developer should know about, however you came to 1Password.

1Password isn't just a vault you copy values out of. It's a secret manager you can wire directly into your pipeline. The model is delightfully blunt: instead of storing a secret's value in GitHub, you store a reference to where it lives in 1Password, written as a op://vault/item/field URL. The real value never touches your repo settings.

You create a 1Password service account scoped to a single CI vault, and the one secret you put into GitHub is its token. Everything else becomes a secret reference that the load-secrets-action resolves at runtime:

- name: Load secrets from 1Password
  uses: 1password/load-secrets-action@v2
  with:
    export-env: true
  env:
    OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
    TAURI_SIGNING_PRIVATE_KEY: op://CI/Tauri/key
    APPLE_CERTIFICATE: op://CI/Apple/cert
    NPM_TOKEN: op://CI/npm/token
    VERCEL_DEPLOY_HOOK: op://CI/Vercel/hook

Read that workflow and the whole pitch is right there. The only literal secret in GitHub is OP_SERVICE_ACCOUNT_TOKEN. Every other line is just an address. The values live in 1Password, get fetched into the job, and are masked in the logs, and when the job ends, they're gone.

What that buys you, concretely:

• One source of truth. The vault is canonical. GitHub holds an address book, not a key ring.
• Rotation is a single edit. Change the value in 1Password once; every workflow that references it picks up the new one on its next run. No hunting through repo settings.
• Real access control and audit. Who can see a secret is vault membership, not repo-admin-by-accident, and 1Password actually logs it.
• The same secrets work locally. With the 1Password CLI you reference the exact same op:// items from a dev machine, via op run -- pnpm release, so the credentials you test a release with are literally the ones CI uses. No drift, nothing copied to disk.

It's the same idea that makes Tabularis itself worth using: keep the sensitive thing in one trustworthy place, and reference it everywhere else instead of making copies. (Tabularis stores your database credentials in the OS keychain for exactly that reason: no account, no copies on a server.) Seeing 1Password apply the same principle to CI is what sold us.

The part that already works today: SSH

The CI migration is still ahead of us, but there's one 1Password feature that already pays off inside Tabularis right now, with zero setup on our side: the SSH agent.

1Password can hold your SSH keys and act as your system's SSH agent, so the private key never sits unencrypted on disk and every single use is an explicit, approved action. What that means for connecting to a database over SSH in Tabularis is the nicest kind of surprise: it just works out of the box. Pick an SSH connection, leave the key-file field empty, hit connect, and the 1Password window pops up. You approve with Touch ID (or however you've set it), and you're connected. No key file to hunt down, no passphrase to paste, no agent to wire up by hand.

We didn't build an integration for this, and that's the whole point. Tabularis talks to the system SSH agent like any well-behaved SSH client, and 1Password registers itself as that agent. The two meet in the middle, and the result is that the most secure option is also the least effort. That's exactly the principle we care about: the safe path should be the easy one.

And we'd like to do more of it. The SSH agent is just the first place 1Password and Tabularis happen to meet, and we want to build proper, first-class integration on top: pulling connection credentials straight from your vault, for one, so a database password never has to be pasted into Tabularis at all. One thing we want to be completely clear about: any of this will be strictly opt-in. Tabularis works fully without 1Password and always will. If you don't use it, nothing changes and nothing nags you, and the OS keychain stays the default. This is an extra door for the people who want it, never a requirement for the people who don't.

What we plan to do with it

Here's the plan, and to be clear it is still a plan: we haven't moved a single CI secret across yet. The intent is to take Tabularis' release and deploy secrets out of scattered GitHub repo settings, put them in a dedicated 1Password CI vault, and wire load-secrets-action into the workflows so every job resolves what it needs from op:// references. The end state is the one in the diagram above: a single service-account token in GitHub, everything else an address.

We're deliberately not rushing it. The signing keys are the careful part, and moving them is something we'd rather do once, slowly, than twice. So treat this as a direction we've committed to and a use of the free plan we intend to make, not a migration we've finished. The everyday accounts are already in 1Password; the CI pipeline is the next step.

Thanks

So, plainly: thank you, 1Password. For backing open source with a free plan that lets independent maintainers manage secrets the way larger teams do, and for building a product good enough that adopting it felt like an upgrade rather than a chore. Doing that quietly, for projects you have no commercial relationship with, is a generous thing, and it's worth saying so out loud.

If you maintain something open source and you're still pasting tokens into repo settings one at a time, go look at their open-source program and at using 1Password in GitHub Actions. It's the rare bit of security work that makes your life easier the same day you set it up.

Secrets should be invisible when they're handled right. The least we can do is keep them somewhere we'd trust with our own, and then tell you where that is. Star Tabularis on GitHub to follow along, and keep an eye on the blog.

v0.13.3 follows v0.13.2, which made the notebook, results panel, and grid feel responsive and managed. This one is about making the app feel like yours: results that read at a glance because they're colored by type, an editor that shows you which connection you're in by its color, a new theme, and a workspace that reopens where you left it. It's a release driven almost entirely by the community — ten external contributors land in this tag.

Results, Colored by Type

A grid where every value renders in the same color makes you read each cell to know what it is. v0.13.3 fixes that with customizable result colors, contributed by @GabrielMalava (Gabriel Malavazi Rodrigues) in PR #354.

Turn on Result Colors under Settings → Appearance → General and query result cells are tinted by their data type — numbers, text, dates/times, and booleans each get their own color. The defaults follow your active theme's semantic palette, so it looks coherent out of the box, and a per-type color picker with a live preview and a Reset to theme button lets you tune each one. It's off by default; values render exactly as before until you opt in. Colors apply only to plain data cells — edited, inserted, deleted, and NULL cells keep their existing styling — and the per-column colors are precomputed once rather than recalculated on every render, so there's no scroll cost.

The same PR sharpened in-place editing: pending grid edits now commit with a rebindable save_grid_changes shortcut (Cmd/Ctrl+S, TablePlus-style), and editing single-table SELECT results is validated against the table's real columns first — so an aliased or computed column gives you a clear message instead of a cryptic 1054 Unknown column, and a result missing its primary key is blocked with guidance to include it rather than building an unsafe UPDATE.

Tabs That Wear the Connection's Color

If you keep several connections open, the editor tabs all looked the same — easy to run a statement against the wrong one. PR #333 by @Davydhh (with Davide Cazzetta) ties the whole tab strip to the active connection's color.

The active-tab indicator line now uses the connection color with a soft glow, the active tab carries an accent-tinted body gradient, and inactive tabs pick up an accent wash on hover instead of a flat grey. The loading bar and the rename input border follow the same color, and the tab bar itself uses a vertical accent gradient with an accent-tinted bottom border so the strip reads as part of the connection. The treatment extends into split view: split-pane panel headers and the connection switcher use each pane's accent instead of a fixed blue. When no connection is active it all falls back to the default blue, and the scroll arrows and new-tab buttons stay theme-safe.

A New Theme: Gruvbox

@Wilovy09 added Gruvbox Material, in both Dark and Light, in PR #357 — bringing the built-in count to twelve. Each ships with a matching dedicated Monaco editor theme, so the SQL editor's syntax colors line up with the rest of the UI, and both are wired into the theme registry with sidebar and registry test coverage. Switch to it in Settings → Appearance; like every theme, it applies instantly with no restart.

A Workspace That Remembers

Launching Tabularis dropped you on an empty workspace even if you'd had three connections open when you quit. PR #332, also from @GabrielMalava, adds opt-in session restore: enable it and Tabularis reopens the connections from your previous session on startup, with autoconnect set only after the connection validates so a stale credential can't wedge the launch. The same PR adds a start-maximized option for anyone who always drags the window full-size anyway. Both live in Settings → General.

Copy CSV With (or Without) Headers

When you copied rows as CSV, you got the values but never the column names — fine for pasting back into a query, annoying for pasting into a spreadsheet. @Wilovy09 added a CSV headers toggle in the copy controls in PR #356. A new csvIncludeHeaders setting (persisted in config.json, on by default) and a toolbar toggle let you decide per copy whether the header row comes along, threaded all the way down to the grid with i18n across all eight locales.

Louder MCP Approvals

Approval gates only help if you notice them. @Stiwar0098 closed that gap in PR #311 (closes #307) with an attention flow that fires when a pending approval appears: the window comes to the front via a user-attention request, an OS notification with localized title and body is sent, and an optional alert sound plays. Two new toggles under MCP → Safety — keep the approval window on top while a request is pending, and play an alert sound — let you tune how insistent it is, both localized across eight languages. On Linux the alert now plays through the OS notification sound so it actually reaches you when Tabularis is in the background.

Driver-Aware Kubernetes Connections

The Kubernetes connection dialogs had two rough edges, fixed by @metalgrid in PR #319. The context, namespace, saved-connection, and resource-name selectors are now searchable instead of forcing a scroll through long lists, and the container port no longer hard-codes MySQL's 3306 — it reads default_port from the active driver's manifest, so Postgres lands on 5432, ClickHouse on 8123, and plugin drivers on whatever they declare. The maintainer follow-up added a service port discovery command so the dialog can derive the port from the service's actually-exposed port, plus corrected inline port defaults and localized K8s validation messages across all eight locales.

A Community Informix Driver

@danielnuld built and shipped an IBM Informix driver plugin, registered in PR #343. It's now in the plugin registry serving releases for Linux, macOS, and Windows — v0.1.2 adds the missing linux-x64 asset, and earlier point releases hid the stray console window on Windows. Install it from Settings → Plugins. Informix joins the growing set of community-built drivers extending Tabularis beyond the built-in MySQL, Postgres, and SQLite.

Smaller Things

• Fresh AI model lists (@debba, PR #359) — the Anthropic and MiniMax model menus are now fetched live from their APIs instead of a hardcoded list, so newly released models show up without a Tabularis update.
• Multi-database operations stay scoped (@debba, PR #346) — the ER diagram, dump, and export now act on the database you've selected on a multi-database connection instead of leaking across all loaded databases.
• Social links everywhere they're expected (@debba, PR #353) — GitHub, Discord, X, Bluesky, and Mastodon links now appear in the Settings Info tab, the update and What's New modals, and the welcome screen, pulled from a single source of truth.
• External plugin triggers forwarded (@haos666, PR #321) — plugin trigger RPCs are now forwarded through to plugin drivers, so plugins can expose trigger-style actions.
• Robust view-definition parsing (@maacl, PR #320) — the view editor extracts the SELECT body from a view definition more reliably across the shapes different engines return.
• Flatpak via Flatpark (@jing2uo, PR #341) landed in the README, alongside an updated sponsors list.

Thanks

Nine external contributors land in v0.13.3 — this release is overwhelmingly community work.

@GabrielMalava (Gabriel Malavazi Rodrigues) lands both customizable result colors with the editing improvements (#354) and session restore with the start-maximized option (#332) — two of the headline features of the release.

@Davydhh (with Davide Cazzetta) tied the editor tab bar and split panels to the active connection's color (#333).

@Wilovy09 added the Gruvbox theme (#357) and the CSV-header copy toggle (#356).

@Stiwar0098 built the MCP approval attention flow (#311) so a pending approval never goes unnoticed.

@metalgrid made the Kubernetes selection dialogs searchable and driver-aware (#319).

@danielnuld built and shipped the community IBM Informix driver plugin (#343).

@haos666 forwarded external plugin trigger RPCs (#321), and @maacl hardened view-definition parsing (#320).

@jing2uo documented Flatpak install via Flatpark (#341).

If you juggle multiple connections and want them color-coded, read grids faster when values are typed by color, theme your editor with Gruvbox, want Tabularis to reopen where you left it, or connect to Informix — this is the upgrade.

v0.13.3 is available now. Update via the in-app updater, or download from the releases page.

About three months ago I added external database drivers to Tabularis. Not dynamic libraries, not WebAssembly modules: ordinary processes that speak JSON-RPC over stdin/stdout.

Enough time has passed for the design to be less theoretical. It has survived real drivers, timeouts, a headless server mode, and one security bug that was hiding in what looked like normal registry code. So this is not a launch post. It is a short retrospective on the shape of the implementation and the places where the shape mattered.

Tabularis still has three database drivers compiled into the application: MySQL, PostgreSQL and SQLite. They use sqlx, implement the same Rust trait, and ship with the binary. This is the comfortable case.

The interesting case is the fourth database.

There are many databases I will never run myself, and a few I have not heard of yet. Compiling a client library for each of them into the core binary is not realistic. It also feels wrong: a database GUI should not have every possible vendor SDK, Python runtime, OAuth stack, TLS oddity and transitive dependency in the same address space as the rest of the application.

Still, "it does not support the database I use at work" is a valid reason to close a database GUI and never open it again. So Tabularis needed plugins.

That sounds like a solved problem until you ask what a plugin is, exactly, for a Rust desktop application. In practice I saw three choices: load a dynamic library, run WebAssembly, or start another process. The implementation that shipped chose the least clever one.

The two options I didn't take

Dynamic libraries. Load a .so, .dylib or .dll, find a symbol, call into it. This is the traditional native plugin model, and on paper it is the fastest one. A query method becomes a function call.

There are two problems with it here.

The first one is Rust. Rust does not have a stable ABI, so a plugin compiled with one toolchain cannot safely pass a String, Vec or trait object to a host compiled with another one. In practice a Rust plugin ABI becomes an extern "C" interface: raw pointers, owned buffers, explicit frees, error codes, and a driver author thinking about FFI before thinking about the database.

The second problem is more important. A dynamic library lives in the host process. If the driver segfaults, Tabularis segfaults. If it corrupts memory, the crash can surface later in unrelated code. If a panic crosses an FFI boundary incorrectly, the behavior is not something I want in user crash reports. The fastest plugin boundary is also the boundary with the worst failure mode.

WebAssembly. WASM is attractive for the opposite reason. It gives a real memory sandbox, and if the main problem was running hostile code, it would be the first thing to evaluate seriously.

But a database driver is mostly I/O. It opens sockets, negotiates TLS, speaks a binary protocol, and often wants to reuse a vendor SDK or a mature client library that already exists in some language. For this use case WASM does not just sandbox the driver; it removes a lot of the ecosystem the driver author would naturally want to use.

I am not saying WASM is a bad plugin technology. It is probably the right answer for many plugin systems. But for database drivers, the practical constraint is not CPU isolation. The practical constraint is: can somebody write a driver quickly, using the tools that already speak to that database? If the answer is no, the plugin system will be beautiful and mostly empty.

The boring option

A Tabularis plugin driver is a separate program. It reads requests on stdin, writes responses on stdout, and exits when the host is done with it.

This idea is old enough to be boring. Language servers work like this. Unix tools work like this. CGI worked like this. The reason this shape keeps coming back is that it gives a useful amount of isolation without inventing much:

• The driver can be written in any language. Rust, Python, Go, Java, a shell script if that is really what the database deserves. If it can read a line and print a line, it can be a driver.
• If the driver crashes, the host sees EOF on a pipe. That is a normal error path, not memory corruption in the GUI process.
• The driver brings its own dependencies. The CSV driver is Python. The Google Sheets driver is Rust with an OAuth dependency I do not want in the core application. Both are fine because neither one is linked into Tabularis.

The cost is serialization. Every call is encoded, written through a pipe, read on the other side, decoded, and then the response takes the same trip back.

For a database client, this is a good trade. The thing behind the driver is usually a database server over the network, or at least disk. A bit of JSON framing is not where the time goes. When it does matter, the answer is usually to page or stream the result set, not to put a third-party driver into the main process.

The wire

The protocol is JSON-RPC 2.0, one message per line. The whole definition lives in src-tauri/src/plugins/rpc.rs, and it is small enough to show:

#[derive(Serialize, Deserialize, Debug)]
pub struct JsonRpcRequest {
    pub jsonrpc: String,
    pub method: String,
    pub params: Value,
    pub id: u64,
}

#[derive(Serialize, Deserialize, Debug)]
#[serde(untagged)]
pub enum JsonRpcResponse {
    Success { jsonrpc: String, result: Value, id: u64 },
    Error   { jsonrpc: String, error: JsonRpcError, id: u64 },
}

Line-delimited JSON is intentionally unsophisticated. I could have used Content-Length framing like LSP does. Instead a Python driver can do this:

for line in sys.stdin:
    request = json.loads(line)

and be done with framing. A JSON serializer escapes newlines inside strings, so a physical newline is a message boundary. This is not the most general protocol in the world. It is the one that makes the first driver take an afternoon instead of a week.

One detail that paid for itself: the child's stderr is inherited, not piped. Driver logs and panics go to the same console as the app logs. I did not build a logging protocol because the operating system already had a useful one.

The method surface is the database trait flattened into strings: test_connection, get_databases, get_tables, execute_query, insert_record, get_create_index_sql, and so on. There are a bit more than thirty methods. The scaffolder generates stubs for all of them, so a driver author fills in behavior rather than copying protocol boilerplate.

At the boundary, params and result are serde_json::Value. Immediately above the boundary they become real types again. This is important: dynamic data at the process boundary is fine; dynamic data spread through the application would not be.

The part that is actually hard

The phrase "JSON-RPC over stdin/stdout" hides the annoying part: there are two byte streams and many callers.

When a connection opens, the sidebar may ask for schema information while the grid asks for the first page of rows and a background task pings the driver to see if the connection is still alive. Those calls are concurrent. The child process, however, has one stdin and one stdout.

So two things must be true:

• Writes must be serialized. Even if small pipe writes often appear atomic, relying on that would make the protocol depend on an implementation detail.
• Responses must be routed by id. The fast schema request can finish after the slow row request or before it. Order is not a contract.

The way to get both properties is to stop letting callers touch the pipes. One Tokio task owns the child process. Everyone else sends that task a command and waits on a one-shot channel.

The caller side looks like this:

enum PluginCommand {
    /// Dispatch a request; route the response back via the sender.
    Call(JsonRpcRequest, oneshot::Sender<Result<Value, String>>),
    /// Drop the pending entry for `id` because the caller stopped waiting.
    Cancel(u64),
}

The owner holds the only stdin, the only stdout, and the map of outstanding requests. It waits for three things: a shutdown signal, the next command from the application, or the next line from the plugin.

let mut pending: HashMap<u64, oneshot::Sender<Result<Value, String>>> = HashMap::new();

loop {
    tokio::select! {
        _ = &mut shutdown_rx => { let _ = child.kill().await; break; }

        msg = rx.recv() => match msg {
            Some(PluginCommand::Call(req, resp_tx)) => {
                pending.insert(req.id, resp_tx);          // remember who's waiting
                let mut line = serde_json::to_string(&req).unwrap();
                line.push('\n');
                stdin.write_all(line.as_bytes()).await?;  // serialized: only this task writes
            }
            Some(PluginCommand::Cancel(id)) => { pending.remove(&id); }
            None => { let _ = child.kill().await; break; } // all callers gone
        },

        line = reader.read_line(&mut buf) => match line {
            Ok(0) => break,                                // EOF: the plugin died
            Ok(_) => {
                match serde_json::from_str::<JsonRpcResponse>(&buf) {
                    Ok(JsonRpcResponse::Success { result, id, .. }) => {
                        if let Some(tx) = pending.remove(&id) { let _ = tx.send(Ok(result)); }
                    }
                    Ok(JsonRpcResponse::Error { error, id, .. }) => {
                        if let Some(tx) = pending.remove(&id) { let _ = tx.send(Err(error.message)); }
                    }
                    Err(e) => log::error!("bad response from plugin: {e}"),
                }
                buf.clear();
            }
            Err(e) => { log::error!("read error: {e}"); break; }
        },
    }
}

This is the PluginProcess management task in src-tauri/src/plugins/driver.rs. The request id is a monotonic counter. Responses can arrive in any order, because each one finds its waiting caller through pending. Writes are serialized because there is exactly one writer.

The external shape is concurrent. The internal shape is a single owner of a resource that should not be shared. That is the main trick.

A call becomes:

let (tx, rx) = oneshot::channel();
self.sender.send(PluginCommand::Call(req, tx)).await?;
match tokio::time::timeout(PLUGIN_CALL_TIMEOUT, rx).await {
    Ok(Ok(result)) => result,
    Ok(Err(_))     => Err("plugin did not respond".into()),
    Err(_)         => { /* timed out */ }
}

At this point the design looks clean. In my experience, that is a good time to look for the state the code forgot to model.

Two bugs that showed up

The actor loop was the right abstraction, but two bugs fell directly out of its shape during the first rounds of testing.

The leak. A caller waits at most 120 seconds for a reply. If the plugin is slow or wedged, the caller gives up and returns an error.

But the owner still has an entry in pending. It contains a oneshot::Sender whose receiver is gone. The entry is removed only when a response arrives, and in this case the response may never arrive. So every timeout leaks one map slot. A bad plugin can slowly grow that map for the lifetime of the application.

That is what Cancel(id) is for. When a call times out, the caller also tells the owner to forget the request:

Err(_) => {
    let _ = self.sender.send(PluginCommand::Cancel(id)).await;
    Err(format!("plugin call '{method}' timed out after {}s", timeout.as_secs()))
}

This is a small fix, but it is the kind of small fix that is easy to miss because the happy path never needs it. The actor owns the child process, so it must also own the cleanup for abandoned calls.

The zombies. Tabularis can also run headless as an MCP server. In that mode a subprocess starts, registers plugins, serves requests, and exits when its stdin reaches EOF.

The first time I tested that path, ps still showed plugin processes after the parent had gone away. The owner task was the only place that called child.kill(), but Tokio tasks are cancelled when the runtime is torn down. The task that was supposed to clean up the child could be dropped before it reached the shutdown branch.

The fix is one line at spawn time:

.kill_on_drop(true)

Dropping the child handle is enough to terminate the process. This is a better invariant than "the async task will always get a chance to run one more branch before the runtime disappears", because that invariant is not true.

The registry bug

This is the bug that changed how I think about the registry.

Registering a driver, built-in or plugin, eventually meant inserting it into a map keyed by driver id:

registry.insert(manifest.id, driver);

The built-in drivers have the ids "mysql", "postgres" and "sqlite". A plugin declares its id in manifest.json.

Nothing stopped a plugin from declaring this:

{ "id": "mysql" }

Install that plugin and the map insert shadows the built-in MySQL driver. From that point, an existing MySQL connection can be routed to the third-party process that claimed to be MySQL. Tabularis resolves the password from the OS keychain and hands it to "the MySQL driver". The attacker does not need a memory corruption bug. The attack is a manifest entry.

I caught this during the original implementation, before it shipped, but it was close enough to be uncomfortable. The fix in src-tauri/src/plugins/manager.rs is deliberately boring:

const BUILTIN_DRIVER_IDS: [&str; 3] = ["mysql", "postgres", "sqlite"];
if BUILTIN_DRIVER_IDS.contains(&config.id.as_str()) {
    return Err(format!(
        "Plugin id '{}' collides with a built-in driver and was refused",
        config.id
    ));
}

A plugin that claims a built-in id is refused at load time.

The lesson is not that this particular denylist is clever. It is that an identity namespace shared by trusted and untrusted code is a security boundary. The HashMap looked like plumbing. In practice it was deciding which process received credentials from the keychain.

That is a useful class of bug to remember: the dangerous code is not always the code that parses packets or runs SQL. Sometimes it is the code that chooses who gets to run.

About the word "sandboxed"

It is tempting to call this sandboxing. I have used that word myself, but it needs qualification.

Running a driver as a separate process gives Tabularis two things:

• Fault isolation. A crash becomes EOF on a pipe, not a corrupted heap in the GUI.
• Dependency isolation. A plugin can bring its own runtime and packages without linking them into the application.

It does not make an untrusted plugin safe. The plugin process runs as the user. It can read files the user can read, open network connections the user can open, and do the normal things any program on the machine can do. A pipe is not a jail.

Real containment against hostile code needs operating-system mechanisms: seccomp, pledge/unveil, the macOS sandbox, Windows job objects and AppContainer-style boundaries, or something equivalent. Tabularis does not have that layer yet.

So the honest trust model is the same one you already use for packages, editor extensions and database client plugins: you are trusting the plugin author. The credential-shadowing fix above solves a narrower problem. It prevents Tabularis from automatically handing credentials to a plugin just because it chose a privileged name. That is worth doing even before a stronger sandbox exists.

Installing a plugin

The registry is a JSON file in the repo on GitHub, fetched by src-tauri/src/plugins/registry.rs. Installing a plugin, in src-tauri/src/plugins/installer.rs, fetches a ZIP over HTTPS, unpacks it into a temporary directory, checks that manifest.json exists and parses, and then atomically renames the directory into place:

fs::rename(&tmp_dir, &final_dir)   // .tmp-<id>  ->  <id>, atomically
    .map_err(|e| format!("Failed to finalize plugin installation: {e}"))?;

The atomic rename matters because the loader should never see half of a plugin. Either the install finished and the directory has a valid manifest, or there is no plugin.

Three months later, this is still the weakest part of the install story: no signatures, no checksum pinning. The trust chain is "you trust the registry review, and you trust GitHub over HTTPS to deliver the ZIP". Signing is on the roadmap. Until then, it is better to describe the chain as it is than to imply more security than exists.

What held up

The part that held up is the original reason for doing this: I do not need to know about your database for Tabularis to speak to it.

Because a driver is just a process that reads a line and writes a line, the CSV driver can be Python, the Google Sheets driver can be Rust with OAuth dependencies, and a future driver can use whatever client library its database community already trusts. The Tabularis core does not need that code in its build, in its address space, or in its release cycle.

This is not a sophisticated plugin architecture. That is the point. The sophistication is in the edges: one owner for the pipes, request ids for out-of-order responses, cancellation for abandoned calls, process cleanup that survives runtime teardown, and an explicit boundary between trusted built-in ids and plugin ids.

The code is in the Tabularis repo, mostly under src-tauri/src/plugins/. If you want to read a real driver instead of the trait in the abstract, the Google Sheets plugin is the one I would start with.

Localization is invisible. Nobody opens an app and thinks "wow, great translation infrastructure." They notice the opposite: a button label cut off mid-word, a date in the wrong order, a tooltip that's still English when the rest of the menu isn't. It's unglamorous, easy-to-postpone work, and it quietly decides whether someone outside your own language ever gets past the first ten minutes with your tool.

Tabularis already ships in 8 languages: English, Italian, Spanish, Chinese, French, German, Japanese and Russian. So this isn't a "we should really do i18n someday" post. The bones are there. Under the hood it's i18next today with a folder of JSON locale files, one per language — though we're partway through moving that runtime to Lingui, and I'll explain why below because it turns out to matter for this decision. The app shows whichever language you pick in settings, and falls back to your system language by default. That part works.

What didn't work was everything around it. So we went looking for a better way to manage translations, weighed the options, and landed on Tolgee, who, as it happens, have stepped up to back the project while we do it. To be clear about where we are: this is the outcome of an evaluation, not a finished migration. We've chosen Tolgee, but the actual switch is still ahead of us, not behind us. That backing means a lot, and I'll come back to it. But a tool is only worth writing about if it earns the place on its own, so let me walk through how we got here. It wasn't a "first result on Google" pick, and the why matters more than the logo.

The problem was never the strings. It was the context.

Here's what contributing a translation looked like before. You'd clone the repo, find src/i18n/locales/, open a 1,200-line JSON file, and start editing values next to keys like editor.toolbar.runSelection and grid.contextMenu.copyAsInsert. No screenshots. No idea whether the string is a button (needs to be short) or a paragraph (can breathe). No way to tell whether "Open" is the verb on a button or the adjective in a connection-status badge.

That last one isn't a toy example. "Open" as a verb and "Open" as a status are the same four letters in English and two completely different words in German, Japanese, or Russian. A translator working from a flat JSON file gets one of them wrong, every time, because the file doesn't contain the one thing they actually need: where does this show up?

The result is the failure mode every localized app has: translations that are technically correct and obviously machine-shaped. Literal, not native. And the barrier to fixing it (clone, find the file, edit JSON, open a PR, wait for review) is high enough that the people most able to fix it, native speakers who use the app, almost never do.

We didn't want better JSON files. We wanted to delete the JSON file from the contributor's mental model entirely.

Why Tolgee, specifically

I looked hard at the usual options before settling on anything. Here's what actually made the decision.

It fits an open-source, privacy-first project. Tabularis has no account, no telemetry, and stores your secrets in your OS keychain. The whole pitch is that it's your tool, not a client for someone's backend. Bolting a closed, VC-funded SaaS onto the one project built around not doing that felt wrong on principle. Tolgee is open source and self-hostable. The values line up instead of quietly fighting each other, and if their pricing or direction ever changes, we own the exit. That's the same bet we ask our own users to trust.

Context-rich translating is the real unlock. This is the feature that closed it. With Tolgee, a translator isn't staring at keys. They see each string with the screen it belongs to: in-context editing while developing, and a translate UI that pairs every string with a screenshot of where it actually appears. "Open" stops being ambiguous the moment you can see it's a button in the connection panel. That's the difference between a translation and a literal translation, and between a contributor finishing one string and finishing a hundred.

It isn't welded to our i18n library, which matters right now. Here's the wrinkle: we're mid-migration from i18next to Lingui for the app's runtime. Lingui is ICU-MessageFormat-native, with compile-time message extraction and type-safe macros — for a codebase this size it's a cleaner, safer foundation than hand-maintained i18next JSON keys, and it stops the "is this key still used?" rot before it starts. A translation platform that was bolted to one specific library would be a liability in the middle of that move. Tolgee isn't: it manages translations as ICU messages and exports to whatever format the runtime needs — i18next JSON today, Lingui's catalogs as we cut over. So adopting it removes friction instead of adding a third thing to migrate. And because Lingui is ICU-native, it's a tighter fit with how Tolgee stores strings internally than i18next ever was — the format round-trip that would otherwise worry me mostly disappears. Our 8 existing languages move over as-is. That's a big part of why the evaluation pointed here: going from 8 to "a lot more" turns into a throughput problem instead of an engineering one.

Machine translation as a first draft, not a crutch. Tolgee can pre-fill a new language with machine translation and translation-memory suggestions, which means a human contributor starts from 80% instead of a blank file. They review and correct, which is fast, instead of typing from scratch, which is slow. English stays the source of truth; everything else is a draft until a human who speaks the language signs off.

What this is not

In the interest of being honest the way we try to be about everything else: this doesn't make Tabularis magically fluent in 30 languages overnight, and machine translation is not "done." English remains the canonical source. New strings still start in English in the codebase, and a locale is only as good as the humans who've reviewed it. What changes is that reviewing becomes something a native speaker can do in an afternoon from a web browser, instead of a chore that requires Git, a JSON editor, and a tolerance for ambiguity.

We'd rather ship 12 languages that real speakers have actually looked at than claim 40 that a model guessed.

The part we're really here for: community translations

There's one more reason Tolgee won, and it's the one I'm most excited about: community translations are on Tolgee's public roadmap, tracked in issue #1360. We're not building that ourselves. We don't need to, and frankly we couldn't do it better than a team that does localization for a living. We just want to flip it on the moment it lands.

Go read the issue. It describes almost exactly the workflow we want: public projects, where community members can propose translations, project maintainers review and merge them, and a dedicated "translate one string, with a big screenshot of where it lives" UI. That's the whole game. Contributors get context and a low-stakes way to help; maintainers keep a quality gate; nobody touches Git.

The idea is simple to state and has always been annoying to deliver: anyone should be able to help translate the app, and improving a translation in your own language should take minutes, not a pull request. A community-translation workflow on top of the platform we've chosen gets us there without us reinventing the wheel.

Here's how we see it rolling out:

• First, from the web. A hosted project where you pick your language, see what's translated and what's missing, and propose fixes in context, with no clone, no JSON, no Git. Maintainers review and merge. That's the workflow #1360 describes, and it's the part that's coming first.
• Delivered over the air. This is the detail that makes it click. With Tolgee's Content Delivery, an approved translation can reach you without waiting for the next app release. Tabularis still ships every language bundled inside the app. That's your offline, no-network fallback, and it always works. But when you're online, improvements can land on top. No account, no API key in the build. Your French gets better on a Tuesday; you don't wait for v0.14.
• Eventually, right inside the app. The long-run goal: you spot an awkward label while you're actually using Tabularis, fix it on the spot, and send it upstream. Community translation without ever leaving the app. We're honest that we're not there yet; doing it properly while staying offline-first and account-free is the hard part. But that's the direction, and it's why we chose Tolgee over patching JSON forever.

If you've ever wanted to see a tool you use every day speak your language properly, and been put off by the "submit a PR editing this JSON file" barrier, that barrier is on its way out. Your language is going to need you.

Thanks

Which brings me back to the part I said I'd return to: Tolgee is backing Tabularis. Not as a logo on a sponsors page, but as real support for an independent, open-source project that's still funded out of pocket. It's the kind of backing that lets us do localization properly instead of squeezing it between bug fixes. It's one thing to build good developer tooling; it's another to put your weight behind the people building open software with it. We don't take that for granted, and the fact that they're open source themselves is exactly why it feels like a fit rather than a transaction. If you're shipping a multi-language app and still wrangling JSON by hand, go look at what they've built. It's genuinely good.

Localization will always be invisible when it's done right. The least we can do is make it easy for the people who'd notice, and that's exactly what moving to Tolgee is for.

Want Tabularis in your language? Download it, switch the language in settings, and tell us what reads wrong. Issues and PRs are welcome today, and community translations are coming. Star us on GitHub to follow along, and keep an eye on the blog. When Tolgee's community-translation feature lands, your language is going to need you.

A short while after DigitalOcean welcomed us into their Open Source Credits Program, we got another email we weren't expecting: Tabularis has been accepted into the Vercel Open Source Program, in the Spring 2026 cohort.

We'll be honest about our bias here: we're genuinely fans of Vercel. We've followed the platform and its products for years, and a fair amount of how we think about shipping the web — fast previews, sane defaults, treating the deploy as part of the developer experience rather than an afterthought — has Vercel's fingerprints on it. So being picked is not a polite "thanks for applying." It's getting a nod from a team whose work we already admired. We're genuinely honored.

The terms are refreshingly simple. Stay fully open source, deploy on Vercel, keep a badge in the README for twelve months. That's it. No equity, no roadmap strings, no quarterly check-in deck. For a project that's still run on nights and weekends, an email that says "we like what you're doing, here's a year of support, carry on" is a rare kind of thing.

The part that makes this one different

The DigitalOcean credits go toward infrastructure for the plugin registry — backend, the stuff users never see directly. The Vercel support lands somewhere more visible, and frankly more fun to talk about.

This site is the thing being supported. tabularis.dev — the page you're reading this on, the wiki, the changelog, the plugin pages — is a Next.js app, it's open source, and it's the front door to everything else we build. The download links, the docs people land on from a Google search, the release notes that go out every couple of weeks: all of it runs through here.

So this isn't "a sponsor pays for our servers" in the abstract. It's the tooling we use to talk to you, getting a real upgrade. There's something fitting about an open-source database client having an open-source website, both supported by the same kind of program. The whole stack, all the way down, is something you can read, fork, and send a PR to.

What we're actually going to do with it

We're not going to pretend a year of Vercel turns the site into something it isn't. But there's a backlog of things that have been "later" for too long, and "later" just became "now":

• Faster previews on every content change. Most of what we ship here is Markdown — blog posts, wiki pages, comparison pages. Preview deployments mean we can see a post rendered, OG card and all, before it goes live. Fewer typos shipped to production.
• A site that keeps up with the app. Tabularis ships roughly every two weeks. The site has to keep pace — new features documented, the changelog current, the plugin pages accurate. Better build and deploy tooling makes that less of a chore and more of a habit.
• The boring-but-important stuff. Performance, the search index, the things that make the docs actually findable. None of it is glamorous. All of it is what makes a project feel maintained rather than abandoned.

If you've got an idea for what the site should do better, the repo is right there. Issues and PRs are open.

Thanks, and the usual honest note

To Amy and the team running the Vercel Open Source Program: thank you. Picking a young project out of a stack of strong applications is a vote of confidence, and we don't take it as a given.

To everyone who's starred the repo, filed a bug, shipped a plugin, translated a string, or just told a colleague about Tabularis: this is the kind of thing that happens because a project looks alive, and a project looks alive because of you. Two sponsorships in two months isn't luck. It's the curve you've all been bending upward.

We'll be sharing this across our channels over the next few days. If you want to help it travel, that's the best thank-you we could ask for.

The road ahead is the longest part. We're glad you're on it with us.

The Tabularis Team

v0.13.2 follows v0.13.1, which was a correctness pass. This one is about the surfaces you actually live in — the notebook, the results panel, the grid, the editor — and making them feel responsive and managed rather than write-once. Notebooks stop being files you save into the dark and become a browsable, undoable workspace; the results panel stops waiting for a whole batch to finish before telling you anything; and the grid stops stuttering when the table is wide.

Five external contributors land in this tag.

Notebooks You Can Actually Manage

SQL Notebooks shipped as a powerful surface, but they were write-only: you created one, ran cells, exported it, and then it disappeared onto disk as a flat file with no way back in from the app. v0.13.2 turns them into a first-class, per-connection workspace in PR #304.

Notebooks are now stored per connection at notebooks/<connectionId>/<id>, with lazy migration of any legacy flat notebooks the first time their connection loads — nothing you saved before is lost. A new Notebooks section in the sidebar lists the active connection's notebooks with search, one-click open, and a context menu to rename, export, import, delete (with confirmation), and Save as HTML. The list refreshes live: create a notebook and it appears immediately; a rename or delete elsewhere reflects without a manual reload. You can also rename a notebook straight from its editor tab by double-clicking the title.

Editing a notebook is now undoable. Each structural change — adding, removing, reordering, or editing cells — is captured into a timeline, and a history panel lets you scrub back through every state and jump to any point, with each entry labeled by what changed. It's the same instinct as undo in the SQL editor, applied to the whole document.

If you've been treating notebooks as throwaway scratchpads because there was no way to find them again, this is the release that makes them worth keeping.

Query Progress, In Real Time

Run a multi-statement batch and, until now, the results panel sat blank until the entire batch finished — then every result tab and the timing badge appeared at once. For a script where statement 3 of 12 is slow, that's a long stretch of staring at nothing.

@fzlee rebuilt this in PR #296. Each result tab now resolves progressively as its statement completes, matched by entry id so rapid back-to-back completions never overwrite each other. The summary badge updates live — succeeded and failed counts accumulate while a spinning count shows how many statements are still running — and the elapsed time ticks up on a live wall-clock timer instead of only appearing at the end. When the batch finishes, the ticking estimate snaps to the precise server-measured total. Under the hood, all three SQL drivers gained progressive result reporting and the editor context grew an updateResultEntry that reads the latest state rather than a stale snapshot.

You now watch a long script work through itself, statement by statement, instead of waiting blind for the whole thing.

A Grid That Scrolls on Wide Tables

Scrolling a table with a few hundred rows and 30–40 columns was visibly laggy. The whole <tbody> re-rendered on every scroll tick — no row or cell memoization — and each row was dynamically re-measured as it went.

PR #287 fixes the render path. The per-row render is extracted into a React.memo MemoRow, with the stable per-grid dependencies bundled into a single memoized context object so the default shallow compare only re-renders the rows that actually changed; volatile per-row values are passed as primitives. The cell double-click, edit-commit, and keydown handlers are stabilized with useCallback (reading the live editing cell through a ref) so the memo holds, the cell value is formatted once per cell instead of twice, and rows use a fixed height with no per-row measurement — the same proven fixed-size pattern already used by the mini result grid. The default cell renderer moved to a dataGridCell helper with unit tests.

The result: scrolling stays fluid on wide, tall tables instead of dropping frames on every tick.

Autocomplete That Reads Your Clauses

Two long-standing autocomplete gaps close in PR #295, contributed by @thomaswasle (Thomas Müller-Wasle).

First, clause keywords. Once you had a FROM clause, typing past it stopped offering WHERE, ORDER BY, GROUP BY, LIMIT and friends — a guard suppressed keyword suggestions whenever column suggestions were present. Now keyword and column completions are offered together when a FROM clause is in scope.

Second, columns across databases. The table parser was mistaking SQL keywords like WHERE, ON, and HAVING for table aliases, which corrupted the alias map and blocked column lookups. The fix replaces the keyword denylist with proper clause-boundary extraction: it isolates the FROM/JOIN section, strips ON/USING conditions, and captures schema.table qualified notation, so no clause keyword can ever land in the alias capture group. In multi-database mode each table is tagged with its source database, so a db.table. dotted completion resolves by exact (schema, name) pair and unqualified names fall back across every loaded database — MySQL multi-DB connections finally pass the right schema instead of falling back to information_schema. Empty column results are no longer cached, so a transient miss from a not-yet-ready connection can't poison later lookups.

Visual EXPLAIN Gets Honest Numbers

Two fixes make the Visual EXPLAIN table view tell the truth about row counts and timing.

PR #302 (closes #298) adds an Actual Rows column next to Est. Rows. The MariaDB ANALYZE FORMAT=JSON parser already captured actual rows from r_rows, but the table view only ever exposed the estimate; the column now renders whenever analyze data is present, on both MariaDB ANALYZE and Postgres EXPLAIN ANALYZE.

PR #303 (fixes #300) corrects MySQL EXPLAIN ANALYZE timing. MySQL's tree-format output reports time=first..last as the per-loop timing averaged across all iterations, and the table view displayed that per-loop figure directly — so a node executed many times (an index lookup driven by a join, say) reported a tiny per-iteration cost instead of its real total. The parser now scales the per-loop end time by the loop count, so the displayed time is the node's total wall-clock cost, matching how PostgreSQL's Actual Total Time relates to Actual Loops.

SSL for Plugin Drivers

The SSL/TLS tab in the connection modal was hardcoded to the mysql and postgres driver IDs, so plugin drivers — ClickHouse, for instance — could never expose SSL configuration at all.

@Aditeya (Adi) fixes this in PR #309 by adding a supports_ssl capability to DriverCapabilities on both the Rust and TypeScript sides. The SSL tab is now gated on that capability instead of a driver-ID allow-list: built-in Postgres and MySQL set the flag, and plugins opt in through their manifest. The tab description is now driver-agnostic, and ClickHouse ssl_mode options (disable/require) are wired in. Plugin authors get a documented, first-class way to surface TLS configuration.

Redis (Go) Plugin: v0.4.1

@gzamboni (Giovani Zamboni) shipped v0.4.1 of the community Redis (Go) plugin, registered in PR #314. The release fixes connecting to a Redis instance that has no username, and the registry now serves 0.4.1 across Linux, macOS, and Windows. The plugin continues to offer virtual table views for Strings, Hashes, Lists, Sets, and ZSets with native write operations. Install it from Settings → Plugins.

Smaller Things

• Scroll-bar buttons stay reachable (@VincentZhangy, PR #315) — the Refresh and Add Table buttons were hard to click once scroll bars appeared in the panel; the layout now keeps them selectable.
• README, restructured (PR #318) — the GitHub landing page got a clearer hero, a fixed .rpm download link, a "Why Tabularis?" comparison table, and reference material (configuration, AI providers, MCP setup) moved to the wiki. All seven translated READMEs were realigned and their stale download links refreshed.
• Grid cleanup — a dead cell renderer and the unused isRawSql plumbing were removed, and the demo seeds gained a 50-column × 50k-row perf_demo wide table (MySQL + Postgres) so the scroll-performance work stays reproducible.

Thanks

Five external contributors land in v0.13.2.

@fzlee brings the real-time query progress rework (#296) — the change that makes a long multi-statement batch report itself live instead of finishing in one silent jump.

@thomaswasle (Thomas Müller-Wasle) lands the autocomplete overhaul (#295): clause keywords offered alongside columns, and column resolution that finally works across databases instead of corrupting the alias map on a stray keyword.

@Aditeya (Adi) adds the supports_ssl capability (#309), giving plugin drivers a first-class path to TLS configuration that the SSL tab respects.

@gzamboni (Giovani Zamboni) shipped Redis (Go) plugin v0.4.1 (#314), fixing usernameless Redis connections.

@VincentZhangy is new to the contributor list with the scroll-bar button fix (#315). Welcome.

If you keep notebooks and could never find them again, run long scripts and want to see them progress, scroll wide tables and feel the lag, lean on autocomplete across multiple databases, or read Visual EXPLAIN and want the numbers to be honest — this is the upgrade.

v0.13.2 is available now. Update via the in-app updater, or download from the releases page.

We gave Fable 5 a single day after it dropped and accidentally shipped a video game.

It's called Tabularis Run — a tiny Super Mario-style platformer that runs in your browser, themed entirely around Tabularis. No download, no account, no catch. It's free, it's open source, and the whole point is to have a bit of fun — and maybe put Tabularis in front of a few people who'd never have clicked on a database client otherwise.

👉 Play it right now → game.tabularis.dev

How it plays

Run, jump, climb network cables and fire SQL "queries" across three worlds — SQLite, MySQL and PostgreSQL — each one ending in a boss fight against that database's mascot: a hummingbird, a dolphin, and an elephant.

• 12 levels, including a vertical WAL ascent climb
• 27 hidden plugins to collect, plus power-ups — an MCP gun, an Index shield, a Vertical Scaling RAM stick
• SQL flavor everywhere: COMMIT; is the flag at the end of a level, ROLLBACK is what happens when you die, BEGIN; marks your checkpoints
• 4 playable characters: TAB, PRIMARY KEY, CURSOR and TRIGGER
• Plays on desktop (keyboard or gamepad) and mobile (touch controls)

Every pixel is procedural — the sprite art is drawn from character grids, the music is WebAudio chiptune, there are zero external assets and zero runtime dependencies. It's just vanilla JavaScript and a <canvas>. Beat it and you can share a generated score card straight to your socials.

Full disclosure: we're not game developers

Let's be honest about how this got made, because it matters.

We're not game designers. We're not really game developers either. A good chunk of Tabularis Run is straight-up vibe-coded — we described what we wanted, Fable 5 wrote a lot of it, and we steered. The physics are tuned by feel, the level design is whatever felt fun at 1am, and an actual professional would probably wince at some of the choices.

And that's kind of the point. It's the same thing we keep writing about on this blog — we handed Fable 5 a real task on the Tabularis codebase and it opened an 1,800-line PR in 30 minutes. A whole game in a day is just the playful version of the same shift: the gap between "we have an idea" and "it's live on the internet" is collapsing.

Want to build a world?

Here's where you come in.

The game is fully open source, and we'd genuinely love for people who know what they're doing to jump in. Tweak the physics, fix our questionable level design, add enemies, or — the fun one — let's design entirely new worlds together. The engine already supports three; there's no reason it has to stop there. New database mascots, new mechanics, new bosses: it's all on the table.

👉 Game source on GitHub → github.com/TabularisDB/game

The codebase is small and approachable on purpose: levels are authored in a little grid DSL, sprites are character grids, and there's a test suite that validates every level is actually beatable. PRs are very welcome, and if you want to riff on an idea first, the Discord is the place.

Why a game, though?

Because Tabularis grows when people hear about it — and a game travels in places a database client never will. Someone shares a high score, a friend asks "wait, what's Tabularis?", and the curve nudges upward.

So if you enjoy it, the single best thing you can do is share it — a clip, a screenshot, your best run. Have fun with it. That's the whole brief.

And if you came here for the actual database client: Tabularis is a free, open-source database client for the AI era — one fast, native app for SQLite, MySQL, PostgreSQL and many more. The game is just a love letter to it.

The Tabularis Team

Daily Dev Experiment — a short series where we hand a real task to an AI on the Tabularis codebase and report exactly what happened. No staged demos. Today's run got a little out of hand.

We asked Fable 5 (Anthropic's new model) to add a command-line interface to the app. That's less trivial than it sounds: this is a Tauri app — Rust backend, React frontend — so "a CLI" means reaching every saved connection (keychain passwords, SSH/K8s tunnels, plugin drivers) without booting the GUI or starting the Tauri runtime at all.

One prompt. A coffee break. A draft PR waiting at the end of it.

Here's what was in it.

The numbers

We've spent longer naming a variable.

What we expected

A coherent set of clap subcommands, addressed by connection id or name:

The detail we like most: query picks its mode from the invocation. SQL argument → one-shot. Piped stdin → executes the piped statement. Interactive TTY with no SQL → drops into a proper SQL shell.

# one-shot query, pipe-friendly
tabularis query my-db "select id, name from customers" --format csv > out.csv

# pipe a statement in
echo "select count(*) from orders" | tabularis q my-db

# no SQL on a TTY → drop into a proper SQL shell
tabularis query my-db

The interactive shell is backed by rustyline: line editing, persistent history (cli_history.txt in the app config dir), multi-line statements that fire on a terminating ;, Ctrl-C drops the current buffer, Ctrl-D exits. Plus psql-style meta commands:

\l    list databases        \f table|json|csv   output format
\dn   list schemas          \limit N            row limit (0 = unlimited)
\dt   list tables           \schema NAME        set schema
\d T  describe table        \use DB             switch database
\q    quit                  \?                  help

Result data goes to stdout, logs go to stderr — so piping stays clean, and you get a non-zero exit code on failure. Exactly the kind of detail a human means to remember and usually forgets.

It even kept the GUI-launch fallback intact: macOS still passes junk like -psn_* to the binary on launch, and that must keep booting the GUI — while a misspelled subcommand should surface clap's error instead of silently opening a window. It threaded that needle, and wrote tests asserting the exact clap error kinds that fall through to the GUI versus the ones that don't.

What we did NOT expect

1. It found the refactor before writing a single feature.

The app already ships an MCP server, and that server already knew how to resolve a saved connection — decrypt the keychain password, open the SSH/K8s tunnel, register the right plugin driver. Instead of duplicating all of that for the CLI, Fable 5 dug through the codebase, realized the logic was buried inside mcp/mod.rs, and pulled it out into a shared headless.rs module that both the MCP server and the new CLI consume. The MCP server now just wraps the shared helpers with its JSON-RPC error type — zero behavior change on that side.

That's 242 lines deleted from mcp/mod.rs and a 214-line module born. It's the refactor we would have done — unprompted, because it understood why duplicating connection resolution was the wrong move.

It also didn't dump everything into one file. The old 52-line cli.rs became a real module:

src-tauri/src/cli/
├── mod.rs       clap definitions, GUI-fallback logic     (182 lines)
├── run.rs       command dispatch + execution             (338 lines)
├── repl.rs      the interactive shell                    (282 lines)
├── output.rs    table / JSON / CSV rendering             (138 lines)
├── install.rs   install-cli symlink logic                 (97 lines)
└── *_tests.rs   args, output, run, install               (442 lines)

2. It fixed two real bugs that were already there.

• keychain_utils was logging with println!, dumping straight to stdout. Harmless in a GUI — silently corrupting any piped CSV/JSON the moment a CLI exists. And it was bypassing the in-app log buffer too. It rerouted everything through the log crate.
• Headless processes never called sqlx::any::install_default_drivers(), so the default connection-test path panicked. It installed the drivers in the shared headless::register_drivers() — which also quietly fixed the existing --mcp mode.

Neither was in the prompt. It found them because it actually traced the execution path from "user pipes a query" to "bytes hit the terminal" and noticed what would break along the way.

3. It handled multi-database connections properly.

Multi-db connections used to resolve to their first database, which made the others unreachable outside the GUI. Every db-scoped command now takes -d/--database, and the shell's \use <db> doesn't just flip a variable — it validates the switch with a connection test before applying it, and the prompt shows where you are (Demo · MySQL:blog_demo>). Under the hood it reuses the GUI's per-call database-override semantics (DatabaseSelection::Single) instead of inventing a parallel mechanism.

4. It tested its own work against a live database.

The 37 unit tests aren't padding: clap parsing (including the GUI-fallback error kinds), table/CSV/JSON rendering (column alignment, control-character escaping, CSV quoting), limit and database-override semantics, and the install-cli symlink logic — idempotency, refusal to clobber a foreign file, --force.

Then it went further: it ran the new shell against a real MySQL connection, switched across the three demo databases with \use, eyeballed the table/CSV/JSON output, and fixed the formatting it didn't like — before handing over the PR.

So... do we trust it?

No. It's a draft PR and we're reviewing every line before anything ships. There are real limitations — which, to its credit, it flagged itself in the PR description:

• On Windows release builds the binary has no attached console (windows_subsystem = "windows"), so CLI output is invisible there. Same constraint the --mcp mode always had.
• Each shell statement runs on its own pooled connection, so session state — SET, transactions, temp tables — doesn't persist between statements. It even documents that caveat inside \?.

But here's the part that stuck with us: the review is genuinely worth doing. This isn't autocomplete spitting out a function body. It's an agent that read the architecture, found the seam we'd have found, refactored toward it, and cleaned up two messes on the way out — then wrote 37 tests and a PR description more thorough than most humans bother with.

Two years ago this was Tab-complete. Today it's a coworker whose work we have to code-review.

👉 Read the full PR — every line, the real description: #313

Where this is going

This experiment isn't a side quest — it's the direction. We're building a database client that's native to this new workflow: a built-in MCP server so agents like the one in this post can work against your databases, with approval gates, a read-only mode, and a full audit log so they do it on your terms. An AI assistant that also runs on open-source models — locally via Ollama, with zero schema data leaving your machine. And now a CLI, born from that same headless core.

An agent wrote today's feature. The point is that tomorrow, your agents get a first-class, safe way to use it.