![\"Plugin](\"https://tabularis.dev/img/posts/tabularis-bounty-board-before.png\")
\n ![\"Plugin](\"https://tabularis.dev/img/posts/tabularis-bounty-board-after.png\")
\nTabularis.dev did its job well. It was built by developers whose expertise is databases and desktop software, not frontend, and AI helped them build a solid site quickly. It presented the project clearly and helped it reach a growing community.
\nBut a project doesn't stand still. As Tabularis grew, with more features, more plugins, more docs and more new visitors, the site had more to say than its original structure could hold. The goal of the rebuild wasn't to fix something broken, but to give the site room to grow with the project.
\nHere is how the rebuild went, and what each step taught me.
\nBefore opening any design tool, I reviewed the site page by page: what was there, what each page was trying to say, and where a first-time visitor would probably get lost or leave.
\nThree things stood out. The navigation and the page hierarchy were not obvious to someone arriving for the first time. Some content was dense where it should have been easy to scan. And the homepage, the page that matters most for convincing someone to stay, described the project without really explaining why it was worth trying.
\nHere is what the top of the homepage looked like before the rebuild:
\n![\"Homepage](\"https://tabularis.dev/img/posts/tabularis-homepage-hero-before.png\")
\n\nThe homepage hero before the rebuild.
\nI also looked at how well-known developer tool sites handle the same problem: Stripe, Vercel and Linear. The goal was not to copy their look, but to learn from two things. First, their navigation stays simple as the product grows, with a few clear entries instead of links to everything. Second, their design is consistent: the same spacing, the same type sizes and the same few colors on every page. This meant I didn't have to guess what "clean" looks like. I could reuse rules that already work.
\nNext, I moved to Figma. There were no formal rounds of review, just a continuous process: sketch a direction, test it with the real content, adjust, and move on to the next page.
\nDeciding the structure of a page in Figma is much cheaper than changing it later in code. It also gave everyone something concrete to react to before any development started.
\nFor each page, I asked whether every section was really useful, instead of keeping it just because it was already there.
\nThe homepage features section was the clearest example. It had 14 feature cards, all with the same visual weight. I kept the 4 that matter most for a first visit, and moved the full list to the solutions page, which is linked from the homepage. Fourteen cards of equal importance don't help a new visitor understand a project, they only delay the moment they decide whether it's worth their time.
\nTwo other sections were removed: one about the app's visual themes, and one introducing the wiki. Both have their place on the site, but not on a homepage whose job is to convince first-time visitors.
\nThe other pages went through the same review, including the download page, the compare pages and the plugin bounty board. The question was always the same: does this help the reader make a decision, or is it here only because it was easy to add?
\nThe bounty board is a good example. Its header used to show a complex driver map with thirteen targets, four status colors, a legend for those colors, and three buttons, all before the visitor had finished reading the title. The new version has the same goal, showing which databases still need a driver, but it uses six database logos around the Tabularis logo and two buttons instead of three. The information is the same, and it's much easier to read.
\n\n \nThe bounty board header, before (left) and after (right).
\nRemoving what wasn't needed was only half of the work. The other half came from the lesson of Stripe, Vercel and Linear: a site looks clean when the same few rules are used everywhere.
\nTabularis didn't have those rules yet. There was only one logo file, also used as the favicon, and the whole site used a monospace font, even for body text. Each page also had its own style, with different spacing, different cards and different uses of color. Going from one page to another felt like visiting different products.
\nNow the whole site shares one visual language. It uses two fonts, each with a clear role: Urbanist for the interface and for reading, and JetBrains Mono only for code and data. It has one color palette, and the same spacing and components on every page. The logo and the icon now exist in color, white and black, so they work on any background. The brand kit makes all of this available to anyone who writes about Tabularis or builds something around it.
\nTwo parts of the rebuild took much longer than the rest.
\nThe first was the download page. It looks like the simplest page on the site, since you just pick your platform and get the file, which is exactly why it has to be perfect. Every extra click or unclear option can make someone leave before downloading, so I spent more time on it than its size suggests.
\nThe second was the content pages: blog posts and solution pages. Their content is written in Markdown rather than placed in a fixed layout, so every type of content needed its own design and testing: all heading levels, code blocks, videos and images. A content page is not one component but a small set of components that must look good together, whatever combination an article uses. That made it much harder to finish than a page with a fixed layout.
\nA new design on top of the old code would only have moved the problem. So once the design direction was clear, I reviewed the code the same way I had reviewed the pages.
\nSome parts were in good shape. The routing was well organized, and SEO and Open Graph images were already handled well, better than in most projects of this size.
\nOther parts were not. All the styles of the site were in a single globals.css file, with about 11,200 lines of code, or 13,000 lines including comments and blank lines. With a file like this, there was no reliable way to know whether a rule was still used. Changing a class was risky, because it might also affect three other pages. Class names conflicted between unrelated components, and the file was too large to work with confidently. The components had the same problem: all 65 of them were in a single folder, with no organization by feature.
\nThe rebuild moved all the styles to CSS Modules, page by page during the redesign, and component by component for shared pieces. Each component now has its own style file next to it, with styles that only apply to that component: about 100 small files instead of one huge one. The components follow the same logic, with shared layout and UI components on one side, and one folder for each part of the site on the other, such as the homepage, the blog, the wiki and the download page.
\nThe global stylesheet is still there, but it went from 13,000 lines to about 300. It now only contains what really needs to be global: shared variables and basic layout classes. Changing the style of one component no longer means checking the entire site.
\nYou don't have to take my word for it: the site is open source, and you can explore its structure in the website repository.
\nThe rebuild took several weeks, alongside other work. Here is how the code changed:
\n| \n | Before | \nAfter | \nChange | \n
|---|---|---|---|
| Files | \n145 | \n288 | \n+99% | \n
| Lines of code | \n28,533 | \n21,453 | \n-25% | \n
| Total lines | \n32,295 | \n24,338 | \n-25% | \n
Almost twice as many files, and a quarter less code. That's not a contradiction, it's the goal: each file now has one clear job, and the code has a logical place instead of piling up in whichever file was already open. There is simply less code to read, review and maintain.
\nThe change is not only in the code. The homepage now explains the project in the few seconds a new visitor gives it, and the next person who works on the site will find code that is easy to change. The best way to judge is to explore the site, starting with the download page or a few demos.
\nIf your project is growing and its site "just works", the real question is not whether it looks fine today. It's whether it will still hold up when more people look at it closely, when traffic grows, and after six more months of changes that nobody has planned yet.
\nThanks to Debba for the trust and the freedom to rethink everything.
\nWhat still feels rough when you visit tabularis.dev? Tell us on GitHub Discussions or Discord.
\n", "image": "https://tabularis.dev/blog/tabularis-dev-rebuild-story/opengraph-image.png", "date_published": "2026-10-05T14:00:00", "tags": [ "ux", "ui", "design", "ai", "open-source", "website" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0260-postgres-tab-transactions-command-palette-accessible-themes", "url": "https://tabularis.dev/blog/v0260-postgres-tab-transactions-command-palette-accessible-themes", "title": "v0.26.0: Transactions That Span Runs, a Command Palette That Acts, and Themes That Reach Every Pixel", "summary": "v0.26.0 keeps a PostgreSQL transaction open across runs of the same tab, turns the command palette into an action surface, routes every UI color through the theme with WCAG AA checks in CI, and cancels timed-out plugin queries on the server.", "content_html": "v0.26.0 follows v0.25.0. Where that release built the theme system and the plumbing around connections, this one is about the editor session and the surface you drive it from. A PostgreSQL editor tab now behaves like a session: a transaction you open in one run is still open in the next, and a TX badge says so. The command palette grows from navigation into an action surface for the editor, the result grid and saved connections, and the shortcut editor learns to detect conflicts and work on any keyboard layout. The theme engine from v0.25.0 finally reaches the whole UI, and a new CI workflow keeps it there with contrast and accessibility checks. Driver plugins can own the SQL that Generate SQL produces, and a plugin query that runs past its timeout, now a setting, is cancelled on the server instead of left running. The grid remembers where you scrolled. Around the release, the registry gained a Cassandra and ScyllaDB plugin, an Oracle plugin and its first theme package, Ember, and the PostgreSQL and SQL Server plugins moved to new pre-releases. The rest is a set of community fixes, most of them for things that only break on someone else's machine.
\nPR #801 by @egertaia fixes the workflow a transaction exists for. A batch already ran its statements on one pooled connection, so BEGIN … COMMIT inside a single script worked. Splitting it did not:
-- Run 1\nBEGIN;\nUPDATE accounts SET balance = 0 WHERE id = 42;\n\n-- Run 2: check before committing\nSELECT balance FROM accounts WHERE id = 42;\n\n-- Run 3\nCOMMIT;\nBetween runs the connection went back to the pool, so run 2 could land on a different connection and show pre-transaction data, and run 3 could report there is no transaction in progress while the real transaction stayed open somewhere else. Worse, the pool did not reset connections on return, so the stranded connection, still holding its locks, could be handed to an unrelated query that then ran inside someone else's transaction.
An editor tab is now a session. When a run leaves an explicit transaction open, the tab's connection is pinned to it instead of returning to the pool, and the next run from the same tab continues the same transaction. The tab shows a TX badge while that is the case, with the hint "Transaction open — this tab keeps its connection until you COMMIT or ROLLBACK", because its uncommitted changes are invisible to every other tab. COMMIT, ROLLBACK, closing the tab or 30 minutes of inactivity release it. A pinned connection is never handed back to the pool without a ROLLBACK first.
Pinning is lazy: a tab that never opens a transaction holds nothing, so ten idle tabs still cost no connections. Transaction control is recognized from a statement's leading keywords only (BEGIN, START TRANSACTION, COMMIT, END, ROLLBACK, ABORT, PREPARE TRANSACTION, and ... AND CHAIN, which ends one transaction and opens the next), so a BEGIN inside a string literal or a PL/pgSQL body is not mistaken for one, and ROLLBACK TO SAVEPOINT leaves the transaction open. A failed ordinary statement leaves the session pinned, since PostgreSQL keeps the aborted transaction open until you roll it back from the same tab; a failed COMMIT releases it, since PostgreSQL has already rolled back. Paging through a result, counting rows, exporting and Copy all rows go through the tab's session too, so they see the tab's own uncommitted changes. Closing a tab releases its connection only after the unsaved-file prompt, so cancelling that prompt cannot discard a live transaction, and every close path, a disconnect and the app exit release pinned sessions.
This works on the built-in PostgreSQL driver and on the PostgreSQL plugin from 1.0.0-rc.5, where the companion change landed in plugin PR #124, carried by @aesslinger on top of @egertaia's original work. The wire format is backward compatible in both directions: an older plugin keeps the old per-run behaviour, and an older host never sends a session id. Other drivers are unchanged. One behaviour change is worth flagging: a batch that leaves a transaction open with no session to pin it to, such as a non-editor caller, is now rolled back rather than returned to the pool as it was.
\n@verbaux turns the command palette from a navigation box into an action surface in PR #815. Actions and database objects are now searched together from one input, opened with the new Command Palette shortcut, ⌘+K / Ctrl+K; ⌘+P and ⌘+Shift+A still open it scoped to objects or to actions. What it offers depends on where you are:
IN (...) list, or copy all rows. This works in tabbed and stacked result views, includes pending inserted rows, and the label states the same row count the command will copy.Root commands such as Open settings and Open connection manager stay available while the editor is loading or showing its error boundary, so the palette is a way out of a broken state rather than part of it.
\nThe same contributor reworked shortcut handling in PR #773. Settings → Keyboard Shortcuts opens a dedicated editor for each binding that records the combination, refuses one without a modifier ("Add a modifier key, such as Ctrl or Alt."), and names the shortcut it would collide with ("This shortcut conflicts with “Toggle sidebar”.") instead of silently overriding it. Shortcuts now track the physical key as well as the character, so switching connections with Ctrl+Shift+1–9, the palette shortcut and your own overrides keep working on AZERTY, QWERTZ and other layouts; an override matches either the key or its position, so on some layouts one shortcut has two triggers, which is intended. Open settings (⌘+, / Ctrl+,) is a new, remappable shortcut, notebook shortcuts appear in their own category, and closing Settings returns to where you came from.
v0.25.0 made themes installable packages. It also exposed how little of the UI honoured them. The engine defines 38 color tokens, two font stacks and four radii, but with the default themes nobody could tell that a large part of the interface ignored them, because the hardcoded Tailwind blue, red and green happened to match. Under Ember's amber accents, a square-cornered theme or any light theme, the app split into two palettes.
\nPR #809 routes everything through the tokens. Status banners take their colors from the theme's accents instead of a fixed :root. Rounded corners follow layout.borderRadius, so square-corner themes, the built-in High Contrast included, are square everywhere. The grid paints modified, new and deleted rows and primary-key, foreign-key and index icons with the semantic.* tokens every theme already defined and nothing used. The ER diagram, the visual query builder, notebook charts, the drag ghost and the editor tab accent read the theme instead of hex literals. Native select popups are no longer forced dark, and the startup flash uses the saved theme's background. A codemod replaced 1,305 palette classes in 153 files by meaning, and labels on success, warning and error fills now pick black or white from the fill's lightness. The System font setting, which used to override every theme's font, follows the theme and is now labelled Theme default.
PR #812 adds a Design & Accessibility workflow with three blocking checks, and fixes everything they found on the way in:
\n| Check | \nWhat it verifies | \nFindings fixed | \n
|---|---|---|
| Theme tokens | \nNo hardcoded colors, radii or fonts | \nalready passing | \n
| Theme contrast | \nWCAG 2.2 AA on the token pairs the UI paints, for all 12 built-in themes | \n277 pairs | \n
| jsx-a11y | \neslint-plugin-jsx-a11y recommended rules on every component | \n128 violations in 52 files | \n
The contrast fixes change lightness only and keep each theme's hue, and a second test keeps the primary, secondary and muted text tiers in order so a fix cannot flatten the hierarchy. You will notice them most in Solarized, Nord, Tabularis Light, whose status colors are darker, and GitHub Dark, whose accent and focus ring are lighter. The accessibility fixes are the less visible half: clickable divs became buttons, rows and tabs that contain other controls respond to Enter and Space, several menus that ignored Escape now close on it, resize handles are keyboard-operable separators, labels are tied to their controls, icon-only buttons have translated names, and every newly focusable element has a focus ring. The sidebar width and editor split are still mouse-only.
For theme authors, PR #807 separates what the app validates from what the registry validates. The app's manifest schema keeps only the runtime contract and tolerates extra metadata, so a manifest the registry accepts, such as the published Ember 1.0.0 with a display name and a stable id, is no longer rejected at install time. The archive validator still admits only declared files, so tolerated keys cannot smuggle payload. @tabularis/create-plugin 0.4.0 ships the matching tabularis-theme validator.
Generate SQL builds SELECT, UPDATE and DELETE previews for a table. For a driver plugin speaking a different dialect, the host's generic output was wrong: SQL Server users got LIMIT 100. PR #818 adds an optional table_query_templates capability and a get_table_query_template RPC. When a driver opts in, the modal asks it for the template, passing structured identifiers, schema, columns and the explicit SELECT limit; built-in drivers and plugins that do not opt in keep the existing generation. Only a JSON-RPC method-not-found falls back to it; any other error is shown instead of silently producing SQL in another dialect, and stale responses no longer overwrite the current one.
The first plugin to use it is SQL Server 1.0.0-beta.3, which emits SELECT TOP (100), schema-qualified bracket-escaped identifiers, unique :value_N placeholders, and WHERE 1 = 0 guards on UPDATE and DELETE previews, and stops rewriting queries that carry their own TOP or OFFSET/FETCH. The capability defaults to false, so no plugin needs a newer runtime just because this exists.
Every JSON-RPC call to a driver plugin, execute_query included, used to wait at most a hardcoded 120 seconds. A VACUUM, a batched DELETE or an index build on a plugin connection was always cut off, and nothing short of a rebuild could change it (#832). Worse, the cut-off was only on the host side: Tabularis dropped its pending request and showed an error, while the plugin kept working and the statement kept running on the server. A DELETE you had just seen fail could still take effect.
PR #833 makes the limit a setting. Settings → Plugins → Plugin runtime → Call timeout sets it for all plugins (default 120 seconds, 0 for no limit), and each plugin's own settings page has a Call timeout override: leave it blank to inherit the global value, or set 0 to lift the limit for that plugin only. The override lives in the host config, so plugins need no change, and a new value applies to the next call without restarting the plugin, MCP server included. Plugin initialization keeps its own 15-second limit.
PR #842 closes the other half. When a call times out, the host now also writes a JSON-RPC notification to the plugin:
\n{"jsonrpc": "2.0", "method": "cancel", "params": {"id": 42}}\nIt has no top-level id, so the plugin must not answer it, and it is only sent if the request was still pending, so a response that raced the timeout does not trigger a cancel. The PostgreSQL plugin handles it from 1.0.0-rc.6 by calling pg_cancel_backend on the statement's backend: in the PR's end-to-end test, SELECT pg_sleep(60) with a 3-second timeout failed on the host at 3.0 seconds and left no backend running half a second later. Plugins that do not implement cancel behave as before; at worst their reply is dropped with one log line. The contract is documented in the plugin guide as an optional Cancel Notification.
Two fixes for things you notice every day. @drakeo338 makes result grids keep their scroll position when you switch editor tabs and come back, fixing #823 in PR #831, and extends it to every grid in the multi-result panel, tabbed or stacked, in PR #838. The offset is forgotten on a fresh run, a page change or when the tab or result closes. The same work fixes a race that scrolled a tab with pending inserted rows back to the bottom over the restored position.
\n\nPR #828 fixes #826: a value typed into a new row was drawn as green text on a green tint, and modified cells had the same problem in their own color, with contrast as low as 2.9:1. Edited values now use the primary text color; the row tint, the italic style and the NEW marker still show the state. The same PR fixes date cells on new rows: the date picker showed today's date as a starting point but never passed it on, so the cell stayed empty unless you changed a field. A Use this value button, or Enter in the grid, now accepts the date on screen.
Plugins ship on their own schedule, so this is what reached the registry since v0.25.0, not something bundled with the app.
\n@Mohamed-Fameen built the Cassandra plugin against the Cassandra/ScyllaDB bounty, and 0.1.0 is in the registry for macOS, Linux and Windows. It is written in Rust on ScyllaDB's scylla-rust-driver, so one plugin serves both databases, and the author verified it end to end against real Cassandra and real ScyllaDB containers. It lists keyspaces, tables, columns and indexes, runs CQL with native forward paging, and edits rows. The README is upfront about the gaps in 0.1.0: no TLS yet, tables with a composite primary key are browsable and queryable but not editable from the grid, grid writes cover the common scalar types only (decimals, timestamps, collections and UDTs are read-only there, writable through CQL in the editor), and ScyllaDB shard-aware routing is not implemented.
The Oracle plugin 0.1.0 was published the day after v0.25.0 and requires it, since it returns table and column comments. It connects to Oracle Database 12c and newer, including Free/XE, Autonomous Database (tcps://) and Amazon RDS for Oracle, through EZConnect, full connect descriptors or TNS aliases. It browses multiple schemas through the ALL_* views, runs queries with OFFSET/FETCH pagination, PL/SQL blocks, exact NUMBER values and native JSON columns, edits rows with composite primary keys, generates table, column, index, foreign-key and view DDL, and feeds Visual EXPLAIN from PLAN_TABLE, with EXPLAIN ANALYZE runtime statistics from V$SQL_PLAN_STATISTICS_ALL. The Oracle Instant Client must be installed separately, because its license does not allow bundling it; without it, connections fail with a DPI-1047 hint. Triggers, routine editing and user management are not implemented yet.
Ember 1.0.0 is the first theme package in the registry: Ember Dark, charcoal-brown with amber accents, and Ember Light, parchment with copper, in one package. Its manifest uses the stable id and display name that #807 above teaches the app to accept, so v0.25.0 rejects it and v0.26.0 is the first stable release that installs it, from Settings → Appearance → Manage themes or the Themes filter in Plugins.
ROLLBACK. It also implements get_table_ddl, so Dump Database writes a schema-preserving dump for plugin connections instead of failing, and get_schema_snapshot, so the ER diagram loads a schema in one round trip. rc.6 handles the host's new cancel notification, described above, and stops reporting a lowercase DEFAULT null as a default value.TOP or OFFSET/FETCH.pk_map), and the plugin gains a Tabularium manifest and icon. Its id changes from tubularis-d1 to cloudflare-d1-http. The release is on GitHub; at the time of writing the registry still lists 0.3.0.id.KEY_COLUMN_USAGE and REFERENTIAL_CONSTRAINTS join could not be pruned on MySQL 5.7. Both views are now scoped to the selected database and table, which also stops same-named constraints from different tables being mixed on MariaDB. Tested against MySQL 5.7, 8.0 and 8.4 and MariaDB 10.11 and 12.1.registry.json. It now uses the OS trust store, like the PostgreSQL and MySQL connections already did.PATH without /opt/homebrew/bin or /usr/local/bin. The well-known install locations are appended after the inherited entries, so your own aws still wins.file://, or carrying a BOM or zero-width space is normalized before it is opened.tabularis-nightly-bin next to tabularis-bin, from the same PKGBUILD. PRs #835 and #836 fix macOS nightlies that reported the previous stable version to plugins, and nightlies that were cancelled halfway through publication.@tabularis/explain no longer scaffolds and compiles a Rust driver for create-plugin.Eleven external contributors land in this release or in the plugins around it. @egertaia made a PostgreSQL tab a session that keeps its transaction across runs, with the badge, the cleanup on every close path and the idle sweep (#801), and @aesslinger carried the plugin side to release in PostgreSQL rc.5 and rc.6 and fixed the registry behind corporate proxies (#811). @Mohamed-Fameen took the Cassandra/ScyllaDB bounty and shipped the plugin. @verbaux turned the command palette into an action surface and rebuilt shortcut handling (#815, #773). @drakeo338 made the grids remember their scroll position (#831, #838).
\n@wwww-deeeee hardened nearest-table autocomplete (#782), @hkz329 sped up MySQL foreign-key metadata (#802), @Davydhh followed up on SSM with AWS CLI discovery (#806), @coloraven sanitized pasted file paths (#755), @igorzelaya-io finished the read-only JSON viewer work (#781), and @GabrielMalava kept the Cloudflare D1 registry entry honest (#819, #830) and shipped D1 0.4.0 with composite-key edits. Thanks also to @mayeenulislam for the two precise bug reports behind the grid fixes.
\nIf you have ever run COMMIT and wondered which connection it went to, this is the upgrade.
Download the latest published version from the download page. Release notes and packages are available on GitHub Releases.
\n", "image": "https://tabularis.dev/blog/v0260-postgres-tab-transactions-command-palette-accessible-themes/opengraph-image.png", "date_published": "2026-10-01T10:00:00", "tags": [ "release", "feature", "bugfix", "postgres", "mysql", "ui", "ux", "data-grid", "plugin", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0250-installable-themes-aws-ssm-update-badges-mcp-toon", "url": "https://tabularis.dev/blog/v0250-installable-themes-aws-ssm-update-badges-mcp-toon", "title": "v0.25.0: A New Theme System, AWS SSM Tunnels and Startup Improvements", "summary": "v0.25.0 turns themes into installable, declarative packages with author tooling, adds AWS SSM Session Manager port forwarding as a third tunnel method, surfaces core and plugin updates in the sidebar and on a startup toast, cuts the JavaScript loaded at startup by 84%, lets MCP tools return TOON, shows table and column comments, and carries community fixes for the MCP driver registry, read-only JSON viewers and plugin display names.", "content_html": "v0.25.0 follows v0.24.0 with a release about the things around your queries rather than the queries themselves. Themes stop being a fixed list of twelve presets and become packages you install, preview, update and remove the way you already handle driver plugins, with a command-line tool for authors. Connections gain a third tunnel method, AWS Systems Manager Session Manager port forwarding, next to SSH and Kubernetes. Available updates for the app and for installed plugins are counted in the sidebar and announced once at startup instead of waiting in Settings. Startup itself loads far less JavaScript. On the MCP side, every tool can return TOON instead of JSON, and the standalone MCP process now notices plugins that were installed, disabled or removed while it was running. Table and column comments from PostgreSQL and MySQL reach the schema inspector, the sidebar and the grid. The community fixes cover read-only JSON viewers, plugin display names, schema text selection and MongoDB replica set URIs.
\nPR #793, with the follow-up #803, addresses #791: themes are now declarative packages that travel through the same registry and the same install lifecycle as driver plugins. A theme package is a ZIP with a .tabularium manifest of kind: "theme" and one JSON file per variant, typically a light and a dark one. It contains data only. Nothing in a theme package is executed, and theme packages are excluded from the driver activation path entirely.
Two surfaces change. Settings → Appearance → Manage themes lists built-in, personal and installed themes together. Preview applies a theme temporarily and shows a read-only SQL sample rendered by the shared Monaco renderer; Cancel or Escape restores the saved selection, Apply saves it. Installed packages are read-only; Duplicate as personal creates an editable copy. The application theme and the SQL editor theme are selected independently, and the Follow System light and dark picks from v0.22.0 continue to work with installed variants. Settings → Plugins gains a Filter by type control with Drivers and Themes, so theme packages can be installed from the registry, updated, enabled, disabled and uninstalled next to drivers. Removing a theme package reuses the plugin removal dialog and states that every variant of the package is affected. Installing a package never selects a variant on its own: close the dialog and pick it explicitly in Appearance.
\nThe lifecycle underneath is the careful part. The archive is inspected with size bounds, every path and payload is validated, the package is staged privately under a lock, and the install is committed by atomic replacement with rollback on failure. Interrupted operations have an explicit Recover interrupted installs action rather than silent repair. A saved selection that points at a package that is currently unavailable, because it was disabled or its file went missing, falls back to a built-in theme without overwriting your preference; the moment the package is back, the selection is restored. Packages are stored by kind, in plugins/themes/<package>/ beside plugins/drivers/<package>/, and discovery still finds the legacy flat layout.
Imports and exports round it out. Import from VS Code accepts a VS Code JSON or JSONC theme, converts it, lists what could not be mapped and asks you to pick the light or dark base when it cannot tell. Import Tabularis JSON and Export standalone JSON keep the old single-file format, and Export author package produces the package layout for a theme you want to publish. Theme definitions and manifests accept optional $schema hints for editor completion; the runtime ignores them for validation and never fetches a remote schema.
For authors, @tabularis/create-plugin 0.3.0 ships a second binary, tabularis-theme, which scaffolds a two-variant repository, validates both variants offline with the same schemas the app uses, and builds a deterministic ZIP. The generated repository includes a validation workflow for branches and pull requests and a separate draft-release workflow for tags. The guide is THEMES.md. The reference implementation is Ember, a warm amber and copper pair.
One caveat, stated plainly: v0.25.0 is the first release that can install theme packages, so a package must declare min_runtime_version: "0.25.0" and older clients will refuse it. At the time of writing no theme package has been published to the registry yet, Ember included. The Themes filter in Plugins will fill up as authors publish; until then, local ZIP installs and VS Code imports are the way to try it.
@Davydhh adds a third tunnel method in PR #766, closing #765. The connection modal gains an AWS SSM tab with Use AWS SSM Port Forwarding, a Managed Node id, and optional AWS Profile and AWS Region. On connect, Tabularis runs aws ssm start-session as a port-forwarding session and points the driver at the resulting local port, exactly as the SSH and Kubernetes methods do. The forward target is the host and port from the General tab, so a connection to an RDS instance behind a bastion node needs no extra fields.
![\"AWS](\"https://tabularis.dev/img/tabularis-aws-ssm-tab.png\")
\n ![\"Connection](\"https://tabularis.dev/img/tabularis-ssm-chip.png\")
\nThe SSM document is derived from that target instead of asked for:
\n| Target host | \nDocument | \n
|---|---|
Loopback (localhost, 127.0.0.1, ::1, blank) | \nAWS-StartPortForwardingSession | \n
| Anything else | \nAWS-StartPortForwardingSessionToRemoteHost | \n
Both are supported on purpose. Some IAM policies grant only the plain document, and a remote-host-only implementation would lock those users out. The tab shows which document will be used and reminds you that ssm:StartSession is needed on the target and on that document. A Test SSM button opens a real session and closes it again without touching the database.
Three decisions are worth knowing. Readiness is taken from the AWS CLI reporting its own open port on stdout, never from probing the local port; a probe also succeeds against a foreign process that won the race for that port, which would silently query the wrong database. Teardown signals the whole process group, because the CLI spawns session-manager-plugin as a child and that child is what holds the port. Cached sessions are checked for liveness before reuse, since AWS ends sessions on idle timeout. Credentials are delegated to the AWS CLI, so SSO, assumed roles and credential processes behave as in your terminal, and nothing SSM-specific is written to the keychain.
Failures are classified into actionable messages: plugin missing, expired SSO, absent credentials, TargetNotConnected, IAM denial, port conflict, wrong region. The second commit fixes the frontend classifier, which read an IAM "Access denied" as a database login failure and a missing aws binary as an unreachable database server. SSM, SSH and Kubernetes are mutually exclusive on a connection, and connections using SSM carry an SSM chip on the Connections page and in the sidebar. Static access keys, a plugin path override, EC2 and RDS target discovery and Secrets Manager passwords are out of scope for now.
PR #786 surfaces core and plugin updates without opening Settings. The sidebar rail carries one aggregated counter; inside Settings, Plugins and Info each show their own count with a tooltip naming the plugins or the version involved. The Plugins badge used to count configuration entries, built-in drivers included; it now counts installed plugins with an update that is compatible with your app version and platform. Registry state is shared between navigation, Settings and the startup check, and refreshes after a plugin install, update or removal.
\nWhen plugin updates are found at startup, one dismissible toast appears. Clicking it or Open Plugins lands on Settings → Plugins with the Updates filter applied, also when Settings is already open. No toast is shown for an empty or failed initial check, so an offline registry stays quiet. For core updates, Remind Me Later keeps suppressing the modal on background checks but no longer hides the fact that an update exists: the sidebar badge and the Info details remain.
\nThe same PR reworks how status is drawn. A semantic tone system with shared Chip and CountBadge primitives replaces hardcoded palette classes on connection cards, list rows, plugin cards, the sidebar rail and the Settings navigation, so every one of the twelve bundled themes gets readable badges; a coverage test checks chip contrast on each preset. The Plugin Center gets clickable metric tiles, a single toolbar, split-button actions with a keyboard-navigable version list, and status moved into the chip row. The Info tab gains an update status card with check, release notes and install actions.
\n\nOpening the Connections screen used to load 8.79 MB of JavaScript, repeat several bootstrap IPC requests, and do work for dialogs that were closed and features that were off. PR #790 loads the editor, secondary screens, dialogs and locales on demand, shares bootstrap reads with explicit invalidation, publishes persisted settings before the optional AI discovery runs, and skips the initial theme rewrite. Session restore opens the last active connection and its editor first, then restores the remaining connections in the background without stealing focus. Native plugin registration no longer waits for each enabled plugin's initialization handshake; a plugin is initialized once, before its first RPC.
\n| Metric | \nBefore | \nAfter | \n
|---|---|---|
| Initial JavaScript | \n8.79 MB | \n1.43 MB | \n
| Initial JavaScript requests | \n9 | \n2 | \n
| Initial CSS | \n344 KB | \n181 KB | \n
| Initial IPC calls | \n49 | \n29 | \n
| Remote changelog requests at startup | \n1 | \n0 | \n
The timing figures in the PR (Connections ready in 85 ms instead of 190 ms, first paint in 68 ms instead of 176 ms) come from a Chromium benchmark with simulated Tauri IPC, not from a measured native launch, and were taken before the update-notification work above landed. The size and request counts are what you get. The trade is that Monaco, non-English translations and plugin initialization now pay their cost on first use. The audit lists what remains.
\nTwo changes for the MCP server. PR #762, fixing #758, adds an optional output_format argument to all five tools. It accepts json, the documented default, and toon, the Token-Oriented Object Notation encoding that represents repeated records compactly. The transport stays JSON-RPC; only the content[0].text payload changes. Calls that omit the argument get the same pretty-printed JSON as before, and an invalid value returns -32602 before any connection is resolved or query executed. A new MCP Server → Safety → Tool output → Default output format picks the encoding used when a call does not specify one; it is stored as mcpOutputFormat in config.json.
![\"MCP](\"https://tabularis.dev/img/tabularis-mcp-tool-output.png\")
The second change comes from @aesslinger, in three PRs. The standalone tabularis --mcp process built its driver registry once at startup, so a plugin installed or enabled in the GUI, or a connection migrated to a plugin, produced Unsupported driver until you restarted your MCP client. PR #784, fixing #783, rescans installed plugins against the on-disk config on a registry miss and retries, rate-limited to once every two seconds so a connection with a genuinely wrong driver id cannot force a filesystem scan per call. The rescan is idempotent and keeps the collision refusal for plugins claiming a built-in id. PR #789, fixing #787, covers the other direction: a driver disabled or uninstalled in the GUI is now unregistered from the running MCP process, checked on every resolution under its own cooldown. PR #800 folds the two hand-rolled cooldown gates into one tested Cooldown type with no behaviour change. Both fixes were verified against a live process without restarting it.
#722 asked for the descriptions that live in the database to be visible in the client. PR #764 adds an optional comment to table and column metadata, reads it from PostgreSQL and MySQL/MariaDB including the batch metadata path, and shows it in three places: the View Schema modal gets a table description and a comment column, the sidebar shows table and column comments as tooltips, and the data grid header tooltip shows the column comment next to its type. Generated DDL preserves them, as inline COMMENT clauses for MySQL and COMMENT ON statements for PostgreSQL and Oracle, with apostrophes escaped and Unicode and newlines intact.
![\"PostgreSQL](\"https://tabularis.dev/img/tabularis-schema-comments.png\")
\n ![\"The](\"https://tabularis.dev/img/tabularis-grid-header-comment-tooltip.png\")
\nThe plugin contract is additive: get_tables and get_columns may return comment: string | null, legacy payloads without it still deserialize, and no capability flag, RPC method or runtime floor is involved. The ClickHouse plugin already emitted comments from system.tables and system.columns; this release makes them visible. Follow-ups for the PostgreSQL, DuckDB, Db2, Oracle and SQL Server plugins are tracked in their repositories. SQLite has no comment syntax and returns none.
Driver plugins that authenticate without a database login, such as Windows integrated authentication, IAM tokens or Kerberos, had no way to remove the username and password inputs from the connection form. PR #780 extends the connection-modal.extra_fields slot context with credentialFieldsHidden and setCredentialFieldsHidden(hidden). Hiding removes the block and clears both values so a stale login never reaches the driver, and the flag resets whenever the driver changes. The plugin's own choice lives in the opaque extra map the host already persists.
The follow-up commit closes a keychain gap that surfaced with it: on edit, an empty password was omitted from the payload and the stored secret survived, so the next connect injected it again with no visible field to fix. While the inputs are hidden the modal now sends an explicit empty password, update_connection deletes the keychain entry on "", and a connection-string import ignores the login part. The design comes from @egertaia's work in #775 and the SQL Server plugin, where the Use Windows Authentication checkbox will use this hook; this PR moves it onto a driver-agnostic slot so any plugin can do the same. The typed context ships in @tabularis/plugin-api 0.2.0.
id as the stable identifier and name as the human-readable name. The catalogue now shows that name for standalone plugins instead of title-casing the slug; shared engine cards keep their engine title, and saved connections and folders are unaffected. The plugin guide documents the migration order: add id equal to the existing slug first, then change name.user-select: none. Column names and metadata are selectable again, with theme-derived selection colours that stay readable in High Contrast.src/version.ts so the UI shows the nightly version, and tags the commit actually built.extra_fields slot and fixes credentials-only connections that were rejected for a missing host. Notes in the plugin release.@tabularis/create-plugin 0.3.0 and @tabularis/plugin-api 0.2.0 are published with provenance whenever a version on main is not yet on the registry, and each package now runs its own tests in CI. The tabularis-create-plugin CLI reads its version from package.json instead of a hardcoded 0.1.0.Six external contributors land in this release. @Davydhh built AWS SSM Session Manager port forwarding, from document derivation to teardown and error classification (#766). @aesslinger made the standalone MCP process follow plugin installs, disables and removals without a restart, then cleaned up the cooldown logic (#784, #789, #800). @igorzelaya-io opened the JSON viewers on read-only results (#763).
\n@NewtTheWolf separated plugin identity from display names (#795), @fuleinist shipped DynamoDB 0.1.7 with plugin-owned connection fields (#796), and @egertaia designed the hidden-credentials behaviour that became the generic slot hook (#775, #780).
\nIf you want a theme that is not one of the twelve, reach databases through Session Manager, or keep forgetting which plugins have an update waiting, this is the upgrade.
\nDownload the latest published version from the download page. Release notes and packages are available on GitHub Releases.
\n", "image": "https://tabularis.dev/blog/v0250-installable-themes-aws-ssm-update-badges-mcp-toon/opengraph-image.png", "date_published": "2026-09-22T10:00:00", "tags": [ "release", "feature", "bugfix", "ui", "ux", "plugin", "mcp", "postgres", "mysql", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/how-to-grow-an-open-source-project", "url": "https://tabularis.dev/blog/how-to-grow-an-open-source-project", "title": "How to Grow an Open-Source Project: Lessons on the Road to 5,000 Stars", "summary": "Lessons from growing Tabularis toward 5,000 GitHub stars: make room for contributors, protect everyday workflows, and plan for the maintenance that comes with new features.", "content_html": "As I write this, Tabularis is about twenty GitHub stars away from 5,000. We might get there in a day or two, perhaps sooner. By the time you read this, the counter may already have moved past it.
\nIt feels like a good moment to stop and look at what has happened since January.
\nWhen I wrote about the first 1,000 stars, the story was still mostly about getting started: shipping the first versions, meeting the first contributors, discovering that other people wanted this thing too. Five months later, there is much more to maintain, more to learn, and a growing number of people helping decide what Tabularis becomes.
\nHere are the lessons I would take into another open-source project: start with a problem you understand, give contributors room to work, and make each expansion something you can maintain.
\n![\"Cumulative](\"https://tabularis.dev/img/posts/tabularis-5k-stars-growth.svg\")
The curve includes quiet stretches and sudden jumps. It records interest in the project; understanding what people actually need still happens through conversations, reports and contributions.
\nTabularis began as a database client I wanted to use myself. Its first name was debba.sql. There was a SQL editor, a Tauri application around it, and plenty of rough edges.
The early pace was intense. The first week produced fifteen releases. Some fixed things the previous release had broken. Getting the application into people's hands brought feedback I could never have produced on my own machine: different Linux environments, unfamiliar database configurations, and expectations I had not considered.
\nIn the 1,000-star post, I called that phase “Ship Fast, Ship Broken, Ship Anyway.” Reading it again now, I can see how much of that advice belonged to that particular moment.
\nFast feedback still matters. So does being able to ship a fix quickly. But every new workflow someone builds around Tabularis adds something worth preserving. A query editor can become part of a working day. A connection configuration can represent hours of setup. An export can be the file someone else is waiting for.
\nStart with a workflow you can test yourself, then let real users challenge your assumptions. As they build routines around the application, include those existing workflows in your release checks.
\nChoosing Tauri gave the project a Rust backend for database connections, tunnels, credentials and exports, with React for the interface. It also brought the ongoing work of supporting different system webviews and packaging environments. Those tradeoffs are still visible in today's bug reports.
\nThe plugin system changed who could extend the application.
\nAn external driver speaking JSON-RPC gave contributors a manageable boundary. Someone could bring knowledge of a database and work on its driver without taking ownership of the entire desktop application. It opened a path for integrations I would never have had time to build alone.
\nThat path has continued to grow. Dominik Spitzli, @NewtTheWolf, built Tabularium, the plugin registry that lets authors publish through their own repositories. SQL Server now has its own driver plugin. PostgreSQL has also moved into a plugin, putting an important part of the original application through the same extension model.
\nThese changes carry maintenance costs: protocol compatibility, installation, updates, and clear expectations about what a driver supports. They also let more work happen independently.
\nNotebooks and Visual EXPLAIN expanded the application in another direction. A query can sit beside an explanation, a chart, and the steps that led to it. Looking at how the database executes that query becomes part of the same investigation.
\nGive a contributor a clear boundary, a working example and a way to test their change. In Tabularis, a driver provides that starting point. Other projects might offer an integration, a theme or a small, independently testable module.
\n![\"Monthly](\"https://tabularis.dev/img/posts/tabularis-5k-community-prs.svg\")
As of September 18, the main repository has merged 257 pull requests from 80 authors other than me, excluding bot accounts. That is one visible part of the collaboration. Work in driver repositories, translations, testing and support adds much more than this chart can show.
\nThe latest release, v0.24.0, is a useful snapshot of the challenges now.
\n“Follow the system theme” sounds like a small setting. On Linux, the desktop preference, toolkit and webview can disagree. Getting it right required following native appearance signals and making sure the theme chosen by the application did not feed back into its own system-theme detection.
\nProxy support sounds like one connection setting. In practice, the application makes update requests, downloads plugins, talks to AI providers, opens database connections and connects to SSH bastions. Those requests may need different routes. Existing tunnels also need a defined lifecycle when the configuration changes.
\nPutting query plans inside notebooks introduces another set of decisions. EXPLAIN ANALYZE actually executes the statement. The interface needs to make that choice explicit, recognise when the query has changed, and avoid running another database request just because someone opens a larger view of a plan.
\nThis is the kind of work a changelog compresses into a few lines. It means reproducing a report, understanding the environment, reviewing a contribution, and checking the surrounding behavior.
\nAsk for the environment and the smallest reproduction, then preserve what the report teaches you in a regression test or a documented manual check. People bring operating systems, database types and network setups I cannot cover alone; their reports should keep helping after the issue closes.
\nTabularis Web is one of the larger pieces of work currently underway. The pull request is still open as I write this.
\nThe goal is to run the application through a browser while sharing its React interface and Rust application services with the desktop client. That requires finding all the places where the application assumes it owns a native window, a local file dialog, or access to the same machine as the user.
\nFile transfers, authentication, query cancellation, credentials and plugin assets all need explicit behavior across that boundary. A browser disconnecting is another event the application must handle. The desktop version must continue to work while these assumptions are being separated.
\nI have already written about the development process behind that work, including the use of AI coding tools. That experience reinforced how much depends on the plan, the checks and the review around the implementation. External review found security issues even after the planned tasks and their tests were complete.
\nBefore adding another way to run your application, identify what it can share and what will need separate verification. Budget for both. Tabularis Web makes that question concrete for the next stage of this project.
\nReserve time for documentation, reviews and compatibility alongside feature work. For Tabularis, that leads to three priorities.
\nReliability across everyday workflows. Query execution, editing, imports, exports and reconnection should behave predictably. This means continuing to investigate the awkward cases: session state, unusual data types, interrupted operations and platform-specific failures. It also means making the interface clearer. The planned design system is an opportunity to give both users and contributors more consistent components and conventions.
\nAn ecosystem people can build on. Plugin authors need useful documentation, stable contracts and a practical way to test compatibility. The connection-specific metadata introduced in v0.24.0 is one step: a generic plugin can describe the database behind each connection instead of forcing every connection into the same static capabilities. Work like this makes future integrations possible, while leaving their implementation in the hands of people who know those systems.
\nA sustainable maintenance process. Reviews, release verification, documentation and support all compete for time. Making those tasks easier to share matters as the project grows. Clear reproduction steps, contributor guides and well-scoped changes help the next person participate with less guesswork.
\nThese are directions for the work ahead. Some have code under review; others need design, discussion and people willing to help. They will take more than another release cycle.
\nThe most encouraging part of this project has been seeing people decide it was worth improving.
\nSome have written drivers or added features. Others have translated the interface, worked through packaging problems, tested a fix, or explained exactly where a workflow fell apart. People have shared Tabularis with colleagues, written about it, and supported the infrastructure and tools that help keep development moving.
\nA star records interest. The conversations and contributions around the repository show much more of what that interest can become. I am grateful for both.
\nWe are approaching 5,000 with an application that has grown substantially since January, and plenty of work still to do. Thank you to everyone who has helped bring it this far.
\nIf you have used Tabularis, including if you tried it and went back to something else, I would like to hear this:
\nWhat is the one thing Tabularis still needs before it can become your everyday database client?
\nTell us in GitHub Discussions or Discord. That feedback will help shape what comes next.
\nAbout the charts: GitHub API snapshot taken on September 18, 2026. The star curve is reconstructed from the timestamps of current stargazers, so it excludes stars subsequently removed. Pull requests are grouped by merge month in UTC, with bot accounts excluded; September is incomplete. The PR chart covers the main repository only, excludes direct commits, and does not measure the size or effort of contributions.
\n", "image": "https://tabularis.dev/blog/how-to-grow-an-open-source-project/opengraph-image.png", "date_published": "2026-09-18T12:00:00", "tags": [ "community", "milestone", "open-source", "engineering" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0240-notebook-query-plans-proxy-settings-result-fonts", "url": "https://tabularis.dev/blog/v0240-notebook-query-plans-proxy-settings-result-fonts", "title": "v0.24.0: Query Plans Inside Notebooks, HTTP/SOCKS5 Proxies, and a Font for Your Results", "summary": "v0.24.0 brings inline notebook query plans, scoped HTTP/SOCKS5 proxies, independent result fonts, running-tab indicators, and connection-specific plugin metadata.", "content_html": "v0.24.0 follows v0.23.0 with changes to the work you do after connecting. A notebook cell can keep its execution plan beside its SQL and results, rather than sending you into a separate modal. Network settings let you route application requests, database connections, AI calls and SSH traffic independently through an HTTP or SOCKS5 proxy. Query results get their own font picker, and a running query identifies its tab even while you work elsewhere. Underneath, plugins can discover capabilities and data types per connection instead of describing every server with one static manifest. The community fixes cover autocomplete ranking, Linux appearance detection, Snap packaging and desktop deep links.
\n@harshavardhankonisa brings Visual EXPLAIN into the cell itself in PR #718. SQL cells on a connection that supports EXPLAIN gain a Query Plan toggle in their header. Turn it on and a resizable plan section appears alongside Query, Results and Chart, using the same Visual EXPLAIN views as the standalone viewer. Visibility is saved with the cell and survives notebook export and import.
\n\nThe first opening requests a plain EXPLAIN, not ANALYZE. The panel has an EXPLAIN ANALYZE checkbox, a Re-run button and a popout that opens the already-fetched plan in the full modal without another database request. Selecting ANALYZE does not execute anything until you press Re-run. That distinction matters: ANALYZE runs the statement, including writes for data-modifying queries.
\nThe plan uses the query the notebook would actually execute. @param values are substituted and {{cell_N}} references expand to their result CTEs. If a referenced cell has not run successfully, the panel names the unresolved references and sends no request. If you change the SQL, connection or schema after fetching a plan, the old plan is replaced by an outdated notice until you explicitly refresh it. The ANALYZE choice is tied to that source too, so consent to analyze one statement does not carry over to a different one. Running the cell again does not silently run EXPLAIN again.
Several notebook fixes ship with it. CSV and JSON exports now report success or failure instead of swallowing write errors. Repeated checks for parameters and cell references no longer alternate between true and false because a shared global regular expression retained its cursor. Referencing the same cell twice emits one CTE instead of duplicate definitions. And reordering, inserting or deleting cells no longer remounts every cell below the change, preserving their editor and panel state.
\nPR #737, by @coloraven, adds Settings → Network. Configure an HTTP CONNECT or SOCKS5 endpoint with an optional username and password, then choose which traffic should use it:
\n| Scope | \nWhat it covers | \n
|---|---|
| App network requests | \nUpdate checks, plugin downloads, registry requests and WebDAV backups. | \n
| Database connections | \nDirect database TCP connections. | \n
| AI / LLM endpoints | \nRequests to the configured AI providers. | \n
| SSH tunnels | \nThe outbound connection to the SSH bastion. | \n
![\"Settings](\"https://tabularis.dev/img/tabularis-network-proxy.png\")
The global proxy is off by default, and each scope is opt-in. A database connection's Advanced section and each AI provider's settings can inherit the global choice, use a custom endpoint or disable proxying for that target. An explicit target override takes precedence over the global setting. Proxy passwords go into the OS keychain, not config.json or connections.json.
For SSH, the proxy applies to the bastion hop; the local leg produced by an SSH or Kubernetes tunnel is not sent through a second database proxy. Reusable SSH profiles do not gain a separate proxy picker in this release: use the global SSH scope or the database connection's override. Saving global proxy settings tears down existing SSH tunnels and cached forwards so later connections use the new configuration; reconnect after changing it.
\nThis is routing control, not a promise that every third-party plugin's own HTTP client obeys application settings. It is also not a replacement for TLS to the database or AI endpoint.
\nUntil now, the grid was hardwired to a monospace stack. Changing the interface font did not change result cells, which is what #726 asked for. PR #741 adds Settings → Appearance → Data Grid → Result font.
\nChoose Same as interface, a bundled font or a custom family. The default remains JetBrains Mono, so existing installations look the same. The choice covers result cells, inline edit inputs and multiline textareas; multiline width measurement uses the actual selected font, so proportional text is not measured as if it were monospace. SQL editors, logs, hex and JSON views keep their own typography. The setting is persisted as resultFontFamily; Same as interface is stored as inherit and follows later interface-font changes.
![\"Appearance](\"https://tabularis.dev/img/tabularis-result-font.png\")
PR #767 replaces a tab's type icon with a spinner in the connection's accent colour while a query is executing. It carries an Executing query tooltip and an accessible status role, and remains visible when another tab is active. The thin pulsing line beneath the tab stays too.
\n\nNotebook tabs participate: one running cell or Run All keeps the indicator active until all currently executing cells finish. Errors and cancelled execution guards clear it correctly, and loading state is not persisted into a restored session. A small change, but it answers “which query is still running?” without opening each tab.
\nA generic driver cannot describe PostgreSQL and MySQL accurately with the same type list and identifier quoting. PR #744, following discussion #728, gives plugins an opt-in connection metadata discovery contract.
\nA manifest can declare "connection_metadata": true. After a successful connection test, Tabularis calls get_connection_metadata before loading database objects. The reply can override capabilities, data types and type mappings for that connection. The registered manifest stays immutable: two connections using the same plugin do not overwrite each other's dialect or type selectors, and backend operations, including MCP, resolve the same connection-specific metadata.
Omitted fields keep their manifest defaults; explicit false values and empty collections replace them. A connection cannot lift a manifest-level read-only restriction. Discovery is cached per plugin process and invalidated by connection tests and disconnects. Only JSON-RPC -32601 falls back to the static manifest; authentication failures, transport errors and malformed responses remain visible errors.
Existing plugins do not opt in automatically and receive no new discovery requests. This ships the host contract, not a finished JDBC integration: a bridge still needs to implement the method and route requests to the correct database worker, and its registry must accept the opt-in field. The protocol reference documents those boundaries.
\nnetwork-status plug needed by WebKit's portal requests and stops mixing a staged WebKit library with the GNOME platform's helper processes. Sandboxed launches skip redundant deep-link registration. Keychain errors in Snap now point to sudo snap connect tabularis:password-manager-service.%u to the executable, so a tabularis:// URL is not lost on a cold start. The launcher name becomes Tabularis and its category becomes Development, shared by deb, rpm and AppImage packaging.pnpm/action-setup moves to 6.1.0 in PR #768.Eight external contributors land in this release. @harshavardhankonisa built inline notebook plans and fixed the surrounding notebook state and export issues (#718). @coloraven added scoped proxy routing and target overrides (#737). @adisusilayasa made multi-table autocomplete prioritise the table you are working with (#679).
\n@be-student fixed native theme detection (#723), @wangyingsm repaired Snap integration (#712), and @anandghegde fixed Linux desktop entries (#754). @aesslinger closed the plugin-activation config race and added Escape to the migration checklist (#736). @igorzelaya-io replaced the committed TLS test fixture with runtime generation (#742).
\nIf you investigate queries in notebooks, work behind a proxy, or keep losing track of the tab that is still running, this is the upgrade.
\nv0.24.0 is available now. Download the builds from the release page.
\n", "image": "https://tabularis.dev/blog/v0240-notebook-query-plans-proxy-settings-result-fonts/opengraph-image.png", "date_published": "2026-09-16T10:00:00", "tags": [ "release", "feature", "bugfix", "ui", "ux", "data-grid", "plugin", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0230-postgres-plugin-migration-sql-files-storage-location", "url": "https://tabularis.dev/blog/v0230-postgres-plugin-migration-sql-files-storage-location", "title": "v0.23.0: The PostgreSQL Plugin Takes Over From the Built-in Driver, SQL Files Open in Editor Tabs, and a Data Folder You Can Sync", "summary": "v0.23.0 lets plugins ship their own Visual EXPLAIN parsers, which is what the new SQL Server plugin (1.0.0-beta.1) needs, opens, edits and saves .sql files in editor tabs without executing them, moves the whole data folder to any location such as an iCloud Drive or Dropbox folder, deprecates the built-in PostgreSQL driver in favour of the PostgreSQL plugin with a reversible, per-connection or bulk migration flow, fixes two bugs that swallowed keystrokes in the SQL editor, and carries community fixes for dump escaping, connections.json field loss, the PostgreSQL pool size and shortcuts firing during IME composition.", "content_html": "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.
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.
![\"Visual](\"https://tabularis.dev/img/tabularis-explain-raw-xml.png\")
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.
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.
![\"The](\"https://tabularis.dev/img/tabularis-sql-file-save-split.png\")
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.
\nThe 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.
\nIssue #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.
![\"Settings](\"https://tabularis.dev/img/tabularis-settings-storage.png\")
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.
![\"Settings](\"https://tabularis.dev/img/tabularis-settings-storage-new-folder.png\")
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 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:
![\"The](\"https://tabularis.dev/img/tabularis-deprecated-badge-catalogue.png\"){kind=icon}
![\"Connections](\"https://tabularis.dev/img/tabularis-postgres-deprecation-banner.png\")
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.
\n![\"The](\"https://tabularis.dev/img/tabularis-migration-checklist.png\")
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.
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.
\nThe 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.
\nThe 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.
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.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.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.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 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.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).Five external contributors land in v0.23.0.
\n@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.
\nv0.23.0 is available now. Update via the in-app updater, or download from the releases page.
\n", "image": "https://tabularis.dev/blog/v0230-postgres-plugin-migration-sql-files-storage-location/opengraph-image.png", "date_published": "2026-09-10T10:30:00", "tags": [ "release", "feature", "bugfix", "postgres", "mysql", "sqlite", "plugin", "ui", "ux", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/how-plugins-can-now-inject-their-own-parsers-into-visual-explain", "url": "https://tabularis.dev/blog/how-plugins-can-now-inject-their-own-parsers-into-visual-explain", "title": "How plugins can now inject their own parsers into Visual EXPLAIN", "summary": "explain.tabularis.dev now reads SQL Server plans, and the parser does not live in the core. This is how @tabularis/explain got a parser registry, how a driver plugin ships its own parser as a bundle the app loads at runtime, and why the SQL Server plugin finally lands next week.", "content_html": "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.
\nThis 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.
\nWhen 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.
\nThe work landed in two steps in the Tabularis repository.
\nThe 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 {\n readonly engine: string;\n readonly format: string;\n readonly label?: string;\n parse(payload: string): ExplainPlan;\n sniff?(payload: string): boolean;\n}\n\nexport function registerExplainParser(parser: RegisteredExplainParser): void;\nexport function unregisterExplainParser(format: string): void;\nThe 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:
\nexplain_query with raw output, the same engine, format and payload shape the built-in drivers already used, instead of a parsed plan.explain_parsers array. Each entry names the engine, the format, a label, and the path of a JavaScript bundle inside the installed plugin directory.@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.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 plugin guide has a new section on this, so any third-party driver can do the same thing without waiting for a core release.
\nOn 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.
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.
\nThe 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.
\nThe 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.
\nUntil 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.
\n", "image": "https://tabularis.dev/blog/how-plugins-can-now-inject-their-own-parsers-into-visual-explain/opengraph-image.png", "date_published": "2026-09-04T18:30:00", "tags": [ "explain", "sql-server", "plugins", "architecture", "typescript", "rust", "extensibility" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0220-follow-system-theme-grid-selection-shortcuts-tiling-decorations", "url": "https://tabularis.dev/blog/v0220-follow-system-theme-grid-selection-shortcuts-tiling-decorations", "title": "v0.22.0: Themes That Follow Your OS, Spreadsheet Selection in the Grid, and a Titlebar That Gets Out of the Way on Tiling Window Managers", "summary": "v0.22.0 adds a Follow System theme mode with separate light and dark picks that switch live with the OS appearance, Google Sheets style keyboard selection in the data grid (Shift+Arrow ranges, Ctrl+Space columns, Shift+Space rows, header click to select a column), automatic hiding of native window decorations on Hyprland, Sway, i3 and other tiling window managers, a round of notebook fixes, and community patches for the production banner, PostgreSQL test connections with client certificates, SQLite text BLOBs and MySQL routines in non-default schemas.", "content_html": "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.
\nTabularis 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:
\nprefers-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.
![\"Settings](\"https://tabularis.dev/img/tabularis-theme-mode-follow-system.png\")
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:
\n| Shortcut | \nAction | \n
|---|---|
Shift + Arrow | \nExtend a rectangular range by one step. The anchor stays fixed, the opposite corner moves. | \n
Ctrl/Cmd + Arrow | \nJump the focused cell to the grid edge. | \n
Ctrl/Cmd + Shift + Arrow | \nExtend the range to the grid edge. | \n
Ctrl/Cmd + Home / End | \nFirst / last cell of the grid. | \n
Shift + Space | \nSelect the row(s) of the focused cell or of the current range. | \n
Ctrl/Cmd + Space, or Ctrl/Cmd + Shift + Space | \nSelect the column(s) of the focused cell or of the current range. | \n
![\"The](\"https://tabularis.dev/img/tabularis-grid-keyboard-range.png\")
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.
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.
![\"Settings](\"https://tabularis.dev/img/tabularis-settings-general.png\")
Two PRs from @harshavardhankonisa went through the notebook frontend with a magnifying glass.
\nPR #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.
![\"A](\"https://tabularis.dev/img/tabularis-notebook-autofit-editor.png\")
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.
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.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.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.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.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.Six external contributors land in v0.22.0.
\n@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).
\n@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.
\nIf 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.
\nv0.22.0 is available now. Update via the in-app updater, or download from the releases page.
\n", "image": "https://tabularis.dev/blog/v0220-follow-system-theme-grid-selection-shortcuts-tiling-decorations/opengraph-image.png", "date_published": "2026-09-01T21:40:00", "tags": [ "release", "feature", "bugfix", "postgres", "mysql", "sqlite", "ui", "ux", "data-grid", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0210-sql-folding-per-tab-page-size-postgres-mtls", "url": "https://tabularis.dev/blog/v0210-sql-folding-per-tab-page-size-postgres-mtls", "title": "v0.21.0: Fold Your SQL, Pick Your Page Size Per Tab, and Postgres Client Certificates That Actually Get Sent", "summary": "v0.21.0 adds dialect-aware folding with hover previews to the SQL editor, a per-tab rows-per-page selector that overrides the global limit (including an All option), PostgreSQL mTLS client-certificate authentication, cancellable plugin installs, a safety-confirmation countdown that is now opt-in and shared between destructive and production guards, an SSL-mode migration that finally runs in the MCP process, and a batch of grid, export and import fixes from the community.", "content_html": "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.
\nLong 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.
\n\nThe 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.
![\"The](\"https://tabularis.dev/img/tabularis-page-size-selector.png\")
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.
![\"PostgreSQL](\"https://tabularis.dev/img/tabularis-postgres-client-cert.png\")
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.
\n\nv0.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:
config.json as safetyConfirmationDelayEnabled. When enabled it applies to both destructive-query and production-write confirmations.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.
\n![\"Settings](\"https://tabularis.dev/img/tabularis-settings-safety-delay.png\")
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.
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.Data directory (or a plist inside it) when auto-discovery fails.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.CAST(... AS JSON), which MariaDB rejects, and aligns the object palette's multi-database branch with the sidebar's live selection.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.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).Six external contributors land in v0.21.0.
\n@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).
\n@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).
\nIf 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.
\n", "image": "https://tabularis.dev/blog/v0210-sql-folding-per-tab-page-size-postgres-mtls/opengraph-image.png", "date_published": "2026-08-25T18:00:00", "tags": [ "release", "feature", "bugfix", "postgres", "mysql", "sqlite", "ui", "ux", "data-grid", "plugin", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/code-generation-was-only-the-beginning-software-development-is-becoming-a-loop", "url": "https://tabularis.dev/blog/code-generation-was-only-the-beginning-software-development-is-becoming-a-loop", "title": "Code generation was only the beginning. Software development is becoming a loop", "summary": "Tabularis Web touched 1,040 files and moved a desktop database client behind a second transport. This is how I managed it as 48 verified tasks, and why AI development is moving from prompts toward loops.", "content_html": "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.
\nThe 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.
\nThe 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.
\nI 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.
\nAn 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.
\nIn my case the outer loop was more or less this:
\nplan -> fresh agent -> change -> local tests -> commit -> CI\n ^ |\n |--------------- repair ---------------|\nThe 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.
\nLonger 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.
\nStarting 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.
\nFor this project the durable state was deliberately boring:
\nPROGRESS.md with status and verification evidence;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.
\nThe 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.
\nI 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):
\nfor task in "${TASKS[@]}"; do\n pi --print --approve \\\n --name "web-ui-${task}" \\\n --thinking high \\\n --model openai/gpt-5.6-sol \\\n @web-ui-project/docs/WEB_UI_PLAN.md \\\n @"web-ui-project/tasks/${task}.md" \\\n @web-ui-project/tasks/PROGRESS.md \\\n "$TASK_PROMPT"\n\n validate_progress_entry "$task"\n watch_task_ci "$task"\ndone\nThere was more code around this, mostly checks. In particular, the runner required that:
\nEvery task was a conventional commit, so every new session inherited a branch that was supposed to be both understandable and recoverable.
\nEach 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.
\nThe 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.
\nThe 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.
\nFor 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.
\nAfter 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.
\nIt 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.
\nWhat 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.
\nAt 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.
\nLooking 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:
\n| Mode | \nUnit of work | \nDurable state | \nCompletion | \n
|---|---|---|---|
| Autocomplete | \nThe next tokens | \nThe open file | \nThe developer accepts the suggestion | \n
| Chat | \nOne answer | \nThe conversation | \nThe developer asks another question | \n
| Coding agent | \nOne delegated task | \nThe context window and worktree | \nThe agent returns control | \n
| Agent loop | \nOne verified task | \nThe repository, tests and Git | \nExternal checks pass | \n
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.
\nThere 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.
\nI 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.
\nI 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.
\n", "image": "https://tabularis.dev/blog/code-generation-was-only-the-beginning-software-development-is-becoming-a-loop/opengraph-image.png", "date_published": "2026-08-23T13:32:00", "tags": [ "ai", "engineering", "open-source", "ralph-loop", "deep-dive" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0200-command-palette-grid-paste-postgres-plugin", "url": "https://tabularis.dev/blog/v0200-command-palette-grid-paste-postgres-plugin", "title": "v0.20.0: A Command Palette That Knows Which Pane You're In, Paste That Works Like a Spreadsheet, and PostgreSQL Moves Out of the Core", "summary": "v0.20.0 replaces the quick navigator with a scope-aware command palette, teaches the data grid to paste spreadsheet ranges as staged edits, moves PostgreSQL out of the core and into a standalone plugin at full parity with the built-in driver (the first step in migrating every built-in driver to the plugin pipeline), adds inline hex preview and editing for BLOBs, and makes rows with binary primary keys deletable on MySQL.", "content_html": "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 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.
\n\nThe 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.
\nThe 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).
\nCopy 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.
\n\nThe 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.
\nTabularis 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.
\nThis is the model we intend to apply to every built-in driver, and it's worth spelling out why:
\nThe 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.
\nThree threads landed on the same theme: binary and keyless data used to fail in opaque ways, and now doesn't.
\nBLOBs 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.
![\"A](\"https://tabularis.dev/img/tabularis-blob-hex-editor.png\")
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.
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.
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.\n![\"The](\"https://tabularis.dev/img/tabularis-routines-error-indicator.png\")
table_xinfo, so generated columns show up in table grids, flagged as generated and excluded from insert and update paths.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.${name} (@fuleinist, PR #602, closes #550): alongside the existing @name, and both syntaxes can mix in one query.get_create_foreign_key_sql now receives ConnectionParams through the driver trait and the RPC layer, unblocking foreign-key creation in plugins like libSQL.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.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.Seven external contributors land in v0.20.0.
\n@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).
\n@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.
\nv0.20.0 is available now. Update via the in-app updater, or download from the releases page.
\n", "image": "https://tabularis.dev/blog/v0200-command-palette-grid-paste-postgres-plugin/opengraph-image.png", "date_published": "2026-08-17T18:00:00", "tags": [ "release", "feature", "bugfix", "postgres", "mysql", "sqlite", "ui", "ux", "data-grid", "plugin", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/one-sql-script-multiple-database-connections", "url": "https://tabularis.dev/blog/one-sql-script-multiple-database-connections", "title": "We Accidentally Ran One SQL Script Across Multiple Database Connections", "summary": "Run All looked like a UI feature. Underneath, it fanned one SQL script into parallel pool checkouts. The statements succeeded, the session state disappeared, and a parent-child import silently produced missing and duplicated rows.", "content_html": "The import was supposed to create 144 child rows, eight for each of 18 parents. It created 83.
\nTwo 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.
\nThere was no useful error. Every SQL statement looked successful in the UI.
\nThis 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.
\nThe 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.
\nThe application had taken one SQL script and executed it as a collection of unrelated, concurrent database sessions.
\nThe original report involved a longer MySQL import, but its essential dependency fits in four statements:
\nINSERT INTO parent (name) VALUES ('A');\nSET @parent_id = LAST_INSERT_ID();\nINSERT INTO child (parent_id, name) VALUES (@parent_id, 'A-1');\nINSERT INTO child (parent_id, name) VALUES (@parent_id, 'A-2');\nThis 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.
\nIn 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.
\nThere 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.
\nPromise.allSettled was the transaction coordinatorThe old execution path split the script into statements and mapped each one to a separate Tauri command:
\nawait Promise.allSettled(\n statements.map((statement) =>\n invoke("execute_query", {\n connectionId,\n query: statement,\n }),\n ),\n);\nThat 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.
\nOn 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?;\nlet mut conn = pool.acquire().await?;\nexecute_on(&mut conn, query).await\nSQLx 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.
\nThe four-statement script could therefore become this:
\nINSERT INTO parent ... connection 17\nSET @parent_id = ... connection 24\nINSERT INTO child ... connection 31\nINSERT INTO child ... connection 42\nConnection 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.
\nAn 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.
\nMost database failures are kind enough to produce an error code. This one often produced plausible data.
\nThe 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.
\nThat 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.
\nThis 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.
\nThe obvious first fix is to replace Promise.allSettled with a loop:
for (const statement of statements) {\n await invoke("execute_query", { connectionId, query: statement });\n}\nThat restores ordering. It does not restore session identity.
\nEach 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:
\nAwaiting each query gives you the first. Holding one connection for the lifetime of the script gives you both.
\nThis 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.
\nWe 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:
\nlet mut conn = pool.acquire().await?;\nlet mut results = Vec::with_capacity(statements.len());\n\nfor statement in statements {\n let result = execute_on(&mut conn, statement).await;\n results.push(result);\n}\n\nOk(results)\nThe 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.
Keeping one connection alive made transactions structurally possible, but MySQL added another constraint.
\nSQLx 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.
\nThe 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:
\nBEGIN;\nCREATE TEMP TABLE batch_tmp (id serial primary key, value text);\nINSERT INTO batch_tmp (value) VALUES ('a'), ('b'), ('c');\nSELECT count(*) FROM batch_tmp;\nCOMMIT;\nPostgreSQL 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.
\nConnection 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.
\nThese operations all depend on session identity:
\nBEGIN, COMMIT, savepoints and transaction-scoped locksLAST_INSERT_ID()currval() and prepared statementssearch_path, sql_mode or FOREIGN_KEY_CHECKSA 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.
\nThat is the general lesson from this bug:
\nA 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.
\n", "image": "https://tabularis.dev/blog/one-sql-script-multiple-database-connections/opengraph-image.png", "date_published": "2026-08-12T10:00:00", "tags": [ "databases", "sql", "mysql", "postgresql", "connection-pooling", "engineering", "deep-dive" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0190-connection-tags-column-masking-keyless-editing", "url": "https://tabularis.dev/blog/v0190-connection-tags-column-masking-keyless-editing", "title": "v0.19.0: Connections That Know They're Production, Columns That Keep Secrets, and Tables Without a Primary Key You Can Finally Edit", "summary": "v0.19.0 adds colored tags and environment classification with a production write guard, masks sensitive columns in the results grid, makes tables without a primary key editable, closes the plugin driver feature gap with BLOB and materialized-view forwarding plus plugin-owned connection fields, validates plugin archives before they can touch an existing install, and stops bundling libwayland in the Linux AppImage.", "content_html": "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.
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.
\nFree-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](\"https://tabularis.dev/img/tabularis-connection-tags-environments.png\")
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.
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.
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.
![\"The](\"https://tabularis.dev/img/tabularis-privacy-settings.png\")
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.
\nRows 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.
Five threads landed this cycle that together move plugin drivers from "supported" toward "indistinguishable from built-in".
\nBLOB, 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.
![\"The](\"https://tabularis.dev/img/tabularis-dynamodb-plugin-settings.png\")
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.
\n![\"The](\"https://tabularis.dev/img/tabularis-plugin-readme-modal.png\")
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.
\n.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).
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.
FROM and JOIN clauses are schema-qualified, so a query built against a non-default database runs instead of erroring on the wrong one.@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.~ 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".Seven external contributors land in v0.19.0.
\n@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.
\nv0.19.0 is available now. Update via the in-app updater, or download from the releases page.
\n", "image": "https://tabularis.dev/blog/v0190-connection-tags-column-masking-keyless-editing/opengraph-image.png", "date_published": "2026-08-10T11:00:00", "tags": [ "release", "feature", "bugfix", "mysql", "postgres", "sqlite", "ui", "ux", "data-grid", "plugin", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/installing-tabularis-from-aur-without-a-helper", "url": "https://tabularis.dev/blog/installing-tabularis-from-aur-without-a-helper", "title": "Installing Tabularis from the AUR, the Careful Way", "summary": "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. Here's how to build straight from our GitHub repo — and what to check in any PKGBUILD before you run it.", "content_html": "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.
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\nsed -i 's/^pkgver=.*/pkgver={{APP_VERSION}}/' PKGBUILD\nupdpkgsums # fills in the real sha256, needs pacman-contrib\nless PKGBUILD # read it, that's the whole point\nmakepkg -si\nThe 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.
Whatever you install from the AUR these days, take thirty seconds to read the PKGBUILD:
\nsource= points at the real upstream,curl or wget inside prepare()/build(),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.
\nArticle with the details: Arch Linux disables AUR package adoption to stop malware flood (BleepingComputer).
\n", "image": "https://tabularis.dev/blog/installing-tabularis-from-aur-without-a-helper/opengraph-image.png", "date_published": "2026-08-03T19:00:00", "tags": [ "security", "linux", "arch", "aur", "open-source", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0180-user-privileges-connection-diagnostics-grid-selection", "url": "https://tabularis.dev/blog/v0180-user-privileges-connection-diagnostics-grid-selection", "title": "v0.18.0: Users and Privileges, a Connection Test That Tells You Where It Failed, and a Data Grid You Can Actually Select", "summary": "v0.18.0 adds MySQL/MariaDB user and privilege management, rebuilds the connection modal around a real SSH test with classified errors and a step-by-step diagnostics log, lets a connection browse every database without picking any, gives the data grid keyboard navigation and honest copy scopes, exports the ER diagram as Mermaid or DBML, and teaches PostgreSQL to edit hstore and render expression indexes.", "content_html": "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.
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.
mysql.user isn't readable, it falls back to CURRENT_USER rather than showing an empty pane.SHOW GRANTS. Checking grants, unchecking revokes, and the editor revokes before granting so narrowing ALL PRIVILEGES down to a subset actually works.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.
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.
\nssh-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.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.All new strings are translated across the eleven supported locales.
\nUntil 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.
\n![\"The](\"https://tabularis.dev/img/tabularis-all-databases-mode.png\")
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.
Three pieces landed here, and together they change how the grid feels under the hands.
\nSelect 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.
\n\nArrow 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.
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.
\nPR #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.
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.
\n\nExport 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}.
![\"The](\"https://tabularis.dev/img/tabularis-er-export-menu.png\")
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.
Four PostgreSQL fixes land this cycle, three of them from outside the core team.
\nhstore 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.
![\"An](\"https://tabularis.dev/img/tabularis-hstore-editor.png\")
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.
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.
\n![\"The](\"https://tabularis.dev/img/tabularis-new-sqlite-database.png\")
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.
PR #559 started as a README correction and turned into a security pass on how notebooks generate SQL.
\nString.replace, so a value containing $&, $' or $$ was expanded as a replacement pattern — quietly producing SQL that differed from what you were shown.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.
@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.
\ninformation_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.mongodb+srv:// included.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.cn_zh regions, and model listing tries both official regional endpoints so mainland China API keys work.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.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.Fifteen external contributors land in v0.18.0.
\n@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.
\n@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.
\n", "image": "https://tabularis.dev/blog/v0180-user-privileges-connection-diagnostics-grid-selection/opengraph-image.png", "date_published": "2026-08-03T18:00:00", "tags": [ "release", "feature", "bugfix", "mysql", "postgres", "sqlite", "ui", "ux", "data-grid", "plugin", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/rust-stack-inside-a-15mb-database-client", "url": "https://tabularis.dev/blog/rust-stack-inside-a-15mb-database-client", "title": "The Rust stack inside a ~15 MB installer", "summary": "Two database stacks, several TLS verification paths, two SSH clients, a hand-written float16 decoder, and the vendored OpenSSL that refuses to leave: a guided tour of the fifty-odd top-level Rust dependencies behind Tabularis's compact installers — the other half of last week's Tauri story.", "content_html": "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.
\nThis 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.
\nThe 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.
\nHere are the invoices I found worth reading twice.
\n![\"Horizontal](\"https://tabularis.dev/img/posts/tabularis-rust-stack-dependencies.svg\")
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.
\nSQLx 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.
\nWith 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`.\nfn f16_bits_to_f32(bits: u16) -> f32 {\n let sign = if (bits >> 15) & 1 == 1 { -1.0f32 } else { 1.0f32 };\n let exp = (bits >> 10) & 0x1f;\n let mant = bits & 0x3ff;\n match exp {\n 0 => sign * (mant as f32) * 2f32.powi(-24), // zero / subnormal\n 0x1f if mant == 0 => sign * f32::INFINITY,\n 0x1f => f32::NAN,\n _ => sign * (1.0 + (mant as f32) / 1024.0) * 2f32.powi(exp as i32 - 15),\n }\n}\nA hand-rolled float16 decoder in a database GUI. We did not plan for this line item, and we are strangely fond of it.
\nThe 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.
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.
\nThen 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.
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.
\nBut 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.
\nA 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.
\nThe 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.
\nDBeaver'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.
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.
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.
![\"Diagram](\"https://tabularis.dev/img/posts/tabularis-rust-stack-bigint-roundtrip.svg\")
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.
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.
\nThe 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.
\nThen 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 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.
\nAlmost all of them, yes. Not because cost is virtuous, but because the expensive choices bought capabilities users actually need.
\nSQLx 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.
\nThe vendored OpenSSL, meanwhile, is still here. Nobody has had the heart to tell it.
\n", "image": "https://tabularis.dev/blog/rust-stack-inside-a-15mb-database-client/opengraph-image.png", "date_published": "2026-07-30T08:52:00", "tags": [ "rust", "sqlx", "rustls", "engineering", "deep-dive" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0170-visual-explain-diagnostics-row-editor-sidebar-sql-formatting", "url": "https://tabularis.dev/blog/v0170-visual-explain-diagnostics-row-editor-sidebar-sql-formatting", "title": "v0.17.0: Visual EXPLAIN That Points at the Problem, a Row Editor That Follows You, and SQL That Formats Itself", "summary": "v0.17.0 rebuilds Visual EXPLAIN around exclusive metrics, per-node findings and two new views, replaces the row-editor overlay with a selection-following right sidebar, adds SQL formatting with configurable style, clause-aware autocomplete, an opt-in nightly update channel, pgvector support for PostgreSQL, live reaction to DROP DATABASE, and a Brazilian Portuguese translation.", "content_html": "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.
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.
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.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.
\nThe 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.
\n\nThe 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.
\n\nA 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.
\nThe 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.
\n\nTwo changes teach the editor to actually parse what's around the cursor instead of pattern-matching the whole buffer.
\nClause-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.
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.
\nThe 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.
\n![\"The](\"https://tabularis.dev/img/tabularis-release-channel.png\")
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.
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.
\nDROP 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.@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.
\nIN 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.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.document.execCommand, which fails on WebKitGTK/Wayland; both actions now use the Tauri clipboard API, the same treatment Paste already had.Nine external contributors land in v0.17.0.
\n@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).
\n@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.
\nv0.17.0 is available now. Update via the in-app updater, or download from the releases page.
\n", "image": "https://tabularis.dev/blog/v0170-visual-explain-diagnostics-row-editor-sidebar-sql-formatting/opengraph-image.png", "date_published": "2026-07-27T15:00:00", "tags": [ "release", "feature", "bugfix", "postgres", "ui", "ux", "data-grid", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/extracting-visual-explain", "url": "https://tabularis.dev/blog/extracting-visual-explain", "title": "Visual EXPLAIN beyond the app: one engine, multiple hosts", "summary": "Visual EXPLAIN began inside the desktop app. Extracting it produced an npm package and an online visualiser, but also a public API, two release schedules, and a repository question I have not answered yet.", "content_html": "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.
\nFor 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.
\nClaude 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:
\nA plan visualiser needs a plan, not a database.
\nThe rest of the work was that sentence applied to one file after another.
\nThat page now exists at explain.tabularis.dev. Its engine is a public npm package, @tabularis/explain, and the desktop app uses the same package.
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.
\nOn 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.
\nThe 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.
\nNone of this stopped the feature from working inside one application. The second host turned it into an architectural problem.
\nThe 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.
\nThe rule I used for every file is now the first line of the package's description:
\n\n\nTakes raw EXPLAIN output; never runs a query.
\n
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.
\nThe decisions were not difficult once the rule existed. The problem was that these host features were threaded through otherwise portable code.
\nI moved the plan analysis and all the views into a @tabularis/explain workspace package. One important question remained: what should happen to the parsers?
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.
\nThe same parser in two hosts was attractive. One plan model was more valuable.
\nThe parsers did not need to run where Rust runs. They needed to run where the views run.
\nSo 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.
![\"Comparison](\"https://tabularis.dev/img/posts/tabularis-explain-parser-decision.svg\")
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.
\n![\"Diagram](\"https://tabularis.dev/img/posts/tabularis-explain-boundary.svg\")
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.
\nOnce 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.
\nThe 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.
\n![\"The](\"https://tabularis.dev/img/posts/tabularis-explain-extraction-timeline.svg\")
The package has three entry points. The split is the architecture:
\n@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.
\nNow 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.
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.
\nA 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.
\n![\"Comparison](\"https://tabularis.dev/img/posts/tabularis-explain-repository-tradeoff.svg\")
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.
\nThe 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.
\nThe 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.
\nThe 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.
\nThis was technically accurate and practically useless.
\nThe 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.
\nThe extraction was merged as #536, with the app's 3,286 tests passing.
\nYes, and earlier.
\nI 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.
\nThis 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.
\nThat 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.
\nThe 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.
\n", "image": "https://tabularis.dev/blog/extracting-visual-explain/opengraph-image.png", "date_published": "2026-07-27T11:48:00", "tags": [ "explain", "architecture", "typescript", "rust", "engineering", "deep-dive" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/why-tabularis-runs-on-tauri", "url": "https://tabularis.dev/blog/why-tabularis-runs-on-tauri", "title": "Why I chose Tauri, and what it cost me", "summary": "A database client is a systems program with a UI problem. That is why I chose Tauri over Electron and native. After six months and 64 releases, here is the part the framework comparison charts leave out.", "content_html": "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.
\nSix 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.
\nYes, the Windows installer is 12 MB. This is nice. It is also the least interesting part.
\nThe sentence that decided the architecture was this:
\nA database client is a systems program with a UI problem, not a web app with a database problem.
\nThat sentence explains why I chose Tauri. It does not explain the bill. This post is about both.
\nBelow 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.
\nThen 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.
\nThere is also a security argument, but it is easy to exaggerate it.
\nCode 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.
\nThis 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.
\nAnd then there is size.
\n![\"Grouped](\"https://tabularis.dev/img/posts/tabularis-tauri-installer-size.svg\")
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.
\nStill, a 12 MB Windows installer for a database IDE makes me smile.
\nElectron is the easy comparison. Native applications are the ones that made me hesitate.
\nAn 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.
\nSize is not even a native-versus-Tauri argument. Sequel Ace is small too. The small-package story is mostly an anti-bundled-Chromium story.
\nSo why not native? Because native to what?
\nSequel 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.
\nFor 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.
\nThe 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.
\nWhen 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.
\nThis is the trade I eventually wrote down:
\nElectron charges you for the runtime. Native charges you for the platforms. Tauri charges you for the seams.
\nNow for the seams.
\nTauri 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.
\nSo I do not ship a rendering engine, but I answer for three of them.
\nWebKitGTK 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.
\nThe 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.
\nAn 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.
\nMost 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:
\nlibEGL fatal: did not find extension DRI_Mesa. The Snap package failed; the .deb worked.libwayland-client.so made it render.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.
\nElectron 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.
\nIt 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.
\nThe first chart contains the whole story if you look at the last pair of bars.
\n![\"Bar](\"https://tabularis.dev/img/posts/tabularis-tauri-appimage-anatomy.svg\")
Same release, five representative x64 package formats. Four are between 15.8 and 18.3 MB. The AppImage is 93.7 MB.
\nAn 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.
\nThe 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.
\nFlatpak 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.
\nI learned another Linux lesson in the traditional way: by shipping the bug.
\nAt 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.
\nWhen you compile a native Rust backend, you own its system compatibility. Rust gives you systems programming, including the systems.
\nThe most important seam is not packaging. It is in the architecture.
\nThe 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.
\nThe 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.
\nElectron 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.
\nThis 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.
\nYes.
\nNot because Tauri is “Electron without the bloat.” That description is too small, and on Linux AppImage it is not even particularly convincing.
\nI 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.
\nSome 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.
\nThat 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.
\nIf 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.
\nJust budget for the seams.
\nThe AppImage users may now open an issue.
\n", "image": "https://tabularis.dev/blog/why-tabularis-runs-on-tauri/opengraph-image.png", "date_published": "2026-07-22T09:40:00", "tags": [ "tauri", "rust", "electron", "engineering", "deep-dive" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0160-hosted-plugin-registry-k8s-overrides-encrypted-backups", "url": "https://tabularis.dev/blog/v0160-hosted-plugin-registry-k8s-overrides-encrypted-backups", "title": "v0.16.0: A Hosted Plugin Registry, Kubernetes Your Way, and Backups That Encrypt Themselves", "summary": "v0.16.0 gives the plugin ecosystem real infrastructure: a hosted registry at registry.tabularis.dev, a searchable driver catalogue inside New Connection, and one-click deep-link installs — plus kubectl/kubeconfig overrides for Kubernetes tunnels, automatic encrypted connection backups to a folder or WebDAV, run-statement-at-cursor in the editor, AWS RDS IAM authentication for MySQL, and Elasticsearch and Cloudflare D1 drivers.", "content_html": "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.
\nUntil 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.
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.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.@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 community-built drivers joined the registry this cycle.
\nElasticsearch, 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.
\nPlugin 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.
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](\"https://tabularis.dev/img/tabularis-k8s-advanced-settings.png\")
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.
\nv0.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.
\ntabularis-backup-*.json files, so it can't eat anything else living in the same directory.config.json, and the scheduler re-reads its config every minute so settings changes apply without a restart.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.
\nMaking 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.
\nAnd 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.
\n\nIf 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.
![\"The](\"https://tabularis.dev/img/tabularis-rds-iam-auth.png\")
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.
![\"A](\"https://tabularis.dev/img/tabularis-multi-result-sets.png\")
@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.
\n[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.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.nightly-<date>-<sha>), cut only from the newest commit that passed CI, laying the groundwork for a selectable nightly update channel..deb and AppImage keep working on older LTS systems.Eleven external contributors land in v0.16.0.
\n@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).
\n@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).
\n@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).
\nIf 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.
\nv0.16.0 is available now. Update via the in-app updater, or download from the releases page.
\n", "image": "https://tabularis.dev/blog/v0160-hosted-plugin-registry-k8s-overrides-encrypted-backups/opengraph-image.png", "date_published": "2026-07-21T11:00:00", "tags": [ "release", "feature", "bugfix", "plugin", "community", "connections", "mysql", "security", "ui", "ux" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/optimizing-virtualized-react-grid", "url": "https://tabularis.dev/blog/optimizing-virtualized-react-grid", "title": "Optimizing a Virtualized React Grid: 3,420 Formatter Calls Down to 90", "summary": "The Tabularis data grid was already virtualized, but wide tables still took 29 ms of React render work per scroll tick. The bottleneck was the visible rows, not the total row count.", "content_html": "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.
\nThe 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.
\nI 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.
\nThe 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.
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.
\nThe 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.
\nVirtualization 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.
\nThe old DataGrid.tsx rendered rows inline, right inside the component body:
{rowVirtualizer.getVirtualItems().map((virtualRow) => {\n // ~560 lines of row and cell JSX, inline in DataGrid\n})}\nScrolling 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:
cell: renderer,title attribute used for the hover preview,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 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) {\n // renders one <tr>\n});\nThe 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.
\nEverything that is stable for the whole grid goes into one object, memoized once in DataGrid:
/**\n * Stable, per-grid dependencies shared by every row. Bundled into a single\n * object that is memoized in DataGrid so React.memo's default shallow compare\n * on MemoRow only sees a new `ctx` reference when one of these actually changes.\n */\nconst rowCtx: RowCtx = useMemo(\n () => ({ columns, pkColumns, pendingChanges, columnTypeMap, /* … */ }),\n [columns, pkColumns, pendingChanges, columnTypeMap, /* … */],\n);\nEverything that varies per row is computed in the parent's .map and passed as primitives:
<MemoRow\n ctx={rowCtx}\n rowIndex={rowIndex}\n isSelected={isSelected}\n isPendingDelete={isPendingDelete}\n editingColIndex={isRowEditing ? editingCell!.colIndex : null}\n focusedColIndex={isRowFocused ? focusedCell!.colIndex : null}\n/>\nThe 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\n// value without listing editingCell in their deps; this keeps their identity\n// stable so the memoized rows don't re-render on every keystroke/scroll.\nconst editingCellRef = useRef(editingCell);\nuseEffect(() => {\n editingCellRef.current = editingCell;\n}, [editingCell]);\nThe 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.
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.
\nThe 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:
\nactualDuration. 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.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.
\nThere 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.
\nGetting 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.
Scrolling, 1,000-row table:
\n![\"Grouped](\"https://tabularis.dev/img/posts/tabularis-datagrid-scroll-commit-time.svg\")
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:
\n![\"Grouped](\"https://tabularis.dev/img/posts/tabularis-datagrid-cells-per-tick.svg\")
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.
\nTyping is the case I find more satisfying, because it's where the editingCellRef trick earns its keep:
![\"Grouped](\"https://tabularis.dev/img/posts/tabularis-datagrid-typing-per-keystroke.svg\")
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.
\nThe 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.
\nThe cause was one line in the shared Vitest setup. It mocked react-i18next like this:
useTranslation: () => ({\n t: (key: string) => key, // a NEW function on every call\n}),\nA 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.
\nColumn 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.
The checklist I wish I'd had before shipping the janky version, in the order I'd apply it:
\neditingCell/focusedCell state objects into memoized children.measureElement. Measurement is for content that actually varies.DataGrid.tsx and extracted DataGridRow.tsxv0.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.
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.
\nEach 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.
\nThe 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.
\n\nConnection 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.
\nThe workflow got the attention the data model change deserved:
\nclients/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.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.
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.
\n@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.
\n![\"Three](\"https://tabularis.dev/img/tabularis-connections-multiselect.png\")
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:
\nImport 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.
\n![\"Export](\"https://tabularis.dev/img/tabularis-export-connections-modes.png\")
Editing an ENUM cell used to mean remembering the allowed values and typing one exactly. Two PRs fix that end to end.
\nOn 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.
![\"Editing](\"https://tabularis.dev/img/tabularis-enum-dropdown.png\")
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.
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.
position: sticky works unconditionally, and a Sticky column headers toggle in Settings → Appearance keeps the old behavior available.name: type — e.g. id: uuid — on column header hover, read from metadata already in hand, so it costs no backend round-trip.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.@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.
postgre prod finds what you meant, ranked by closeness.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.Fourteen external contributors land in v0.15.0 — the widest tag yet.
\n@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).
\n@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).
\n@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.
\nv0.15.0 is available now. Update via the in-app updater, or download from the releases page.
\n", "image": "https://tabularis.dev/blog/v0150-import-connections-nested-groups-encrypted-exports/opengraph-image.png", "date_published": "2026-07-14T11:00:00", "tags": [ "release", "feature", "bugfix", "connections", "security", "postgres", "mysql", "ui", "ux", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/signpath-code-signing", "url": "https://tabularis.dev/blog/signpath-code-signing", "title": "Tabularis Joins the SignPath.io Open Source Program", "summary": "Tabularis has been accepted into the SignPath.io open source program: a free code signing certificate from the SignPath Foundation for our Windows releases. Over the next few weeks we'll wire signing into the release pipeline — and then the days of telling users to click 'More info → Run anyway' are over.", "content_html": "![\"Tabularis](\"https://tabularis.dev/img/posts/signpath-partnership.svg\")
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".
\nThat 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.
\nSo 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.
\nThe 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.
\nThe 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.
\nFor 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.
\nFor 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.
\nBeing 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:
\nWe'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.
\nOnce the integration lands, if you're on Windows:
\nIf 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.
\nIn 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.
\nTo 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.
\nAnd 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.
\nThe Tabularis Team
\n", "image": "https://tabularis.dev/blog/signpath-code-signing/opengraph-image.png", "date_published": "2026-07-10T09:00:00", "tags": [ "community", "sponsors", "partnership", "open-source", "windows" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0140-stored-routines-connection-windows-destructive-query-guard", "url": "https://tabularis.dev/blog/v0140-stored-routines-connection-windows-destructive-query-guard", "title": "v0.14.0: Stored Routines, Windows of Their Own, and a Guard Against the Unrecoverable", "summary": "v0.14.0 opens the 0.14 line: manage stored procedures and functions from the sidebar, pop a connection into its own window, browse PostgreSQL materialized views, and get a confirmation dialog before a DELETE without a WHERE — plus typo-tolerant fuzzy search everywhere and a stack of Postgres/MySQL correctness fixes.", "content_html": "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.
\nStored 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.
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.DELIMITER-wrapped for MySQL, CREATE OR REPLACE with dollar-quoting for PostgreSQL — so you're editing a valid skeleton, not a blank buffer.SHOW CREATE in a DROP IF EXISTS + DELIMITER block, PostgreSQL reuses pg_get_functiondef.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.
\n\nThe 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.
\nThe 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.
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.
\n\n@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.
\n![\"PostgreSQL](\"https://tabularis.dev/img/posts/tabularis-materialized-views.png\")
Three changes, all from @Davydhh, make finding an object forgiving of how you actually type.
\nThe 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.
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.
![\"A](\"https://tabularis.dev/img/posts/tabularis-total-row-count.png\")
@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.
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.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.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.Most of v0.14.0 is community work again.
\n@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).
\n@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).
\n@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).
\nIf 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.
\n", "image": "https://tabularis.dev/blog/v0140-stored-routines-connection-windows-destructive-query-guard/opengraph-image.png", "date_published": "2026-07-07T15:10:00", "tags": [ "release", "feature", "bugfix", "postgres", "mysql", "ui", "ux", "plugin", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/jetbrains-open-source-program", "url": "https://tabularis.dev/blog/jetbrains-open-source-program", "title": "Tabularis Joins the JetBrains Open Source Program", "summary": "JetBrains accepted Tabularis into its Open Source Support program and handed the maintainers a free All Products Pack — which means the editor we write Tabularis in is now, technically, invested in Tabularis existing.", "content_html": "![\"Tabularis](\"https://tabularis.dev/img/posts/jetbrains-partnership.svg\")
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.
\nIntelliJ 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.
\nThat'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.
\nDigitalOcean'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.
\nWe build Tabularis because we think working with data shouldn't be this painful. Turns out the editor felt the same way about us.
\nThe 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.
\nTo the JetBrains Open Source team specifically, for turning an email exchange into licenses with zero friction, thank you.
\nAnd 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.
\nThe Tabularis Team
\n", "image": "https://tabularis.dev/blog/jetbrains-open-source-program/opengraph-image.png", "date_published": "2026-07-06T09:00:00", "tags": [ "community", "sponsors", "partnership", "open-source" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/nobody-reads-the-sql-anymore", "url": "https://tabularis.dev/blog/nobody-reads-the-sql-anymore", "title": "Nobody Reads the SQL Anymore", "summary": "AI writing our queries is fine, and often better than fine. But reading skill was funded by writing, and now that the writing is gone, the reading is decaying while the volume of SQL entering our codebases goes up. Some thoughts on why SQL is the worst possible language for this to happen to.", "content_html": "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.
\nWhat 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.
\nFor 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.
\nThe 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.
\nWrong 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.
\nSo 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.
\nThe 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.
\nThe 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.
\nThis 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:
\n\n(There is a longer walkthrough in the visual EXPLAIN wiki page.)
\nNote 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.
\nIf 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.
\nThe 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.
\n", "image": "https://tabularis.dev/blog/nobody-reads-the-sql-anymore/opengraph-image.png", "date_published": "2026-07-02T10:33:00", "tags": [ "opinion", "ai", "sql", "performance", "culture" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0134-ssh-security-keys-detachable-results-smarter-editor", "url": "https://tabularis.dev/blog/v0134-ssh-security-keys-detachable-results-smarter-editor", "title": "v0.13.4: Unlock Everything — Hardware Keys, Free-Floating Results, and a Sharper Editor", "summary": "v0.13.4 teaches SSH to prompt — unlock a hardware security key or a passphrase from an in-app dialog — pops query results out into their own window, overhauls SQL autocomplete, and lands three new community drivers (MongoDB, Cloudflare D1, Dameng) alongside a wave of correctness fixes.", "content_html": "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.
\nUntil 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.
\n@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.
\nThe 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.
\n\nThe 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.
\nThe 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.
\n\nThree changes converge to make the editor read your intent better.
\nAutocomplete, 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.
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.
\n![\"Startup](\"https://tabularis.dev/img/posts/tabularis-startup-script.png\")
@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.
The plugin ecosystem keeps growing. Three drivers join the registry this cycle, all community-built and installable from Settings → Plugins:
\ndb.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.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.
\n@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.
A run of fixes that quietly make queries do the right thing:
\nUPDATE/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.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.LIMIT/OFFSET stranded after a trailing semicolon or comment, with hardened scanning for MySQL/MariaDB comment and quoting syntax.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.varchar column is now bound as text, so editing those rows no longer fails a type check.role/aria-sort/keyboard support, the connection-test result is an aria-live region, and sidebar expanders are real buttons.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.Nine external contributors land in v0.13.4 — once again, most of this release is community work.
\n@robertpenz contributed SSH security-key authentication (#262), the feature the whole interactive-prompt flow is built around.
\n@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).
\n@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).
\n@haos666 extended the SQL splitter for Oracle/Dameng blocks (#325), aligned plugin trigger docs (#317), and added the DM (Dameng) driver (#382).
\n@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).
\nIf 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.
\nv0.13.4 is available now. Update via the in-app updater, or download from the releases page.
\n", "image": "https://tabularis.dev/blog/v0134-ssh-security-keys-detachable-results-smarter-editor/opengraph-image.png", "date_published": "2026-06-30T11:00:00", "tags": [ "release", "feature", "bugfix", "ssh", "editor", "notebook", "postgres", "mysql", "plugin", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/managing-tabularis-secrets-with-1password", "url": "https://tabularis.dev/blog/managing-tabularis-secrets-with-1password", "title": "Where Tabularis Keeps Its Secrets: Thank You, 1Password", "summary": "An open-source project accumulates secrets like signing keys, certificates and deploy tokens, and they end up pasted across GitHub repo settings with no real story for rotation or audit. 1Password gives open-source projects a free plan, we qualified for it, and it's good enough to deserve a genuine thank-you. Here's why 1Password is a great secret manager for developers, and how we plan to move Tabularis' CI secrets into one vault and pull them into GitHub Actions with op:// references.", "content_html": "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.
\nTabularis 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.
\nA 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.
\nThe 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.
\nWe didn't want a tidier spreadsheet of secrets. We wanted the pasted-into-GitHub copies to stop being the source of truth at all.
\nHere'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.
\nAnd 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.
\nAnd 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.
\nIt'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?"
\nBut the reason it changed how we work is the developer side.
\n1Password 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.
\nThis is the part every developer should know about, however you came to 1Password.
\n1Password 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\n uses: 1password/load-secrets-action@v2\n with:\n export-env: true\n env:\n OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}\n TAURI_SIGNING_PRIVATE_KEY: op://CI/Tauri/key\n APPLE_CERTIFICATE: op://CI/Apple/cert\n NPM_TOKEN: op://CI/npm/token\n VERCEL_DEPLOY_HOOK: op://CI/Vercel/hook\nRead 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:
\nop:// 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.
\nThe 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.
\n1Password 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.
\nWe 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.
\nAnd 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.
\nHere'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.
\nSo, 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.
\nIf 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.
\nSecrets 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.
\n", "image": "https://tabularis.dev/blog/managing-tabularis-secrets-with-1password/opengraph-image.png", "date_published": "2026-06-29T10:00:00", "tags": [ "security", "devops", "ci", "github-actions", "secrets", "open-source" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/v0133-result-colors-gruvbox-themed-tabs-session-restore", "url": "https://tabularis.dev/blog/v0133-result-colors-gruvbox-themed-tabs-session-restore", "title": "v0.13.3: Color Your Results, Theme Your Tabs, and Pick Up Where You Left Off", "summary": "v0.13.3 is a personalization release: color query results by data type, dress the editor in a new Gruvbox theme, tint the tab bar with each connection's color, reopen the connections you had last session, and toggle CSV headers when you copy — plus a community Informix driver, driver-aware Kubernetes ports, and louder MCP approval alerts.", "content_html": "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.
\nA 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.
\nTurn 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.
\nThe 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.
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.
\nThe 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.
\n\n@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.
\n\nLaunching 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.
\nWhen 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.
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.
\nThe 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.
@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.
SELECT body from a view definition more reliably across the shapes different engines return.Nine external contributors land in v0.13.3 — this release is overwhelmingly community work.
\n@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.
\n@Davydhh (with Davide Cazzetta) tied the editor tab bar and split panels to the active connection's color (#333).
\n@Wilovy09 added the Gruvbox theme (#357) and the CSV-header copy toggle (#356).
\n@Stiwar0098 built the MCP approval attention flow (#311) so a pending approval never goes unnoticed.
\n@metalgrid made the Kubernetes selection dialogs searchable and driver-aware (#319).
\n@danielnuld built and shipped the community IBM Informix driver plugin (#343).
\n@haos666 forwarded external plugin trigger RPCs (#321), and @maacl hardened view-definition parsing (#320).
\n@jing2uo documented Flatpak install via Flatpark (#341).
\nIf 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.
\nv0.13.3 is available now. Update via the in-app updater, or download from the releases page.
\n", "image": "https://tabularis.dev/blog/v0133-result-colors-gruvbox-themed-tabs-session-restore/opengraph-image.png", "date_published": "2026-06-24T10:00:00", "tags": [ "release", "feature", "ui", "ux", "data-grid", "editor", "theme", "kubernetes", "mcp", "plugin", "community" ], "authors": [ { "name": "Andrea Debernardi" } ] }, { "id": "https://tabularis.dev/blog/database-drivers-as-external-processes", "url": "https://tabularis.dev/blog/database-drivers-as-external-processes", "title": "Database drivers as external processes", "summary": "About three months ago I added support for plugin drivers outside the Tabularis process. External drivers are ordinary programs speaking JSON-RPC over stdin/stdout. This is a retrospective on why that design held up, where it leaked, and the credential bug hidden in a HashMap insert.", "content_html": "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.
\nEnough 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.
\nTabularis 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.
\nThere 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.
\nStill, "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.
\nThat 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.
\nDynamic 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.
\nThe 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.
\nWebAssembly. 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.
\nBut 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.
\nI 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.
\nA 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.
\nThis 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:
\nThe 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.
\nFor 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.
\nThe 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)]\npub struct JsonRpcRequest {\n pub jsonrpc: String,\n pub method: String,\n pub params: Value,\n pub id: u64,\n}\n\n#[derive(Serialize, Deserialize, Debug)]\n#[serde(untagged)]\npub enum JsonRpcResponse {\n Success { jsonrpc: String, result: Value, id: u64 },\n Error { jsonrpc: String, error: JsonRpcError, id: u64 },\n}\nLine-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:\n request = json.loads(line)\nand 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.
\nOne 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.
\nThe 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 phrase "JSON-RPC over stdin/stdout" hides the annoying part: there are two byte streams and many callers.
\nWhen 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.
\nSo two things must be true:
\nThe 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.
\nThe caller side looks like this:
\nenum PluginCommand {\n /// Dispatch a request; route the response back via the sender.\n Call(JsonRpcRequest, oneshot::Sender<Result<Value, String>>),\n /// Drop the pending entry for `id` because the caller stopped waiting.\n Cancel(u64),\n}\nThe 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();\n\nloop {\n tokio::select! {\n _ = &mut shutdown_rx => { let _ = child.kill().await; break; }\n\n msg = rx.recv() => match msg {\n Some(PluginCommand::Call(req, resp_tx)) => {\n pending.insert(req.id, resp_tx); // remember who's waiting\n let mut line = serde_json::to_string(&req).unwrap();\n line.push('\\n');\n stdin.write_all(line.as_bytes()).await?; // serialized: only this task writes\n }\n Some(PluginCommand::Cancel(id)) => { pending.remove(&id); }\n None => { let _ = child.kill().await; break; } // all callers gone\n },\n\n line = reader.read_line(&mut buf) => match line {\n Ok(0) => break, // EOF: the plugin died\n Ok(_) => {\n match serde_json::from_str::<JsonRpcResponse>(&buf) {\n Ok(JsonRpcResponse::Success { result, id, .. }) => {\n if let Some(tx) = pending.remove(&id) { let _ = tx.send(Ok(result)); }\n }\n Ok(JsonRpcResponse::Error { error, id, .. }) => {\n if let Some(tx) = pending.remove(&id) { let _ = tx.send(Err(error.message)); }\n }\n Err(e) => log::error!("bad response from plugin: {e}"),\n }\n buf.clear();\n }\n Err(e) => { log::error!("read error: {e}"); break; }\n },\n }\n}\nThis 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.
\nA call becomes:
\nlet (tx, rx) = oneshot::channel();\nself.sender.send(PluginCommand::Call(req, tx)).await?;\nmatch tokio::time::timeout(PLUGIN_CALL_TIMEOUT, rx).await {\n Ok(Ok(result)) => result,\n Ok(Err(_)) => Err("plugin did not respond".into()),\n Err(_) => { /* timed out */ }\n}\nAt this point the design looks clean. In my experience, that is a good time to look for the state the code forgot to model.
\nThe actor loop was the right abstraction, but two bugs fell directly out of its shape during the first rounds of testing.
\nThe 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.
\nBut 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(_) => {\n let _ = self.sender.send(PluginCommand::Cancel(id)).await;\n Err(format!("plugin call '{method}' timed out after {}s", timeout.as_secs()))\n}\nThis 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.
\nThe 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.
\nThe 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:
\n.kill_on_drop(true)\nDropping 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.
\nThis is the bug that changed how I think about the registry.
\nRegistering a driver, built-in or plugin, eventually meant inserting it into a map keyed by driver id:
\nregistry.insert(manifest.id, driver);\nThe 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:
\n{ "id": "mysql" }\nInstall 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.
\nI 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"];\nif BUILTIN_DRIVER_IDS.contains(&config.id.as_str()) {\n return Err(format!(\n "Plugin id '{}' collides with a built-in driver and was refused",\n config.id\n ));\n}\nA plugin that claims a built-in id is refused at load time.
\nThe 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.
\nIt is tempting to call this sandboxing. I have used that word myself, but it needs qualification.
\nRunning a driver as a separate process gives Tabularis two things:
\nIt 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.
\nReal 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.
\nSo 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.
\nThe 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\n .map_err(|e| format!("Failed to finalize plugin installation: {e}"))?;\nThe 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.
\nThree 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.
\nThe 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.
\nBecause 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.
\nThis 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.
\nThe 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.