v0.13.1 is a short follow-up to v0.13.0. Where the last release was about reach — Kubernetes tunnels, a Quick Navigator, MCP into plugin drivers — this one is about correctness: a sweep of features that shipped but quietly didn't work, plus the distribution-level fix Mac users have been asking for since the first DMG.

No new surface area. Several things that were broken, fixed. Four external contributors land in this tag.

Signed and Notarized on macOS

Until now, opening Tabularis on macOS meant a trip through Gatekeeper: the "tabularis cannot be opened because the developer cannot be verified" dialog, or an xattr -c incantation copied from the install docs. The app was never signed, so every Mac treated it as quarantined.

PR #289 wires the release workflow to sign and notarize the macOS build. The .app and .dmg are now signed with a Developer ID Application certificate and submitted to Apple's notarization service during the release build — the App Store Connect API key is decoded from a secret into a temp file on the macOS runners only, and the Apple env vars are inert on the Linux and Windows jobs since Tauri only consumes them when bundling for macOS.

What this means for you: a notarized .dmg opens with the normal "downloaded from the internet" confirmation and nothing more. No xattr, no Privacy & Security override, no "unverified developer" wall. If you've been keeping the workaround command in a note, you can delete it.

Postgres Explain Plan, Now Actually Running

The Visual Explain feature has worked on MySQL, MariaDB, and SQLite since it shipped. On PostgreSQL it failed every single time with error deserializing column 0 — and it turns out it never worked on any Postgres version.

@NewtTheWolf (Dominik Spitzli) and the maintainer track it down in PR #279 (closes #276). EXPLAIN (FORMAT JSON) returns the plan in a single column, and on Postgres that column is typed as json (OID 114), not text. The code read it straight into a String, and tokio-postgres refuses to deserialize a json column into a String — so the call errored out before the plan was ever parsed. This is server-side behavior that's been stable since the FORMAT option landed in PG 9.0, which is why the report reproduced on both PG 16 and PG 18.

The fix reads the column as a serde_json::Value and re-serializes it for the existing parser, with a String fallback for Postgres-compatible engines that hand the plan back as plain text. If you've ever clicked "Explain Plan" on a Postgres connection and gotten an error, that was this.

Pagination That Honors Your OFFSET

When the grid paginates a SELECT, it rewrites the query: it strips your trailing LIMIT/OFFSET, then re-appends LIMIT <fetch> OFFSET <page offset>. The rewriter only read back your LIMIT — the OFFSET was dropped on the floor. On page 1 the per-page offset is 0, so LIMIT 1 OFFSET 1 quietly became LIMIT 1 OFFSET 0, and your OFFSET was ignored.

PR #275 (fixes #273) adds extract_user_offset, mirroring the existing token-aware extract_user_limit so an OFFSET inside an identifier or string literal isn't misread, and build_paginated_query now adds your OFFSET to the per-page offset. Pagination walks the rows you actually asked for. Because all three SQL drivers share build_paginated_query, the fix lands on Postgres, MySQL, and SQLite at once — with regression tests including the exact case from the issue and OFFSET-without-LIMIT on both page 1 and page 2.

There was a folk remedy floating around: appending a trailing -- "fixed" it. The reason is grimly funny — the comment broke the stripper's pattern match, so the appended pagination clause landed on the same line as the -- and got swallowed as a comment, and the database ran your original query verbatim. Correct result, entirely by accident. You don't need the -- anymore.

Connection Strings Stop Silently Failing

Pasting postgresql://user@host/db into the New Connection modal did nothing: no fields populated, no error, and the green success indicator still rendered. The connection-string protocol registry was built only from each driver's id and example, so for PostgreSQL only postgres was ever registered — postgresql:// matched nothing and was silently skipped.

PR #277 (fixes #260) registers well-known scheme aliases — postgresql ↔ postgres, mariadb ↔ mysql, sqlite3 ↔ sqlite — in a second pass that never overrides a protocol a driver registered explicitly, so a dedicated mariadb plugin would still win over the alias. The modal's looksLikeConnectionString pre-filter is gone: input always runs through the parser now, an unrecognized scheme produces a real error (Unsupported database driver: oracle. Supported: mariadb, mysql, postgres, postgresql, sqlite, sqlite3), and the green check only appears when the string actually parsed and populated the form.

MCP: A Parenthesized SELECT Is a Read Again

v0.13.0 rebuilt the MCP safety gates to fail closed on multi-statement payloads. v0.13.1 fixes a false positive in the same classifier, reported and fixed by @ymadd in PR #272.

(SELECT ...) UNION ALL (SELECT ...) — the shape you get when each UNION branch needs its own ORDER BY/LIMIT — starts with a (, so first_keyword returned empty and the query was classified as "unknown". That tripped both the read-only mode and the write-approval gate: a pure read raised a write prompt. The classifier now peels leading ( and whitespace before reading the first keyword, so the inner SELECT is detected — while multi-statement detection still runs first (so (SELECT 1); DROP ... stays "unknown"), and the greedy peel never downgrades a parenthesized write or DDL to "select". Regression tests cover parenthesized UNION, nested and whitespace-padded parens, empty parens (which fail closed), parenthesized DDL/DML, and a writing CTE.

The Grid Stops Freezing on Large JSON

Open a table with a fat JSON column — say a MySQL JSON field holding a megabyte of nested data — and the grid would lock up. Each visible cell tokenized and rendered its full stringified value into thousands of DOM nodes, even though the cell is clipped to about 300px on screen and the full value is already one click away.

@NewtTheWolf (Dominik Spitzli) fixes it in PR #285 (closes #283): a new truncateCellPreview caps the inline preview at 300 characters before tokenization and render in both JsonCell and TextCell, and the native <td> tooltip is capped too. The cap is lossless — the inline expander and the JSON viewer both read the raw row value, not the truncated displayText, so the full content is always reachable. The MySQL and Postgres JSON demos gained a ~1 MB big-JSON row to reproduce the freeze and keep it fixed.

Editor: Theme Isolation and Focus on Open

Two Monaco fixes from the maintainer.

PR #282 (closes #281) stops the editor theme from leaking across instances. Monaco themes are global to the page, so every editor has to agree on the active theme — but each component resolved its own: most used the UI theme, the SQL editor and save-query modal honored the editorTheme override, and the AI explain modal passed a theme id it never registered. Whichever editor mounted last won, so opening the AI explanation modal re-colored every other editor in the app. A new useEditorTheme hook now resolves the effective theme once (the editorTheme override when set, otherwise the UI theme, with a fallback if the override points at a deleted theme), and all eleven Monaco usages route through it.

PR #280 (closes #274) focuses the editor when you open a new console tab — via Ctrl/Cmd+T, the + button, or a Quick Navigator action — so you can start typing immediately. Each tab mounts its own editor instance once, keyed by tab id, so a single editor.focus() covers every creation path. The type check on console tabs avoids stealing focus when a table or query-builder tab opens.

Quieter Keychain, Correct TLS Pools

Two connection-layer fixes that you feel as fewer interruptions and fewer surprises.

Opening the AI settings tab on macOS used to fire the Keychain authorization prompt repeatedly — a single tab open issued eight or more keychain reads, one per provider across SettingsProvider, AiTab, and get_ai_models. @ymadd's PR #269 routes the AI key reads through the CredentialCache that already backs DB and SSH credentials, so the keychain is read at most once per provider per session. As a bonus, get_ai_key now distinguishes a definitive "no entry" from a denied or timed-out prompt, so a transient denial no longer caches a configured key as permanently missing until you restart.

@arsis-dev (Julien Barbe) follows the v0.13.0 MySQL SSL work with the Postgres equivalent in PR #278: the connection pool key now includes PostgreSQL TLS settings, so editing a connection from one SSL mode to another can no longer silently reuse a pool created under the old mode.

Smaller Things

• MiniMax-M3 is the new default (@octo-patch, PR #270) — MiniMax-M3, the new flagship model, is added to ai_models.yaml and placed first, so it's auto-selected when only the MiniMax key is configured. MiniMax-M2.7 and MiniMax-M2.7-highspeed stay available for anyone who prefers the previous generation.

• Big-JSON demo rows (part of PR #285) — the MySQL and Postgres demo seeds gained ~1 MB JSON rows so the grid freeze stays reproducible and regression-tested.

Thanks

Four external contributors land in v0.13.1 — three returning, one new.

@ymadd keeps refining the seams from v0.13.0: the parenthesized-SELECT classifier fix (#272) that removes a false write-prompt without weakening the fail-closed gate, and the AI keychain caching (#269) that finishes wiring the credential cache through the last read path that wasn't using it.

@NewtTheWolf (Dominik Spitzli) returns with two correctness fixes: the grid freeze on large JSON cells (#285) and co-authoring the Postgres Explain Plan fix (#279) — the feature that errored on every Postgres connection it ever ran against.

@arsis-dev (Julien Barbe) follows his v0.13.0 MySQL SSL and Codex work with the PostgreSQL TLS pool-key fix (#278) — closing the same class of "the pool ignored your TLS setting" bug on the other major engine.

@octo-patch is new to the contributor list and brings the MiniMax-M3 default upgrade (#270). Welcome.

If you run Tabularis on macOS and were tired of the Gatekeeper dance, ever clicked "Explain Plan" on Postgres and got an error, lost rows to a paginated query that ignored your OFFSET, pasted a postgresql:// string into a void, watched the grid freeze on a fat JSON column, or got Keychain-prompted on every AI-tab open — this is the upgrade.

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

We're honored to share that Tabularis has been recognized with a Rising Star award by SourceForge.

It's a recognition reserved for a select group of projects out of the more than 500,000 hosted on SourceForge — a platform that sees close to 20 million people a month looking for and building open source software. The award is given for reaching real milestones in downloads and user engagement, which is to say: it's a reflection of you actually using Tabularis.

What it means to us

We don't take this lightly. For a project that's only a few months old, being singled out from half a million others is humbling — and it's not the kind of thing a roadmap or a feature list earns on its own. It's earned by people who downloaded the app, kept it open, filed an issue, wrote a plugin, translated a string, or simply told a colleague it was worth a look.

So the honest version of "we won an award" is: you won it for us. Every star, every release downloaded, every Discord question — that's the engagement SourceForge measured. We just got to put our name on it.

Onward

The badge now lives on our SourceForge project page, and you'll see it pop up across our channels. But the part that matters isn't the badge — it's the trajectory it marks. A database client that respects your machine, your credentials, and your time is resonating with people, and that's exactly the signal we needed to keep building.

Thank you to SourceForge, and thank you to everyone who got us here.

The Tabularis Team

You download a SQL client because you need to look at a table. You open it, and the first screen is a signup form. The tool that is about to hold your production credentials wants an email address before it will show you a query editor.

This has somehow become normal, and I think it's worth saying plainly: it shouldn't be.

A database client is the most credential-dense application on a developer's machine. It holds connection strings to production, SSH keys, tunnel configs, sometimes the only working path into a customer's VPC. Editors hold code, which is usually in a repo anyway. Browsers hold sessions you can revoke. A database client holds the keys to the data itself. Of all the tools on your machine, it is the one with the strongest case for never talking to anyone but you and your database.

The trend is going the other way. Accounts, cloud workspaces, query history synced to someone else's backend, AI features that route your schema through the vendor's proxy so usage can be metered.

None of this happens because vendors are malicious. It happens because of how these tools are funded. A VC-backed dev tool needs monthly active users, and you can't count users you can't see, so you add an account. Collaboration features need a backend, so queries move to the cloud. AI is the monetization story, so it goes through the vendor's keys instead of yours. Each decision is individually reasonable. The sum is a desktop app whose useful life is coupled to the runway of the company behind it.

And you find out what that coupling costs on the day the company changes course. Arctype was a genuinely good client. It got acquired, and the product was sunset — along with the workspaces where people's queries lived. That's not an edge case. That's the expected lifecycle of an account-based tool: the account is the leash, and eventually somebody pulls it.

Tabularis is built on the opposite bet, so let me be concrete about what "local-first" actually means here, because the term gets thrown around a lot:

No account. There is no signup, no license activation, no "continue with Google". You download a binary and connect to a database. That's the whole onboarding.

Secrets live in your OS keychain, not in our anything. Passwords, SSH passphrases, API keys — they go into macOS Keychain, Windows Credential Manager, or libsecret on Linux, under the service name tabularis. You can inspect every entry with security find-generic-password or secret-tool and verify it yourself. If you'd rather a password never persist at all, untick one checkbox and it lives in process memory for the session and dies with it. The details are in the security docs.

Everything non-secret is a plain file. Connection profiles, SSH configs, preferences, saved queries: JSON on your disk, in a directory you can grep, diff, back up, and put in your dotfiles. The AI audit log is one JSON line per query, locally. There is no export feature because there is nothing to export from — you already have the files.

AI is bring-your-own-key, and optional. If you turn the assistant on, your key goes in the keychain and calls go directly to the provider you chose. Point it at Ollama and nothing leaves your machine at all. We never see your schema, your queries, or your prompts, because there is no "we" in the request path.

In the interest of honesty, here is the complete list of network calls Tabularis makes on its own: the updater checks GitHub releases for a new version. That's it. No telemetry SDK, no crash reporter phoning home, no anonymous usage pings. You can confirm this the boring way — the code is open, grep it.

This costs us real things, and I'd rather name them than pretend otherwise. We don't have sync, so your connections don't follow you between machines unless you copy the config files yourself. We don't have shared team workspaces. And because there is no telemetry, I genuinely don't know how many people use Tabularis or which features they touch — I find out when someone opens an issue, which makes every bug report worth more and every silent user invisible. Those are the terms of the trade, and I think they're good terms, but they are a trade.

The deeper reason I think this matters goes beyond privacy. A database client is plumbing. Plumbing should be boring, durable, and indifferent to the fortunes of whoever installed it. When your queries are files and your secrets are in the OS keychain, switching away from Tabularis costs you nothing — and that's exactly the point. A tool you can leave at any moment has to earn its place every day. A tool that holds your account, your history, and your team's saved queries only has to be too annoying to migrate from.

I know which kind of pressure produces better software.

"Sign in to continue" was a fine default for a SaaS dashboard. For the tool holding your production credentials, it never was one.

v0.13.0 follows v0.12.0 with a cycle about reach: reaching a database that lives inside a Kubernetes cluster without kubectl port-forward in a forgotten terminal tab, reaching any table in any schema with two keystrokes, and letting MCP agents reach the connections that run through plugin drivers — while closing the one hole that let a stacked query reach further than it should have.

Six external contributors land in this tag — three of them new — plus a first-time co-author.

Kubernetes Port-Forward Tunnels

If your database lives inside a Kubernetes cluster, the ritual is familiar: kubectl port-forward svc/postgres 5433:5432 in a terminal you must remember to keep open, then a connection in your database client pointed at 127.0.0.1:5433 that silently breaks the moment that terminal dies.

@metalgrid (Iskren Hadzhinedev) — new to the contributor list — ships PR #246, which makes Kubernetes a first-class transport option alongside SSH tunnels. The connection modal grows a Kubernetes tab: pick a kubectl context, a namespace, a resource (service or pod), and a container port — each dropdown discovered live from your kubeconfig and cascading into the next.

How it works:

• Tabularis runs kubectl port-forward as a managed child process, binds a local ephemeral port, and points the database driver at it — same pattern as the SSH tunnel, no port to pick manually.
• Tunnels are reused across connections to the same resource (keyed by context/namespace/resource/port), with health checks and lifecycle management.
• Saved K8s configurations persist as reusable profiles in k8s_connections.json — the same pattern as SSH profiles — and round-trip through connection Export / Import.
• Connections with a tunnel get a blue K8s badge on the Connections page and in the sidebar.
• K8s and SSH are mutually exclusive on a connection — enabling one disables the other.

The only requirements are kubectl in your $PATH and a valid kubeconfig. The PR lands with 18 new Rust tests and 24 new TypeScript tests, and the tunnel expansion is wired through every database command path — including MCP, so an agent can query a cluster-resident database through the same tunnel you use.

Full reference in the wiki: Kubernetes Tunneling.

If you've been keeping a kubectl port-forward alive in tmux just to browse a staging database, this is the upgrade.

Quick Navigator: Cmd+P for Your Schema

Every editor since Sublime has had a "jump to anything" key. Your database client now does too. PR #252 — co-authored with lecndu, taking inspiration from Beekeeper Studio's Quick Search — adds a Quick Navigator overlay on Cmd+P / Ctrl+P:

• Type to filter tables, views, routines, and triggers of the active connection.
• All databases and schemas configured on the connection are indexed in the background when the overlay opens — a multi-database MySQL connection or a multi-schema Postgres one is searched whole, with results grouped under per-database/schema headers.
• Hover any result for quick actions: Inspect Structure, New Console, Generate SQL, Count Rows, Run Query, and Copy Name — scoped to what makes sense for each object type.
• Pick a result and the sidebar expands and scrolls to the table — including databases that were collapsed and hadn't loaded their table list yet.
• The shortcut is customizable in Settings → Keyboard Shortcuts under Navigation.

The follow-up commits are where it got interesting: on a connection with hundreds of tables, selecting a result used to freeze the UI, because every sidebar table item re-rendered on every render. SidebarTableItem is now memoized with a comparator that only re-renders the two items whose active-state actually changed, collapsed databases auto-expand and lazy-load when they become active, and the scroll-into-view retries across animation frames until the asynchronously-loaded item actually exists in the DOM. Large-schema sidebars get faster even if you never press Cmd+P.

MCP: Plugin Drivers, a Closed Bypass, and Codex

Three PRs this cycle touch the MCP server — two from @ymadd, who keeps pulling on threads until the whole seam is rebuilt.

Plugin-driven connections now work over MCP

The MCP server hardcoded dispatch for mysql/postgres/sqlite, so every connection running through a plugin driver — Hacker News, Redis, anything from the registry — failed with Unsupported driver. PR #256 (closes #255) routes the schema resource, list_tables, describe_table, run_query, and the pre-flight EXPLAIN through the shared driver registry — the same path the GUI uses — and registers built-in plus installed plugin drivers when the --mcp subprocess starts.

Reaching plugins from a headless subprocess surfaced a pile of hardening, all shipped in the same PR: plugin RPC calls are bounded by timeouts so a wedged plugin can't block the request loop forever, plugin children are killed instead of orphaned when the subprocess exits, plugins claiming a built-in driver id are refused, resources/read resolves through the keychain/SSH-aware path, and the --mcp mode finally gets a logger (stderr only) so plugin-load errors are visible.

The approval/read-only bypass, closed

PR #261 fixes the kind of bug a safety feature exists to not have. The read-only and approval gates classified a query by its leading keyword — so a stacked payload like SELECT 1; DROP TABLE users was tagged as a clean read and sailed past both gates. Separately, an approver could edit an approved SELECT into a DELETE in the approval modal, and the edit was executed without being re-classified.

The classifier now fails closed on multi-statement payloads: string literals are stripped under both the SQL-standard ('') and MySQL backslash-escape (\') readings, and a ; followed by more SQL under either reading trips the gate — so a payload can't hide a separator by exploiting whichever dialect the classifier doesn't assume. And the approver-edited query is re-classified and re-checked against read-only before execution, with the audit record updated to the effective query.

The execution layer's prepared-statement protocol already rejected most stacked queries, but the classifier is the documented fail-closed contract — this restores it. If you point agents at anything you care about, update.

Codex joins the client list

@arsis-dev (Julien Barbe) — new to the contributor list — adds Codex as an MCP install target in PR #264. The MCP integration page already auto-detects Claude Desktop, Claude Code, Cursor, Windsurf, and Antigravity; Codex now appears alongside them, wired through codex mcp add tabularis -- <tabularis> --mcp, with the Codex-specific manual command shown in the setup UI.

Generate SQL Grows DML Tabs

The Generate SQL tool in the table context menu used to do one thing: show the CREATE TABLE statement. @capvalen (Infocat) — new to the contributor list — extends it in PR #259 with a tab per statement kind:

• SELECT * and SELECT [fields] — ready-made queries against the table.
• UPDATE and DELETE — templates with every column laid out.
• A Run in Console button that opens the generated statement in a new editor tab.

The generated UPDATE uses :named bind parameters derived from the column names instead of bare ? placeholders, so the statement binds correctly the moment it lands in the query editor. Translations ship for all eight locales in the same PR.

Display Timezone: Timestamps Where You Are

@ymadd's third PR of the cycle, #251 (closes #249 and #250), starts as a bug fix and ends as a setting.

The bug: the AI activity log rendered raw UTC timestamps — events table, sessions list, detail modal, and the CSV / JSON / notebook exports all showed a time that wasn't yours.

The setting: Settings → Localization → Timezone, a searchable picker of IANA zones with current UTC-offset labels, defaulting to Auto (your OS zone). The selected zone drives every UI timestamp — activity log, query history, favorites — and the backend exports via chrono-tz. Query-history date grouping classifies the today/yesterday/older boundaries in the same zone, so the group headers and the per-row times can never disagree. Even the default export filename derives its date from the configured zone.

Query History That Heals Itself

PR #253 chases a "history doesn't work anymore" report on macOS down to a file ending in valid JSON followed by 46 bytes of leftover tail — concurrent addEntry calls (one per statement in multi-statement scripts) raced on the file write, and a shorter write over a longer one left trailing garbage. Once corrupt, the parse failure silently short-circuited both reads and writes: the History panel went permanently empty and nothing new was ever recorded.

Three fixes ship together:

• Self-healing reads — a corrupt file is renamed aside as <id>.json.corrupt-<timestamp> and history starts fresh, instead of staying mute forever.
• Atomic writes — write to a temp file, then rename onto the target, so a concurrent or crashed write can never leave a half-written file.
• Per-connection serialization — an async mutex orders read-modify-write sequences so concurrent entries can't lose updates.

If a corrupt file was recovered, the History sidebar shows a dismissible banner with the backup path — so you know what happened and where your data went.

Failed Schema Loads Now Say So

When get_schemas failed — bad search path, permissions, a flaky tunnel — the sidebar rendered TABLES (0) / VIEWS (0) and nothing else. The connection looked open (the connection test runs on a separate code path), so it appeared connected while showing nothing, with no hint anything went wrong.

@verbaux (Nikolay Zhuravlev) fixes the silence in PR #242: the sidebar now shows a "Failed to load schemas" message with a Retry button, a two-line brief of the actual error, and a collapsible Details section holding the full raw error with a copy button. For Postgres the brief is the human-readable part of the driver error, with the debug dump tucked into the expanded box. The new strings ship in all eight locales.

MySQL SSL Mode, Actually Honored

@arsis-dev's second PR of the cycle, #263, follows up the original MySQL SSL support from #133. Two related gaps: the test-connection path built its URL without passing the selected ssl_mode to the driver — so a connection configured with ssl_mode=disabled still attempted TLS in the test path — and the connection pool key ignored TLS settings entirely, so editing a connection from one SSL mode to another could silently reuse a cached pool created under the old mode. Both are fixed, with regression tests on the URL builder and the pool key.

Smaller Things

• PostgreSQL FK metadata via pg_catalog (@m-tonon, PR #245) — the information_schema query that loaded foreign-key metadata sometimes missed constraints, and when it did the FK buttons just disappeared from the grid. The query now reads pg_constraint / pg_attribute / pg_class / pg_namespace directly, correctly handling composite keys, cross-schema references, and update/delete rules — with an integration test covering all of it.
• Mouse scroll no longer re-renders the selection (commit 12f45865) — scrolling the results with the wheel was churning selectedIndex re-renders for no reason.
• Plugin data folder paths corrected (commit 358514ed) — plugin data directories now resolve to the right place.

Thanks

Six external contributors land in v0.13.0 — three new, three returning — plus a first-time co-author.

@ymadd ships three PRs this cycle, and they form an arc: the registry dispatch that lets MCP reach plugin drivers (#256), the fail-closed classifier that makes sure that expanded reach stays gated (#261), and the display-timezone work (#251) that turns a timestamp bug into a proper Localization setting. After the SQL splitter in v0.12.0, ymadd has now rebuilt both of the places where Tabularis decides what a piece of SQL is — in the editor and in the safety gates.

@metalgrid (Iskren Hadzhinedev) is new to the contributor list and lands the Kubernetes tunnel feature (#246) — a genuinely vertical piece of work spanning a new Rust tunnel module, Tauri commands, the connection modal with cascading kubectl discovery, badges, export/import, and 42 new tests. First PR, first-class transport. Welcome.

@arsis-dev (Julien Barbe) is also new and ships two precise PRs: the Codex MCP integration (#264) and the MySQL SSL mode fix (#263) — the latter with exactly the kind of issue-archaeology (checking #122, #133, #166, #167, #190 for overlap) that makes a fix easy to merge. Welcome.

@capvalen (Infocat) is new as well, and extends the Generate SQL tool with DML tabs and Run in Console (#259) — including translations for all eight locales. Welcome.

@verbaux (Nikolay Zhuravlev) follows the Russian locale from v0.12.0 with the schema-load error surfacing (#242) — taking a "shows nothing, says nothing" failure and giving it a message, a Retry button, and copyable details, in every locale.

@m-tonon (Matheus Tonon) returns with the pg_catalog FK metadata fix (#245) — following the Related Records panel from v0.12.0 with the fix that keeps the FK buttons it depends on from vanishing.

And lecndu co-authors the Quick Navigator (#252) — a first contribution from inside a pair, which counts.

If you want to reach a database inside a Kubernetes cluster without babysitting a port-forward, jump to any table in any schema with Cmd+P, point an MCP agent at a plugin-driven connection and trust the gates it passes through, generate an UPDATE with named bind params in two clicks, read timestamps in your own timezone, or never again watch your query history go silently mute — this is the upgrade.

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

v0.12.0 is a broad follow-up to v0.11.0. Three new external contributors land in this tag — alongside three returning ones — and the cycle leans further into the parts of a database client that you feel every day: telling two MySQL connections apart at a glance, looking at the row a foreign key points at without losing the one you're on, and a SQL splitter that actually understands what DELIMITER // means in MySQL and what $body$ means in PostgreSQL.

If v0.11.0 was about what happens inside a cell — JSON, long text, triggers — v0.12.0 is about what happens around it: the connection, the relationship, the grid, the driver, the language.

Per-Connection Accent Color and Icon

Issue #189 was simple to state: "I have a MySQL local and a MySQL prod sitting one above the other in the sidebar, they share the dolphin and they share the orange, and I have hit Enter on the wrong one." Up to v0.11.0 every connection rendered with its driver's default icon and its driver's default color — Postgres elephant blue, MySQL dolphin orange, SQLite cylinder grey — and there was no way to override either.

@NewtTheWolf shipped the fix in PR #241.

The New Connection modal grows an Appearance section at the bottom of the General tab with two pickers:

• Accent color — a 12-swatch curated palette plus a custom hex input.
• Icon — four mutually-exclusive tabs:
  • Default keeps the driver's manifest icon.
  • Pack is a curated set of 30 icons (cubes, clouds, layers, shields, leaves, branches…).
  • Emoji takes a single emoji of your choice.
  • Image uploads a PNG / JPG / WebP / SVG (max 512 KB). Uploads are scanned for the usual SVG nasties (<script>, javascript: URLs, on*= event handlers).

When no override is set, the resolvers fall back to the driver's default — so existing connections keep behaving exactly as before, and you never see a "blank" connection. The override is persisted alongside the rest of the profile in connections.json and round-trips through Export / Import like every other field.

The custom accent and icon are wired into every place a connection appears today: the connection list on the Connections page, the sidebar entry once the connection is open, and the Visual Explain modal's connection chip. Tab headers and the status bar will pick up the same accent automatically once those components exist.

Full reference in the wiki: Connections → Per-Connection Appearance.

Foreign Keys: Now You Can Peek Without Leaving

v0.11.0 made foreign keys navigable — hover an FK cell, click the ↗, the referenced row opens in a tab pre-filtered with WHERE ref_col = value. That's the right pattern when you want to go to the related record. It's the wrong pattern when you just want to check what user_id = 123 resolves to before continuing to edit the row you're already on.

@m-tonon — new to the contributor list — closes #228 with PR #230 by adding the second affordance: an inline Related Records Panel that slides up from the bottom of the data grid.

Click any FK value (or pick Show related record from the cell context menu) and the panel opens below the current grid, keeping the parent table visible and interactive above it. Clicking a different FK in the parent grid swaps the panel content in place — no close-then-reopen. The panel is drag-resizable, so a wide referenced row can claim the height it needs.

If you decide you do want to navigate after all, the panel has an Open in tab button that hands off to the existing FK navigation path — same WHERE clause, same tab-reuse behavior.

V1 keeps the same scope boundary as the navigation pattern: single-column foreign keys only. Composite constraints and cross-schema navigation are noted as follow-ups.

If you live in tables with FK-heavy schemas — orders → users → addresses, line items → products → categories — and you've been tab-hopping just to look at something, this is the upgrade.

Full reference in the wiki: Data Grid → Related Records Panel.

A SQL Splitter We Actually Own

The statement splitter is the bit of plumbing between "what's in the editor" and "what gets sent to the database". Up to v0.11.0 we delegated it to an external library, which has served well enough — but the cycle landed two reports that pointed at the same root cause. #223 was the visible one: a SELECT preceded by a -- header comment block showed up in the run-selection dropdown as multiple entries — the comment lines and the SELECT each got their own row, even though only the SELECT was executable.

@ymadd replaces the lot with a first-party splitter in PR #225. What it handles natively:

• String literals — '...', \' escapes, E'...' extended, dollar-quoted PostgreSQL strings ($tag$...$tag$), MySQL backticks, MSSQL bracket identifiers.
• Comments — -- line, /* */ block (with PostgreSQL nested-comment support), and the MySQL conditional /*! ... */ form — which is emitted as its own statement so mysqldump output (with version-gated SET statements wrapped in conditional comments) executes correctly when pasted into the editor.
• Delimiters — ;, the DELIMITER directive for MySQL stored routines, and GO for MSSQL.

A new per-driver dialect field flows from the connection straight into every run-query, explain, and dropdown path in the editor, so MySQL backticks, MSSQL [...], and PostgreSQL dollar-quoting are each parsed by the rules the driver actually uses.

The comment-fold behavior also changes what you see in the dropdown: a header -- block followed by a SELECT is now a single entry, and a trailing comment after a statement folds back into that statement. The dropdown only shows runnable statements.

Oracle's / block terminator, Firebird PSQL BEGIN...END, and MSSQL's adaptive GO split are explicitly out of scope for v1 and noted as follow-ups.

This is the kind of work — invisible until you look at the dropdown — that you only realize was sitting under everything else once it's gone.

Snappier Queries, Right Out of the Gate

@thomaswasle ships PR #216, which is the kind of fix that doesn't show up in a screenshot but shows up in your hands.

Two independent issues were adding latency to every single query execution. First, every query was re-reading the connections file from disk to look up which database it was talking to — fast, but it adds up over a working day, and over a remote keychain on a laptop you can feel it. The new connection cache reads the file once on first use and serves every subsequent lookup from memory. Any time you save or edit a connection, the cache is dropped so the next read picks up the change. There's no behavior to learn — queries just feel less laggy.

Second, the result grid was waiting on column and foreign-key metadata before showing the rows. After each query returned, the grid stayed blank until two extra metadata round-trips finished — sometimes adding 100–500 ms of perceived latency on top of a query that was actually already done. The result now renders the moment the data arrives; metadata loads in the background and the FK indicators light up a beat later.

If you've ever run a fast SELECT and watched the grid sit blank for half a second, this is the upgrade.

The same cycle also ships PR #239 — the sidebar now refreshes after CREATE TABLE, so a freshly created table actually shows up where you expect it without a manual refresh.

BIGINT Precision: Stop Losing Snowflake IDs

@NewtTheWolf closes #210 with PR #220, and it's the kind of fix that's only obvious in retrospect.

BIGINT values bigger than about 9 quadrillion — which includes every snowflake ID, every Discord ID, and most Twitter/X IDs — were silently losing their last digits on read. So 844197938335842304 came back from the database as 844197938335842300. The grid then sent that rounded value back on UPDATE / DELETE, which either matched the wrong row or matched nothing at all.

The fix preserves the exact value end-to-end on read and on write-back. Wired through:

• MySQL — BIGINT and BIGINT UNSIGNED.
• PostgreSQL — BIGINT (INT8), XID8, and MONEY.
• SQLite — INTEGER.

Sort and filter are unaffected because both run server-side against the native BIGINT column. Small IDs (anything that fits in JavaScript's safe range) are handled exactly as before — no change in the common case, no impact on row counts.

The same PR adds a bigint_demo seed table to the MySQL and Postgres init scripts in the Docker Compose demo, mirroring the text_demo / json_demo pattern from v0.11.0. Point Tabularis at the demo and you have something to reproduce the original bug against (before this fix) and confirm it's gone (after).

If you've been editing rows in a Discord-style table and watching the wrong ones change, this is the upgrade.

PostgreSQL TLS Modes, Aligned with libpq

#209 was a precise report: Tabularis' PostgreSQL SSL modes (disable, allow, prefer, require) all behaved like they demanded a valid CA — which broke connection to AWS RDS instances with self-signed certs that work fine in psql and DBeaver with sslmode=require. The expected behavior, the one every other Postgres client ships, is:

• require — force encryption, but do not require certificate validation.
• verify-ca — encryption plus validate the CA.
• verify-full — encryption plus validate the CA plus verify the hostname.

@VincentZhangy — new to the contributor list — lands the alignment in PR #211.

require no longer demands a CA. The clear security progression — require → verify-ca → verify-full — that other PostgreSQL clients ship is now what Tabularis ships too.

If you've been pointing Tabularis at RDS with a self-signed cert and bouncing off "needs CA certificate", this is the upgrade.

Full reference in the wiki: Connections → TLS & CA Certificates.

Delete Rows with the Delete or Backspace Key

@thomaswasle closes #218 with PR #221. Pressing Delete or Backspace with one or more rows selected now marks them for deletion — the same behavior already available from the right-click context menu, just reachable from the keyboard.

The shortcut fires only when rows are selected, no cell is being edited, and the grid is not read-only — so Backspace inside an active cell editor still does what Backspace should do.

Русский

PR #229 from @verbaux — new to the contributor list — adds Russian as the eighth supported UI language. Русский is registered in the language picker and surfaces in Settings → Appearance → Language.

The locale list is now English, Italian, Spanish, French, German, Chinese, Japanese, and Russian.

The same PR also fixes a long-standing pluralization bug in the tab switcher. The English UI used to render "1 tabs" for a single tab because the count was concatenated outside the translation call. Counts are now passed into the translation, with proper plural forms per language — including Russian's four CLDR forms (1 → вкладка, 2–4 → вкладки, 5–20 → вкладок).

A handful of UI surfaces remain not-yet-wired-to-i18n and render in English: the Visual Query Builder canvas, the AI Query modal, and the mini result grid. All noted in the PR; an opportunity for a follow-up contribution.

A New macOS Dock Icon

The old macOS dock icon was a bare isometric cube on a transparent background. On modern macOS (Tahoe and friends) that looked out of place next to system apps that all sit inside a proper squircle — the cube floated, had no glass treatment, and on light wallpapers the dark edges fought the dock.

PR #217 replaces icon.icns with a Tahoe-style design: a proper Apple squircle, a light glass background with a top sheen, very subtle teal and violet auroras in opposite corners picking up the cube's own gradient colors, and the cube logo centered with a soft drop shadow.

Windows .ico and Linux PNGs are untouched; iOS / Android folders unchanged.

Smaller Things

A long tail of papercuts gets cleaned up in this cycle:

• Ctrl+Enter runs the active tab, not the last opened one (@thomaswasle, PR #240) — with multiple Console tabs open, Ctrl+Enter used to always execute the query in whichever tab was opened most recently, regardless of which one was actually focused. It now fires the query in the active tab, as it always should have.
• Pagination works on SELECTs with leading SQL comments (@ymadd, PR #213) — a SELECT preceded by a -- header block silently lost its pagination bar, so 500-row results looked like a fixed slice with no way to advance.
• PostgreSQL filters honor case-sensitive column names (@m-tonon, PR #232) — a column named userId was getting lowercased to userid by the filter bar, and the filter silently matched nothing. PostgreSQL columns now get properly quoted; MySQL/SQLite paths are unchanged.
• Save Query modal doesn't override the editor theme (@debba, PR #248) — opening the Save Query modal silently swapped the theme of every SQL editor in the app to the UI theme. Only visible if you'd picked a different editor theme in Settings → Appearance, which is exactly the configuration that setting exists for.
• Settings toggle knob centered (@verbaux, PR #219) — the knob in the Settings toggles was landing slightly below the center of the track on macOS. Same size, colors, and keyboard behavior, just visually correct now.
• CI: manual prereleases from fork PRs (@NewtTheWolf, PR #206) — the release workflow now accepts a PR number, tag name, and prerelease flag as manual inputs, so a maintainer can build a prerelease directly from a fork PR without merging it. Tags containing a - automatically flag the release as prerelease, and AUR / Snap / Winget downstream workflows skip prereleases so beta channels stay out of system package managers.

Thanks

Six external contributors land in v0.12.0. Three of them are new — Matheus, Nikolay, and vlor — and three continue the streak from v0.11.0.

@NewtTheWolf (Dominik Spitzli) ships three PRs this cycle: the per-connection appearance feature (#241) — a real piece of vertical work spanning the modal, the four-tab icon picker, the upload pipeline with SVG sanitization, and the wiring into every place a connection appears — the BIGINT precision fix (#220) that catches a class of silent corruption nobody had named yet but everyone had hit, and the CI workflow change (#206) that makes building prereleases from fork PRs a one-click maintainer action. Three substantial PRs in one tag, all merged without changes.

@thomaswasle (Thomas Müller-Wasle) also ships three: the per-query latency fix (#216) which lifts a real ms-level cost out of every command and unblocks the grid from waiting on metadata, the Delete / Backspace keyboard shortcut for row deletion (#221), and the Ctrl+Enter active-tab fix (#240) — a precisely-traced bug through how editor commands get bound. Thomas has now shipped triggers in v0.11.0, SQL INSERT export + cell selection in v0.10.2, and three more in v0.12.0; the diagnoses keep getting sharper.

@ymadd lands the first-party SQL splitter (#225) — a properly substantial replacement of the parsing layer with per-driver dialect support — and the leading-comment pagination fix (#213). Together with the multi-statement batch fix in v0.11.0, ymadd has now rewritten large parts of how Tabularis decides "is this one statement or many" — twice over.

@m-tonon (Matheus Tonon) is new to the contributor list and lands two PRs the same cycle. The Related Records Panel (#230) is the kind of feature you only build if you've used the tool enough to know that "navigate to it" and "look at it" are different verbs; the Postgres case-sensitive filter fix (#232) is the kind of bug you only diagnose if you've actually been hit by it on your own database. Welcome.

@verbaux (Nikolay Zhuravlev) is also new, and ships the Russian translation (#229) — full parity with the English locale, a Russian README, and a properly thorough fix to the tab-counter pluralization that was rendering "1 tabs" in English. The same PR also notices the SettingToggle knob being off-center on macOS and fixes it in #219 — exactly the kind of cross-cutting "while I'm here" attention that turns a translation PR into something more.

@VincentZhangy (vlor) rounds out the contributor list with PR #211, aligning the PostgreSQL SSL modes with the behavior psql and DBeaver users already expect.

If you want to tell two MySQL connections apart at a glance, peek at the row behind a foreign key without leaving the one you're on, paste a mysqldump output and see one statement per /*! ... */ block, run a query and see the grid the instant the data arrives, edit by a snowflake ID without losing the last three digits, connect to RDS with sslmode=require and have it work, hit Delete on a selected row, or read the UI in Русский — this is the upgrade.

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

We have some news we're genuinely excited to share: DigitalOcean has welcomed Tabularis into its Open Source Credits Program.

For a project that started four months ago as one person's late-night frustration with database tooling, having a cloud provider of DigitalOcean's stature put their name behind us is more than a sponsorship line on a website. It's a signal — to the contributors who've shown up, to the users who've trusted Tabularis with their workflows, and to anyone still figuring out whether this project is worth their time — that what we're building here matters.

Why this partnership feels right

DigitalOcean built its reputation by betting on developers before it was obvious. Simple pricing, documentation people actually wanted to read, a community-first posture in a market that mostly didn't have one. The kind of company that, if you've ever shipped a side project to a server you paid for yourself, you've probably already met.

Tabularis was built in the same spirit. A tool by developers, for developers. Free, open, and stubbornly independent. The fit isn't an accident.

What the Open Source Credits Program does, in plain terms: DigitalOcean provides yearly cloud credits to open source projects whose work they want to see continue. No equity, no contracts, no pressure to pivot the roadmap. Just resources, in the form of the same infrastructure their paying customers use, given to maintainers who would otherwise be funding it out of pocket.

For a community-driven project still funded out of pocket, that math changes things.

What this unlocks for Tabularis

The credits are earmarked for the infrastructure behind the upcoming Tabularis plugin registry — the next step for the ecosystem the community has been building one plugin at a time.

Without going into the technical weeds (there's a full roadmap page for anyone who wants the details), the registry is the piece that lets plugin authors publish on their own, lets users see what's actually being used, and lets the ecosystem grow without a maintainer sitting in the middle of every release.

It's the difference between "a list of plugins I review by hand" and "an actual platform other people can build on." That's a step Tabularis needs to take, and the DigitalOcean credits make it possible to take it properly, not as a side project squeezed in between bug fixes.

A thank you, and what comes next

To the team at DigitalOcean and the people running the Open Source Credits Program: thank you. Genuinely. Backing a four-month-old open source project takes a kind of long-term thinking that's rare, and we don't take it lightly.

To the Tabularis community: this partnership belongs to you too. Every star, every PR, every plugin, every translation, every Discord question answered — all of it is what made Tabularis the kind of project a program like this wanted to back. We're not where we are by accident.

We'll be telling this story across our channels in the coming days — if you want to help amplify it, you can find us tagging @digitalocean and using #DOforOpenSource.

Four months ago, Tabularis was a single binary one person pushed to GitHub at midnight. Today it's a community, a growing plugin ecosystem, and a project DigitalOcean wants to put their name behind. None of that draws a straight line on a chart — every star, every PR, every Discord thread, every link shared in a Slack channel pulled the curve upward. This partnership is one of the moments where that work becomes visible.

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

The Tabularis Team

v0.11.0 is the fattest tag since v0.10.0 — and it's almost entirely external work. Four community contributors land in this cycle (two of them new), shipping the JSON/JSONB viewer that has been a top request since #24, a trigger manager that lights up the third major database object after tables and routines, a Japanese translation, and a reliability fix to the driver layer that you only notice the day it isn't there.

If v0.10.x was about getting connections to behave, v0.11.0 is about what happens once you're inside.

JSON / JSONB Cells, Now With a Real Editor

The most-requested data-grid issue since the project started (#24) was simple to state and unpleasant to live without: "Let me look at this JSONB column." Up to v0.10.3 a jsonb cell rendered as one long string of escaped braces, and editing it meant typing valid JSON into a textarea that did nothing to help.

@NewtTheWolf shipped the fix in PR #181 — and it's the kind of feature you can tell was reverse-engineered from how DBeaver's Value Panel and DataGrip's Value Editor actually feel to use, not just what they look like.

A JSON / JSONB cell now gets three affordances:

• A chevron on the row that expands an inline editor pane below it — Monaco running in JSON mode with syntax highlighting, bracket matching, and a manual Diff toggle that compares the original cell value against the pending edit (unified by default, with a one-click switch to side-by-side).
• A braces icon that opens the cell in a standalone Tauri window dedicated to the value. Multiple cells can have their viewers open at the same time — each window keeps its own session and remembers its bounds — so comparing two rows is now "click, click" instead of "copy, paste into a different tab, come back, repeat".
• A double-click that opens the viewer window directly in edit mode, for when the chevron isn't where your hand wants to go.

Edits round-trip through the grid's pending-changes machinery rather than going straight to the database — you can review the unified diff, decide you don't like it, close the viewer, hit Submit on the row when you do. Two viewer windows open on the same connection don't interfere with each other; session state lives in a Rust Mutex<HashMap> keyed by ULID, and saves flow back to the grid via a Tauri event.

On the PostgreSQL side the driver finally binds json / jsonb natively through tokio-postgres' with-serde_json-1 impl. INSERTs and UPDATEs of object/array values that used to round-trip through a string cast now go straight through as typed parameters; the same code path is used by inline edits, the viewer save, and the row editor sidebar. Scalar JSON values (a bare 42, "hello", true) are JSON-encoded before binding, so you can't accidentally feed Postgres a malformed payload from the grid.

The same PR also lands a per-connection toggle that scans plain text columns for JSON-shaped content and routes them through the same cell renderer. It's per-connection on purpose — you almost always want it on for your audit-log database and off for the one where TEXT means "free-form prose".

Full reference in the wiki: Data Grid → JSON & long text cells.

Long Text and LONGTEXT, Same Treatment

The week after #181 merged, @NewtTheWolf extended the same chevron + Monaco + diff pattern to plain string columns in PR #208, closing #207.

Any text-like column whose value is longer than 80 characters or contains a newline — TEXT, LONGTEXT, VARCHAR(500), VARCHAR(MAX) — now renders with the same chevron. Expand the row and you get Monaco in plaintext mode, with the same Diff and Side-by-side toggles. Markdown articles, code snippets, SQL queries you stored as text, multi-paragraph notes: all of it readable inline, all of it diffable before commit. The row-editor sidebar in the right-hand panel got the same upgrade — a long field there now opens in a Monaco-backed input instead of a textarea, with the diff toggle right there, and the editor pane itself is drag-resizable so you can give a long markdown article the height it deserves.

There is no separate viewer window for plain text — by design. Text cells aren't compared as often as JSON, and the chevron + inline expansion was the entry point that mattered. JSON cells keep both the chevron and the dedicated-window path.

Trigger Management

Stored procedures and functions have been browsable for a while. Triggers — the third major database object you reach for in real schemas — were the visible gap. PR #183 from @thomaswasle closes it across all three built-in drivers.

The Explorer sidebar grows a Triggers accordion under every schema (PostgreSQL), database (MySQL multi-db), and in the flat layout for MySQL single-db / SQLite. Each entry shows the trigger name, a timing/event badge (BEFORE INSERT, AFTER UPDATE, INSTEAD OF DELETE…), and a tooltip with the target table. There's a filter field at the top of the accordion, matching the existing table-filter pattern.

Right-click a trigger for the actions you'd expect:

• View Definition — opens the trigger SQL in a read-only editor tab (Run and Explain Plan are hidden, since you're looking at DDL).
• Edit — opens the Trigger Editor Modal in Guided mode: name, table, timing (BEFORE / AFTER / INSTEAD OF), event checkboxes (INSERT / UPDATE / DELETE / TRUNCATE), a body editor, and a live SQL preview. A Raw SQL tab is always available for hand-edits. Editing a trigger warns that it's executed as drop + recreate and runs the two statements atomically.

• Create Trigger from the table or accordion header — same modal, blank slate.
• Drop Trigger — with the standard confirmation.

The Rust side is the part you can tell required a database driver author to write. Each engine has its own quirks:

• PostgreSQL aggregates multi-event triggers via string_agg on information_schema.triggers (a single trigger can fire on INSERT OR UPDATE, and the catalog stores those as separate rows). Definitions come from pg_get_triggerdef.
• MySQL uses sqlx::raw_sql for trigger DDL to bypass server error 1295 (the prepared-statement protocol doesn't accept CREATE TRIGGER / DROP TRIGGER). The connection pool is also switched to the correct database before CREATE TRIGGER, which is the kind of detail that only shows up in a multi-database setup.
• SQLite parses sqlite_master.sql to extract the timing and event metadata that the catalog itself doesn't decompose.

Plugin drivers that don't implement triggers degrade gracefully — get_triggers returns an empty list rather than failing the whole schema load.

The new wiki page covers the lot: Triggers.

Foreign Keys: Click to Navigate

Hover an FK cell in the result grid; a small ↗ icon appears on the right. Click it and the referenced table opens in a tab, already filtered to the row you came from. Right-click the same cell and the context menu's first entry is "Open referenced row in <table>". Same pattern TablePlus and Postico use, finally in Tabularis (PR #197).

fetchPkColumn now fetches columns and foreign keys in parallel when a tab opens, and the FK list lives on the tab so subsequent clicks don't re-query. The WHERE fragment is built with the existing quoteIdentifier(driver) helper — backticks for MySQL/MariaDB, double-quotes elsewhere — with number / bigint / boolean / string formatting matching what the row-copy SQL INSERT format does. Numeric-looking strings are quoted unless the source column reports a numeric type, which guards against bigints that some drivers ship as JS strings.

If the referenced table is already open as a tab, that tab is reused — the WHERE filter is overwritten and the query re-runs.

V1 sticks to single-column FKs. Composite constraints and cross-schema navigation are noted in the PR and on the roadmap.

Enter Accepts Autocomplete Suggestions

A small but breaking default change (#186, PR #194): when the autocomplete dropdown is open in the SQL editor, Enter now accepts the highlighted suggestion instead of inserting a newline. The behavior every other Monaco-based editor ships by default, finally lined up.

If you preferred the previous behavior, Settings → Editor → Accept suggestion on Enter turns it back off. The setting is honored across every editor surface — main SQL tabs, notebook cells, the trigger editor's Raw SQL tab.

The bump from 0.10.x to 0.11.0 comes from this change — it's the kind of default switch that warrants a minor bump rather than slipping it into a patch.

Multi-Statement Scripts Now Share a Connection

@ymadd — who landed the Notebook database-selector portal fix in v0.10.3 — shipped a much deeper driver fix in PR #200, closing #199.

Up to v0.10.3, when you ran a multi-statement script through Run All the editor fanned out via Promise.allSettled — each statement acquired its own pooled connection. The result was that cross-statement session state silently broke: SET @var := … in statement 1 was invisible to statement 2, LAST_INSERT_ID() / LASTVAL() returned 0 against the wrong session, explicit BEGIN / COMMIT blocks didn't form a transaction, temporary tables couldn't be read, and PREPARE / EXECUTE pairs failed. The behavior was "execute everything fast" instead of "execute everything like mysql CLI / psql / DBeaver does".

The fix is a new execute_batch method on the DatabaseDriver trait. The three built-in drivers override it to acquire one pooled connection and run every statement on it in order. The frontend's runMultipleQueries is replaced with a single invoke("execute_query_batch"); the whole batch shares one cancellation handle. Plugin drivers fall back to a default impl that preserves ordering without session-state continuity — the explicit trade-off so plugins don't break.

The same PR fixes a long-standing reporting bug: the three built-in drivers were hardcoding affected_rows: 0. INSERTs, UPDATEs, and DELETEs now report the real count execute() returned. There are seven new integration tests pinning the behavior down.

This is the kind of work that's invisible until the moment it isn't.

A Bigger Cancellation Fix, Too

@ymadd also lands PR #203, closing #201.

QueryCancellationState stored one AbortHandle per connection_id. So the second execute_query / execute_query_batch / explain_query_plan against the same connection overwrote the previous handle, and cancel_query could only stop the most recently registered one. The earlier Tokio task kept running on its pooled connection until completion.

The fix switches the slot to a Vec<Arc<AbortHandle>>, prunes finished handles on register, removes specific handles by Arc identity on unregister, and drains the whole slot on cancel. Five new unit tests and a fresh integration test (two SELECT SLEEP(5) on the same connection, single cancel, both report JoinError::is_cancelled()) lock the behavior in. The same fix landed in the export / dump / import path in the follow-up commit, so the cancellation story is consistent across every long-running operation.

If you've ever hit Cancel on a heavy query and watched the dot keep spinning on the connection, this is the upgrade.

日本語

PR #202, also from @ymadd, adds a full Japanese translation. Every key in en.json has a counterpart in ja.json, including the strings that landed this cycle — the trigger management UI (sidebar.*, triggers.*), the connection export/import flow, the Discord callout, and the new "Accept suggestion on Enter" setting. Pick 日本語 from Settings → Appearance → Language to switch.

This brings the locale list to English, Italian, Spanish, French, German, Chinese, and Japanese.

To make this kind of contribution easier going forward, this release also lands a built-in Import / Export translations flow in the Locales settings. Open a single JSON file, edit it offline (or in the AI tool of your choice), import it back in. The export warning makes clear that any unsaved app-level setting will be merged with whatever your file contains, so accidental key loss is avoidable.

Smaller Things

• MCP config path on Windows (@kennelken, PR #204) — the directories crate's config_dir() resolves to %AppData%\Roaming\tabularis\config on Windows, but the app stores connections.json one directory up at %AppData%\Roaming\tabularis. The MCP server was looking in the nested folder, finding nothing, and shipping an empty connections list to the client. The fix uses the parent of the default config_dir() on Windows, so MCP discovery matches the rest of the app. If you're on Windows and the MCP server reported zero connections, this is the upgrade.
• SQL string color across themes (@thomaswasle, PR #192) — Monaco's SQL tokenizer sets tokenPostfix: ".sql", so single-quoted SQL strings tokenize as string.sql, not string. Monaco 0.55 doesn't reliably fall back, which left SQL strings rendering as a barely-readable dark red on every dark theme (Dracula was the worst offender). Every bundled theme JSON now has an explicit string.sql rule using the same color as the generic string rule; the three built-in themes get the rule injected by generateMonacoTheme().
• "New Console" in sidebar context menus (#187, PR #188) — right-click a database for New Console to open a blank SQL editor scoped to that database; right-click a table for New Console to open one pre-filled with SELECT * FROM table_name. Faster than opening the editor and navigating the schema selector when you know exactly what you want to query.
• Export through SSH tunnels (PR #185) — query export over an SSH-tunneled connection was using the connection's raw host/port instead of the tunnel's ephemeral local port, so exports against tunneled databases would fail or — worse — hit the wrong server. Export now expands SSH params through the same helper the editor uses.
• Docker Compose demo environment — demo/docker-compose.yml brings up a PostgreSQL with tabularis_demo and analytics_demo databases, plus a MySQL with tabularis_demo, all seeded with customers, departments, employees, orders, order_items, products, plus the new json_demo and text_demo tables that exercise the JSON and long-text cells covered above. One docker compose up -d and you have something to point Tabularis at.

Thanks

Four external contributors land in v0.11.0. This is the largest contributor-driven release Tabularis has shipped to date.

@NewtTheWolf lands the headline feature in two PRs and ships the seed data that makes it testable. PR #181 is a properly substantial piece of work — a new Rust module for the viewer windows, ULID-keyed sessions, the Postgres native binding path, the per-connection JSON-detect flag, every locale string, the test plan written out — and it lands ahead of the request queue rather than chasing it. PR #208 extends the same pattern to text cells the week after, with the side-by-side diff toggle as the right generalization across both. Dominik has now shipped the JSON viewer, the long-text viewer, the Firestore plugin in v0.10.3, the Discord release template, and the seed data behind half of this changelog — and is still finding obvious-in-hindsight gaps in the UX faster than I am.

@thomaswasle ships the trigger manager in PR #183 — a full vertical slice from the Driver trait down through three driver-specific implementations, a Tauri command surface, a sidebar accordion, a guided modal, and the read-only definition view in the editor — and quietly fixes the SQL string color across every Monaco theme in PR #192. The trigger PR is the kind of contribution that requires you to have read enough of the codebase to know where the Driver trait lives, what the sidebar item conventions are, and how the editor's read-only-tab flag interacts with the existing run-button rendering. Thomas has now shipped triggers in 0.11.0 and SQL INSERT export + cell selection in 0.10.2 — pattern-matching the work to "the parts of Tabularis that are obviously a database tool".

@ymadd turns into a regular contributor in this cycle. PR #200 is the kind of fix that requires you to have used the editor enough to notice that SET @var := doesn't survive across statements, and then to track it through Promise.allSettled into the Rust driver trait. The PR ships with seven new integration tests, the MySQL error 1295 workaround for DDL through prepared statements, and a real-vs-zero affected_rows fix folded into the same diff. PR #203 takes the cancellation slot from "one handle per connection, last write wins" to a properly per-task Vec<Arc<AbortHandle>>. PR #202 is the entire Japanese translation, with every recently-added string already covered. Three PRs in one cycle, every one of them is the kind you accept without changes.

@kennelken (Sergey Tarasenko) is new to the contributor list, and lands a fix in PR #204 that the Windows MCP users have been hitting silently — empty connections list, no error, just a server that acts like nothing's configured. The diagnosis took working backwards from "MCP returns nothing" through the directories crate's platform-specific behavior; the fix is one branch in get_app_config_dir. Welcome.

If you live in JSONB columns, work across long text fields, want triggers managed without leaving the app, prefer your autocomplete to accept on Enter, run multi-statement scripts that need to share a session, are on Windows and connecting through MCP, or have been waiting for 日本語 — this is the upgrade.

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

Arpit Bhayani’s “Defensive Databases for Agentic AI Systems” makes the same argument very well, and extends it from a more technical angle — broken assumptions about deterministic callers, intentional writes and brief connections, with concrete patterns like idempotency keys, role-per-agent connection pools, soft deletes and query tagging.

For two decades the database has been able to outsource trust to the application layer. The app authenticated users, sanitized inputs, enforced business rules, and the DB just executed whatever came through the connection pool. That worked because the caller was almost always software written by someone, reviewed by someone, and shipped on a release train.

Agents don't fit that picture.

Once an LLM with tool access holds a live connection to your production database, the assumptions behind the application-as-perimeter model stop being true:

• Connections aren't short-lived anymore. A tool-using agent can keep a session open across a long reasoning loop, with the SQL emerging one token at a time.
• The caller isn't deterministic. Two runs of the same prompt can produce different queries. Sometimes very different ones.
• Writes aren't intentional in the way a human commit is. An agent will issue an UPDATE without a WHERE clause if its plan says so.
• Failures don't surface loudly. An exception that would have woken up a developer can be absorbed by the model and rationalized into the next step.

Short version: the application layer used to be the boundary. With agents in the loop, it isn't. The database has to defend itself again.

That's most of the reason the MCP safety work in Tabularis looks the way it does. The MCP server is the actual surface where an agent and a real database meet, and that surface needs guarantees the model can't talk its way around.

A few of the pieces we shipped:

Read-only connections. Not "the agent promises not to write" — the connection itself rejects writes. If the agent's plan calls for an UPDATE on a read-only connection, it fails at the boundary, before the row is gone. The classifier strips strings, comments and quoted identifiers before scanning the keyword, and treats anything ambiguous as a write. Fail-closed is the safer default when the alternative is a corrupted production table.

Approval gates with pre-flight EXPLAIN. Before a write (or a heavy read) actually runs, we surface the statement together with the planner's view of it for human approval. EXPLAIN turns out to be the right unit here: it shows the model's intent translated into what the database will really do, and that's often where the divergence between "what the agent said" and "what would have happened" shows up. You can fix the WHERE clause inside the modal, then approve. Both the original and the edited query are kept, linked by the same approval id.

Query audit logs. Every statement an agent issues is stored locally — one line of JSON per call — with its prompt context, the connection it used, the rows it touched, and the outcome. When something goes wrong (and with agents, something goes wrong) the audit log is how you reconstruct what actually happened, not what the model claims it did.

Full MCP activity tracing. Tool calls, results, errors, timing: the whole exchange between the agent and Tabularis is observable. Events can be flat-filtered or auto-grouped into sessions by inactivity gaps, and any session can be exported as a SQL notebook you can replay, diff against another run, or attach to a PR. When a model starts improvising, you can usually pinpoint the exact tool call where it happened.

None of these ideas are new. DBAs have wanted half of them for years. We could get away without them because the application layer was a decent proxy for "someone reasoned about this before it ran."

That proxy is gone. Putting the guarantees back inside the database itself is cheap compared to finding out, after the fact, that an agent dropped a column at 3am because its context window was full of stale documentation.

"Trust the application layer" was a fine default. With agents in the loop, it stops being one.

v0.10.3 is a community-heavy follow-up to v0.10.2. Three external contributors land in this tag — two of them new — and a fourth ships a Firestore driver to the plugin registry on the same day. The headline change is being able to move your connections between machines without rebuilding them by hand; the rest is the kind of resilience work that's invisible until the day it isn't.

If v0.10.2 was about getting connections to work where they should, v0.10.3 is about getting them — and the editor that consumes them — to travel.

Connection Export and Import

Up to v0.10.2, the only way to move your connection profiles between two installations was to copy connections.json, copy ssh_connections.json, then re-enter every password by hand on the new machine because the secrets live in the OS keychain and the JSON files don't include them. Doable, but painful past a handful of connections.

PRs #175 and #176 — both originating in @zhaopengme's combined PR #172, split into two focused PRs for review — replace that with a single round-trip through a JSON file.

The Connections page gets Export and Import buttons in the toolbar. Export walks every connection group, saved database connection, and SSH profile, pulls the relevant password out of the OS keychain (database password, SSH password, SSH key passphrase), and writes the lot into a JSON file. Import takes that file back, merges it with the existing config, writes the embedded passwords back into the keychain, and persists the connection files — so the imported entries behave exactly like manually-created ones. A fresh install also picks up an Import button on the empty-state view, so you have a way in before you've created the first profile.

The trade-off is unavoidable: the exported JSON contains plaintext passwords. Keep the file the way you'd keep a .env. If you only need to move connection shape and not credentials, you can strip the password fields before importing — Import writes back whatever passwords are present and leaves the keychain alone for empty ones.

The same PR also lands password visibility toggles on every password input across the New Connection, SSH, and AI provider modals. Small ergonomic win when you're pasting a password and want to see whether the paste landed correctly.

Full reference in the wiki: Connections → Export / Import.

An Editor Error Boundary

@saurabh500 reported and fixed a sharp edge in #173: some drivers return columns with no name. The two examples in the wild are SQL Server's SELECT @@VERSION and PostgreSQL's SELECT 1 AS "". The data grid couldn't render the empty column header — the whole editor pane blanked out instead, with no result, no error message, and no recovery short of reopening the tab.

The fix is small: empty column names are handled internally without breaking the grid. Drivers that return real names are unaffected.

That bug surfaced something else — there was no top-level error boundary around the editor. So one driver edge case could take down the whole workspace. PR #173 closes the immediate crash, and a follow-up commit wraps the editor surface in an Editor Error Boundary with a fallback UI ("Editor crashed — try again / report"), translated across English, Italian, Spanish, French, German, and Chinese.

Together they're the difference between "your query crashed the app" and "your query crashed; here's the trace and a reload button."

Saurabh also lands a small refactor in #174 — not user-visible, but the kind of housekeeping you only do when you've started reading the code seriously.

Notebook Database Selector, Now Through a Portal

The scrollable database selector that landed in v0.10.1 (#160) had a clipping bug nobody hit until a Notebook cell with a tall dropdown showed up. Short cells — no result yet, the last cell in a notebook, anything with collapsed neighbors — cut off the lower half of the dropdown, and the inner scrollbar became unreachable.

New contributor @ymadd shipped the fix in PR #178. The dropdown now renders on top of the page rather than inside the cell, so it can't be clipped regardless of how tall or short its container is. Behavior across scroll and resize is consistent with the rest of the app, and the existing styling, height cap, click-outside-to-close, and "show only when more than one database" condition are all preserved.

If you have a MySQL host with many schemas and you've been bouncing off the Notebook DB selector since v0.10.1, this is the upgrade.

A New Plugin: Firestore (Community)

The plugin ecosystem picks up a sixth third-party driver, and the first one to target a managed NoSQL platform: firestore-tabularis by @NewtTheWolf, connecting Tabularis to Google Cloud Firestore. It's now published to the plugin registry, so it's a one-click install from the in-app Plugin Manager.

The mapping is the interesting part. Firestore is collection/document, not table/row, and it has no schema. The plugin fits Firestore into Tabularis' relational worldview by listing root collections as tables and sampling N documents per collection (default 50) to infer column types. Inferred schemas are cached per process; an optional set of JSON override files lets you pin required-ness, correct types, hide fields, or declare extras per project/database.

What works today (tagged v0.1.0):

• Connection lifecycle — install from the in-app Plugin Manager, then connect like any other driver.
• Schema discovery — root collections appear as tables, columns are inferred from document samples, and the ER diagram is populated with inferred foreign keys.
• A SQL subset for queries — SELECT with WHERE, AND / OR / NOT, IN, array contains, ordering, LIMIT / OFFSET, and cursor pagination.
• EXPLAIN mapped to Firestore's plan endpoint, with documents returned, documents scanned, index used, and execution time.
• CRUD via the data grid context menu (insert, update, delete rows, rename document IDs).
• The full Google auth chain — service account JSON, Application Default Credentials, GOOGLE_APPLICATION_CREDENTIALS, or the Firestore emulator host.

What's not in v0.1.0 yet: writing through raw SQL statements (INSERT INTO, UPDATE, DELETE) — those return a friendly redirect pointing you at the grid actions instead, with SQL-side DML on the plugin's roadmap. DDL is intentionally absent because Firestore is schemaless. Subcollections, multi-database, and live mode are listed as future phases.

The plugin is hosted on Codeberg (NewtTheWolf/firestore-tabularis) with binaries mirrored for installation from the registry. If you've been waiting to point Tabularis at a Firestore project, this is the upgrade — and the plugin is open for issues on Codeberg.

A Discord Community Channel

Tabularis now has a dedicated Discord channel for the community — a place to ask questions, share what you're building, and follow what's coming next.

To make it findable from inside the app, a small tile appears in the sidebar the first time you launch this version, inviting you to join the server. Dismiss it once and it's gone for good. Every Discord link across the app, the README, and the contributing guide now points to the same invite, so wherever you click, you land in the same room.

Come say hi.

Join the Discord →

Smaller Things

A handful of polish items round out the release:

• Connections page — import on empty state. The empty Connections view ("No saved connections yet") used to offer only a "New Connection" button. It now also offers an Import button, so a fresh install with an exported payload in hand is one click from being usable.

Thanks

Three external contributors land in v0.10.3, and one community plugin ships alongside it.

@zhaopengme is new to the contributor list and lands the headline feature. The original PR #172 bundled both password visibility toggles and connection export/import; splitting it into #175 and #176 for separate review was friction we asked for and you accommodated without pushback — thank you.

@saurabh500 continues a streak that started outside this window: two PRs in this tag (#173 and #174), one bug fix sharp enough to expose a missing error boundary, one small refactor that's the kind of thing you only do when you've started reading the code seriously.

@ymadd is also new — PR #178 is a textbook portal-rendering fix, with the test plan, the reproduction conditions, and the cross-reference to the existing pattern already written. The kind of PR that's just done when it lands.

@NewtTheWolf ships firestore-tabularis the same day as the release — a full Firestore driver written from scratch against the plugin protocol, with schema inference, a SELECT parser, EXPLAIN plan extraction, schema overrides, and the entire Google auth chain wired up. The plugin protocol exists so this kind of thing can happen without us touching the core, and it's still satisfying when it does.

If you've been moving between machines and rebuilding your connection list by hand, hitting unnamed columns in SQL Server or Postgres, bouncing off the Notebook DB selector, or waiting to point Tabularis at Firestore — this is the upgrade.

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

v0.10.2 is another short follow-up to v0.10.1. Four days after the patch, three users opened three independent issues — two against the connection layer, one against an SSH modal that suddenly stopped opening — and a handful of data grid features were already on their way in. v0.10.2 closes the issues, lands the features, and goes out the door.

If v0.10.1 was about smoothing the AI safety release, v0.10.2 is about getting connections to work where they should and making the data grid a little more useful once you're inside.

Postgres on AWS RDS Works now

This is the headline fix, and the kind of bug that's particularly painful: "Test connection" succeeds, schemas load, then 30 seconds later the health check pings the pool, the TLS handshake fails, and the UI tells you the connection was lost. Reproducible across restarts. Indistinguishable from "the database is down" if you don't read the logs.

@benedettoraviotta reported it in #166 and shipped the fix in PR #167. The diagnosis took some patience: tokio_postgres only surfaces error performing TLS handshake and hides the underlying cause. Walking source() on the error chain exposes the real story — on macOS, Secure Transport applies a strict id-kp-serverAuth Extended Key Usage check to user-supplied root anchors and rejects valid CAs (the AWS RDS bundle is a textbook example) with "The extended key usage is not valid". Independently, the system keychain doesn't trust the regional Amazon RDS root CAs, so platform verification fails with errSecNotTrusted (-67843).

The fix replaces postgres-native-tls with tokio-postgres-rustls for the deadpool path, switches the trust source to rustls-platform-verifier, and starts honoring params.ssl_ca. RDS users can now paste https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem into the connection's CA Certificate field and connect cleanly. MySQL/sqlx remains on native-tls — the bug was specific to the Postgres pool path and there was no reason to churn the rest.

The RDS bundle is intentionally not vendored. AWS rotates these CAs every one to three years; a vendored copy would silently break released apps the moment the next rotation lands and the user is on an old binary. Distributors who want out-of-the-box RDS support can pull the bundle at packaging time (Dockerfile RUN, build script, etc.) and ship it alongside the app.

If you've been bouncing off RDS since upgrading to v0.10.x, this is the upgrade.

Cell-Level Selection and Copy

Up to v0.10.1, the data grid let you select rows. You could shift-click a range, ctrl-click to add to the set, and copy the lot to the clipboard. What you couldn't do was select a single cell — the whole row came along, every time.

PR #161 from @thomaswasle adds cell-level selection. Click any cell and it gets a focused outline; the row checkbox stays untouched. Cmd/Ctrl+C copies just the cell value, formatted using the same null/length/type rules the row copy uses. A new "Copy cell" entry appears in the right-click menu for the moments when keyboard isn't faster.

The two interaction modes don't fight each other: clicking a row checkbox clears the cell focus, clicking a cell clears the row selection. So copy with an active cell focus copies the cell, copy with selected rows copies the rows. The behavior you'd expect, just without the surprises.

SQL INSERT as a Copy Format

The flip side of "I want this row" is "I want to put this row somewhere else". CSV, TSV, and JSON copy formats already covered most exports. PR #168, also from @thomaswasle, adds SQL INSERT as a fourth option.

Set it once in Settings → General → Copy format, then copy any selected rows from the data grid. You get back a sequence of INSERT INTO \table` (`col1`, `col2`, …) VALUES (…);statements, one per line. NULLs render asNULL, booleans as TRUE/FALSE`, numbers unquoted, strings single-quoted with single quotes doubled-up — the basics that make the output paste-able into another shell or query window without hand-editing.

It complements the duplicate-row context menu action that landed in v0.10.1: that one stays in-grid and inserts the row right where it sits, this one ships the row out as text.

Postgres Boolean Submit Error

@simonwang1024 reported in #155 that editing a value in a Postgres result grid and pressing Submit returned an error. The path involved was the binding module that landed in v0.10.1: when the data grid sends an edited value back, it serializes the cell as a string, and the binding layer maps it to a typed parameter based on the column type.

For boolean columns, the column type was correctly identified, but the value still arrived as a string ("true", "false", "t", "f", "1", "0") and the bind was rejected because Postgres expects a real bool. The fix coerces the common string forms to a bool before binding, with 105 lines of new tests covering the cases that come out of the data grid, JSON inputs, and SQL editor parameters. Edits to boolean columns now go through cleanly.

Smaller Things

Two community-reported regressions round out the release, both from @MischaKr:

• MySQL passwordless connections (#164, fixed in #169). After the v0.10.1 connection URL refactor, MySQL connections without a password were producing URLs with a trailing colon (user:@host), which some servers reject and some accept silently with surprising behavior. The fix simply omits the password segment entirely when the field is empty, so the URL ends up as user@host. The connection-URL test fixture got an updated assertion to lock the behavior in.
• Manage SSH Connections button (#163, fixed in commit 9eb48e2). The button rendered, but clicking it did nothing — the SSH connections modal was opening underneath another overlay and getting click-blocked. A z-index bump and a backdrop-blur tweak put it on top where it belongs.

Thanks

Three external contributors land in v0.10.2 and each fixed a different layer of the stack. @benedettoraviotta for the AWS RDS TLS investigation — diagnosing a "TLS handshake failed" through two layers of error wrapping, two macOS-specific quirks, and two TLS stacks isn't trivial work, and the PR came in with the rustls swap, the platform verifier, the ssl_ca honoring, and the call to not vendor the RDS bundle. That last call is the one I'd have got wrong. @thomaswasle for two more data grid PRs — cell selection and SQL INSERT export — both small in diff and immediately useful. @simonwang1024 and @MischaKr for the bug reports that kept the release honest. Two of Mischa's three issues this cycle turned into shipped fixes; the third (#164, MySQL passwordless) became the first commit on the way to this tag.

If you connect to AWS RDS, edit boolean columns, or use MySQL without a password, this is the upgrade.

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

v0.10.1 is a short follow-up to v0.10.0. The AI safety release shipped a week ago, and a few bug reports came back almost the same day. v0.10.1 closes those, lands three new context menu actions in the data grid, and rewires how the PostgreSQL driver binds parameters under the hood.

If v0.10.0 was about giving the agent a safer door into your database, v0.10.1 is about smoothing out the things you bumped into while using it.

A Sneaky LIMIT Bug

This is the headline fix, and it's the kind of bug that's invisible until the day it isn't.

@midasism reported and fixed it in PR #154. When Tabularis paginates a SELECT in the data grid, it strips the user's LIMIT / OFFSET (if any), wraps the query, and re-applies its own pagination. The two helpers responsible — strip_limit_offset and extract_user_limit — used a naive rfind("LIMIT") against the raw SQL string.

That works right up until you query a table whose name happens to contain the substring limit (tapp_appointment_message_event_limit was the real-world example), or a string literal that mentions the word, or a quoted identifier. The pagination wrapper would clip the query in the wrong place and you'd end up with corrupted SQL or duplicated LIMIT clauses.

The fix replaces the raw string search with a small SQL tokenizer (tokenize_sql) that treats single-quoted strings, double-quoted identifiers, backtick-quoted identifiers, and parenthesized groups as opaque tokens. strip_limit_offset and extract_user_limit now scan backward over those tokens, so only standalone LIMIT / OFFSET keywords match. 11 new test cases cover table names containing limit, quoted identifiers, string literals with SQL keywords, and subqueries.

The MCP run_query tool got a small upgrade in the same PR: it now accepts an optional limit parameter (default 100), and respects user LIMIT clauses inside the SQL when present. Agents that want the full result can pass an explicit value; the default keeps them from accidentally pulling a million rows into context.

If you ran into this bug after upgrading to v0.10.0, the upgrade to v0.10.1 is the fix.

Three New Data Grid Actions

Three back-to-back PRs from @thomaswasle extend the data grid context menu — the same one that already handles single-row delete and copy-as.

Multi-row deletion (PR #158). Select multiple rows in the grid, right-click, and delete them in one shot instead of repeating the action row by row. The deletion goes through the same path as single-row delete — same confirmation, same reload behavior — so there's nothing new to learn.

Duplicate row (PR #159). Right-click any row and copy it as a new INSERT, with the primary key cleared (or auto-incremented, depending on the column). Useful when you're seeding data, building a quick test fixture, or making a small variation of an existing record without writing the SQL by hand.

Insert current time (also PR #159). On any timestamp/datetime cell, the context menu now offers an "insert current time" action that drops NOW() (or the driver's equivalent) into the cell. Small ergonomic win when you're filling rows manually.

All three actions are translated across English, Italian, Spanish, French, German, and Chinese.

Parameterized Bindings for PostgreSQL

The PostgreSQL driver had grown a sprawl of inline string-to-SQL conversions in mod.rs — formatting numbers, escaping strings, converting JSON arrays to PostgreSQL array literals, handling UUIDs and blobs. It worked, but each call site had to remember the right escape rules, and edge cases were easy to miss.

PR #156 extracts all of that into a dedicated binding module. Values are bound as proper tokio-postgres parameters ($1, $2, ...) instead of being interpolated into the SQL string. Numbers are cast through bigint / double precision so the bind succeeds against int2 / int4 / int8 / real columns; UUID strings are detected and bound as the Uuid type so PostgreSQL receives the matching OID; arrays go through a JSON-to-array literal conversion that handles nested types; blobs respect the configured max_blob_size.

This is the kind of refactor where the user-facing diff is "nothing changed". 208 lines of new tests and a 350-line trim in mod.rs argue otherwise: edits that touch numbers, UUIDs, arrays, or binary columns now go through one well-tested code path instead of seven slightly-different ones. The kind of work that's worth doing once, before it bites again.

Smaller Things

A handful of polish items round out the release:

• Scrollable database dropdowns (#160, thomaswasle). The Editor and Notebook database selectors used to render a flat dropdown that grew indefinitely. Past 10 databases it became unusable. Now the menu caps its visible height and scrolls.
• Connection-modal placeholders (#157, thomaswasle). Empty fields in the New Connection modal were rendered with a value-styled appearance, which made them look pre-filled when they weren't. Now an empty field looks empty.
• Semver-aware "What's New". The in-app changelog and "What's New" dialog used naive string comparison to figure out which release notes to surface. That worked fine until a 0.10.x versus 0.9.x comparison came around, where "0.10" is lexically less than "0.9". A new versionCompare utility (with tests) compares releases as proper semver and the changelog parser now also accepts level-one headings, so the right release notes show up after every upgrade.
• Visual Query Builder polish. The graph view gained a small embedded result grid, a schema metadata cache hook, and a dagre-based auto-layout pass. Useful when you're iterating on a builder query and don't want to switch to the editor tab to see the rows.

Thanks

A patch release is mostly bug reports turning into PRs and PRs turning into a tag. @midasism for finding and fixing the LIMIT bug — that one was easy to ship and hard to spot, and you nailed both. @thomaswasle for four PRs in a single window, all small, all good, all making the app a little more pleasant to use.

If you've been holding off because of a bug v0.10.0 left behind, this is the upgrade.

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

Tabularis has been MCP-native since v0.9.9: Claude Desktop, Claude Code, Cursor, Windsurf and Antigravity can all talk to your saved connections through the tabularis --mcp server, with schema reading, table description and query execution. The catch up to now is that once you set MCP up, the agent had the same level of access you do.

v0.10.0 is the release that closes that gap. Three features land together, all visible at the first launch after the upgrade:

• An audit log of every MCP tool call, stored locally and queryable from a new Settings panel.
• Read-only mode to block writes per-connection or globally.
• Approval gates that pause writes and require user confirmation, with a pre-flight EXPLAIN plan rendered inside the modal.

Two smaller features come along for the ride: exporting an entire AI session as a SQL notebook, and jumping from any audit row into Visual Explain.

1. The audit log

Every MCP tool call is now recorded as one line of JSON in ~/.config/tabularis/ai_activity.jsonl:

{"id":"4f9b…","sessionId":"a8c1…","timestamp":"2026-04-24T14:02:11Z",
 "tool":"run_query","connectionId":"prod-pg","connectionName":"prod",
 "query":"SELECT count(*) FROM orders","queryKind":"select",
 "durationMs":42,"status":"success","rows":1,
 "clientHint":"claude-desktop","approvalId":null}

A new MCP → Activity tab in the app reads this file (the plug icon in the sidebar opens the MCP page). It has two sub-tabs:

• Events: flat, filterable, exportable to CSV or JSON.
• Sessions: events auto-grouped by 10-minute inactivity gaps, with a per-session Export as Notebook button.

The Sessions sub-tab is probably the most useful of the two. One click and you get a valid .tabularis-notebook file you can replay or attach to a PR:

• A markdown header with session metadata (client, connections, time range, event count).
• One SQL cell per run_query, in chronological order.
• Cell names taken from the first -- comment in the query when present.
• Markdown context cells for the list_tables and describe_table calls so the agent's investigation trail stays intact.

Results aren't embedded; opening the notebook re-executes the cells, same as every other Tabularis notebook.

If you want to disable the audit log entirely, setting aiAuditEnabled: false in config.json falls back to the original code path with zero overhead.

2. Read-only mode

The simplest of the three features, configured under MCP → Safety → Read-only mode:

• Allow-list of read-only connections (default off, e.g. mark prod as read-only).
• Allow-list of writable connections (default on, e.g. mark local-sqlite as writable).

The classifier strips strings, comments and quoted identifiers before scanning the SQL keyword, and catches CTEs that end in UPDATE / INSERT / DELETE. Anything ambiguous is treated as a write: fail-closed is the safer default when the alternative is a corrupted production table.

Blocked calls land in the audit log with status = blocked_readonly and the agent gets:

Query blocked by Tabularis read-only mode. Enable writes for this connection in Settings → MCP → Read-only mode.

Most agents handle this gracefully — they rewrite as a SELECT or surface the error to you.

3. Approval gates with pre-flight EXPLAIN

Approval gates are the most involved of the three features, and the part that makes giving an agent write access to a real database feel like a sane choice.

When the agent fires a write, Tabularis pauses it and shows an AI Approval Modal:

• The full SQL in a Monaco editor (read-only by default; toggle "Edit before approving" to modify it).
• The execution plan, rendered with the same Visual Explain component used for ad-hoc EXPLAINs.
• An optional reason field. Approve, Deny, or close the modal.

The point is that you can see, before any row is touched, that the UPDATE would do a sequential scan over 1.2 million rows. You can fix the WHERE clause, add the right index hint, then approve. The audit log captures both the original and the edited query, linked by an approvalId.

There are three modes: off, writes_only (the default) and all queries. The timeout is configurable (120 s by default). Pre-flight EXPLAIN is best-effort: if it fails (DDL, syntax errors, missing permissions) the modal still opens with an "EXPLAIN unavailable" notice and you can decide anyway.

How approval gates actually work

The MCP server runs as a separate subprocess. The AI client spawns tabularis --mcp as a child process and the two talk over JSON-RPC 2.0 on stdin/stdout. That subprocess has no Tauri runtime, no AppHandle, and no socket back to the main app.

Asking the user to approve a write across that boundary needs some kind of channel. Three options were on the table:

1. A real RPC channel between the MCP subprocess and the main Tabularis app. Workable, but it means teaching the MCP binary to discover the running app, open a Unix socket or named pipe, handle disconnect and reconnect, deal with ports on Windows, and so on. A lot of moving parts for something fragile.
2. Desktop notifications from the OS. Quick to implement, but a desktop notification can't render a Visual Explain plan, which would defeat half the point of the feature.
3. A file queue. Both processes touch the same directory: the MCP server writes a request file and polls for a response file, while the Tabularis app uses notify (the inotify/FSEvents/ReadDirectoryChangesW crate) to watch the directory and pops up the modal as soon as a file appears.

Option 3 turned out to be the best fit. The directory looks like this:

~/.config/tabularis/pending_approvals/
  ├── {uuid}.pending.json    ← MCP server writes
  └── {uuid}.decision.json   ← Tabularis app writes

pending.json carries the full payload: query, classifier kind, connection, EXPLAIN plan as JSON, and the agent's clientInfo.name. decision.json carries the verdict (approve or deny), an optional reason, and an optional editedQuery if the user touched the SQL before approving.

The MCP server polls every 500 ms. The Tabularis app's file watcher fires the modal almost instantly. A periodic janitor (every 60 s) wipes anything older than an hour, so the directory never grows.

The whole thing is roughly 200 lines of Rust, with no IPC framework involved. It also works if you launch the agent before opening Tabularis: the request queues in the directory and the modal handles it the moment the app comes up. If Tabularis stays closed for the entire timeout (120 s by default), the call returns a clear error to the agent telling it to start the app first.

A nice side effect of the file queue is that the flow is testable end-to-end without an MCP client. Drop a pending.json with a fake payload into the directory, watch the modal pop up, click Approve, and a decision.json appears. No mocking required.

Bonuses

Open in Visual Explain. Every run_query row in the AI Activity panel has a one-click jump into the same Visual Explain modal that the query editor uses. It opens with the query and connection pre-loaded, runs EXPLAIN, and shows you the plan. Handy when a slow query shows up in the log and you want to know why.

Export Session as Notebook. Already covered above, but worth repeating: this is how an otherwise opaque AI conversation turns into something a human can review, diff and re-run. Attach the notebook to a PR, share it with a colleague, archive it alongside the ticket.

Defaults

After this upgrade:

Audit on, approval on writes_only, pre-flight EXPLAIN on. The first time the agent tries to write after upgrading, the modal will pop up. SELECTs go through without any friction.

To keep the previous behaviour wholesale, set aiAuditEnabled = false and mcpApprovalMode = "off" in config.json (or do the same from the MCP page in the app).

Where to read more

• Wiki: AI Audit Log · Read-only Mode · Approval Gates · MCP Server

None of this changes anything from the agent's point of view; it sees the same MCP server with the same tools. What changes is on the human side. The MCP page in the app (plug icon in the sidebar) is now organised into three tabs (Setup, Activity, Safety), and a modal will show up the next time the agent reaches for the database with anything sharper than a SELECT.

Summary

Thanks

A safety release is the kind of work that lives or dies on the questions people ask before merging, and on the bug reports that come back the same day a build ships. Thanks to everyone who tested the modal flows, pointed at edge cases in the read-only classifier, and helped shape what writes_only should actually mean in practice.

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

SQL Server will be a built-in driver. Not a plugin — peer to MySQL, PostgreSQL, SQLite, registered in the same lib.rs, served out of the same pool_manager, showing up in the connection modal with nothing to install first. Code lives on feat/sql-server today. Not on main. Not in any released build. Phase 1 on the branch is read-only browsing + query execution. Phase 2 — editing, TLS, composite primary keys — is six GitHub issues away. Help close it and the whole branch squashes back into main. Full scope, issue list and architecture notes are on the roadmap page.

Why built-in instead of a plugin

Tabularis has a plugin system. DuckDB, Google Sheets, Redis, and others reach the app through it, talking JSON-RPC over stdin/stdout. The system is stable and deliberately simple. It was still the wrong choice for SQL Server, for four reasons that matter in practice:

Streaming latency. Plugin drivers serialise every row through a JSON-RPC frame. On a 100k-row result the overhead is visible — for the built-in it's a Vec<Row> hand-off inside the host process.

Capability flags. The ER diagram's batch snapshot, the pager, the explain tree all branch on DriverCapabilities. Built-ins set those natively from the DatabaseDriver trait; plugins translate them through a JSON manifest, which drifts and needs to be kept in sync.

Credential and pool reuse. SSH tunnels, the keychain-backed credential cache, and the health pinger hold Arc<T> state inside the host binary. A plugin driver re-implements what it needs from that stack; a built-in shares one pool manager.

Install step. The plugin manager exists and works. Expecting a user to visit it for SQL Server specifically — day zero, from a fresh install — is the wrong default.

Costs: ~2.5 MB on the release binary (tiberius + deadpool + tokio-util compat layer), and the driver ships on the main release cadence instead of its own. We took those over the alternative.

What Phase 1 actually does

The driver lives under src-tauri/src/drivers/sqlserver/. It is readonly: true in its manifest — the UI honours that flag automatically and hides INSERT/UPDATE/DELETE controls — so users can browse and query without ever putting data at risk.

Concretely:

• Connect over SQL authentication; sys.schemas filtered against role schemas for the tree
• Table, view, routine discovery; column / PK / FK / index introspection
• execute_query streaming over tiberius::Client::query
• Pagination via a new PaginationDialect enum in drivers/common/query.rs — the legacy build_paginated_query(q, ps, p) signature still produces the same MySQL/PG/SQLite LIMIT/OFFSET output it always has. The SQL Server branch synthesises ORDER BY (SELECT NULL) when the caller query has no top-level ORDER BY, using a paren-depth-aware matcher (documented false positives on string literals, accepted trade-off)
• Type extraction dispatched off tiberius::ColumnType: int family, float family, Decimal with Numeric fallback for NUMERIC(38), Uuid, chrono temporals incl. datetimeoffset, varbinary → base64, xml, sql_variant
• Runtime version detection from SERVERPROPERTY('ProductMajorVersion'), cached per pool. Default major = 14 (2017) when parsing fails. supports_offset_fetch gates on ≥ 11, supports_string_agg on ≥ 14
• Batch endpoints for the ER diagram: get_all_columns_batch, get_all_foreign_keys_batch, get_schema_snapshot

The CI number: 471 Rust tests, 0 regressions on the existing MySQL/PostgreSQL/SQLite drivers. Every pure helper — identifier quoting, decimal normalization, query builders, the SQL-string constants themselves — ships with co-located #[cfg(test)] mod tests.

Phase 2 — six issues

Phase 1 was the part with the unknowns: whether tiberius 0.12 composes with the current tokio version, whether a non-sqlx pool can sit next to the sqlx ones in pool_manager, whether the DatabaseDriver trait generalises to a driver that doesn't speak LIMIT/OFFSET. Answers came out yes, yes, yes. Those risks are gone.

What's left is scoped and mostly independent. The epic is #150; the six sub-issues:

• #144 — ConnectionParams extension (trust_server_certificate, encrypt, instance_name, domain, auth_mode). All Option<T> with #[serde(default)] so old saved connections deserialize untouched. Labelled good first issue
• #145 — delete_record_composite / update_record_composite as default methods on the trait, forwarding to the legacy single-key path when pk_cols.len() == 1. No change to the other three drivers
• #146 — FK aggregation: STRING_AGG(…) WITHIN GROUP (ORDER BY constraint_column_id) on 2017+ servers, FOR XML PATH('') fallback for 2012–2016
• #147 — IDENTITY_INSERT ON/…/OFF wrapper inside an explicit transaction, triggered when the insert data contains a value for the IDENTITY column
• #148 — frontend: pkColumns?: string[] on DataGrid, composite detection in Editor.tsx, aggregate-by-constraint-name in SchemaDiagram.tsx. Depends on #145 and #146
• #149 — flip readonly: false, manage_tables: true. Closes Phase 2

Everything — architecture, module layout, type coverage, dependencies between issues, local setup — is on the roadmap page.

Ground rules

Three invariants get checked at review, they're not negotiable:

No GPL-licensed code copied from other open source SQL clients. The driver is written against Microsoft TDS / T-SQL docs and observable server behaviour; Tabularis stays Apache-2.0.

New struct fields are Option<T> / Vec<T> with #[serde(default)] + skip_serializing_if. Saved connections from previous releases deserialize untouched, and the MySQL / Postgres / SQLite drivers stay byte-identical — cargo test --lib catches regressions before the PR lands.

Every pure helper ships with #[cfg(test)] mod tests in the same PR. Happy path plus at least one edge case. SQL-string constants count as pure helpers — assert the query contains the expected sys.* / INFORMATION_SCHEMA.* tables and the right @P1 / @P2 placeholders.

If you want in

• Rust, backend: #144 (good first issue), #145, #146, #147
• TypeScript / React: #148 — DataGrid + Editor + ER diagram composite-PK support
• Just testing: spin up mcr.microsoft.com/mssql/server:2022-latest against your own schema, file issues for whatever doesn't match
• Architecture input: the epic #150 is the right thread

Full architecture reference, module layout, type-extraction details, local setup: roadmap page.

Phase 2 will land either way. It lands sooner, and better, with a couple more people on it.

Tabularis' plugin system has had three missing pieces since v0.9.0 launched it:

1. A published npm package with the plugin UI types — so authors stop copying type definitions from the host repo by hand.
2. A scaffolder CLI — so nobody has to write 33 JSON-RPC stubs, a cross-platform release workflow, and a manifest against a 230-line JSON schema from scratch.
3. An actual tutorial — not a reference; something you can follow top to bottom and end with a working driver.

The first two shipped as @tabularis/plugin-api and @tabularis/create-plugin. This post is the third.

I wrote it while scaffolding a Google Sheets driver from zero, so every command is one I actually ran. The final plugin lives at tabularis-google-sheets-plugin — clone it if you want the finished state to diff against.

What you'll end with: Google Sheets shows up in Tabularis' driver picker. Authenticate once with OAuth. Paste a spreadsheet URL. Sidebar lists every tab as a table. Run SELECT * FROM "Sheet1" LIMIT 5 and get rows.

Why Google Sheets

Two reasons.

It's not a database. Real drivers don't wrap RDBMSs exclusively — a registry plugin can expose anything queryable as SQL. Hacker News (posted here) exposes the HN Firebase API. A CSV-folder plugin exposes a directory. Google Sheets is another point on that axis: a row-oriented data source where each tab is a table and the first row is the header. No host, no port, no password — just OAuth.

It exercises two UI extension slots. The tutorial walks through both. Most plugins touch zero slots; some touch one. Two is the point at which the scaffolder's --with-ui defaults stop fitting and you learn how the IIFE loader actually works.

1. Scaffold

npm create @tabularis/plugin@latest -- \
  --db-type=api \
  --dir ~/Progetti/google-sheets \
  google-sheets

Three flags matter:

• --db-type=api — Google Sheets has no host/port/user/pass. The scaffolder sets no_connection_required: true in manifest.json and leaves the default ports null.
• --dir — scaffold outside your normal cwd so you can keep a "before/after" next to it.
• google-sheets — the plugin id. Used for the crate name, the binary, the manifest id, and the install path (~/.local/share/tabularis/plugins/google-sheets/ on Linux).

Ten seconds later, ~/Progetti/google-sheets/ contains:

google-sheets/
├── Cargo.toml
├── manifest.json           # metadata + UI extensions + data types
├── justfile                # build / install / test recipes
├── rust-toolchain.toml
├── .github/workflows/release.yml    # 5-platform matrix for v* tags
└── src/
    ├── main.rs             # JSON-RPC stdin/stdout loop
    ├── rpc.rs              # dispatch → handlers/
    ├── handlers/{metadata,query,crud,ddl}.rs
    ├── utils/{identifiers,pagination}.rs    # tested helpers
    ├── client.rs           # scaffold leftover (delete later)
    ├── error.rs            # scaffold leftover
    ├── models.rs           # scaffold leftover
    └── bin/test_plugin.rs  # local REPL

Every handler returns something valid:

• Metadata methods return empty arrays — the plugin loads in Tabularis without errors.
• test_connection returns {"success": true} hard-coded — the driver appears in the picker immediately after just dev-install.
• Query/CRUD/DDL methods return -32601 method not implemented — you haven't implemented them yet, and the host surfaces a clean error rather than crashing.

This matters. A newcomer to any plugin system needs to see their driver in the UI before writing a single line of real logic. "Empty but alive" is the right default.

cd ~/Progetti/google-sheets
cargo check  # should be green in seconds

2. Declare the driver

Open manifest.json. The scaffold gives you the right structural defaults for --db-type=api. You need to add three things: the settings, the UI extensions, and the data types.

Settings — five fields the plugin persists across restarts. The user never edits these; the OAuth wizard (step 6) writes them:

"settings": [
  { "key": "client_id",     "label": "OAuth Client ID",     "type": "string" },
  { "key": "client_secret", "label": "OAuth Client Secret", "type": "string" },
  { "key": "access_token",  "label": "Access Token",        "type": "string" },
  { "key": "refresh_token", "label": "Refresh Token",       "type": "string" },
  { "key": "token_expiry",  "label": "Token Expiry",        "type": "number" }
]

UI extensions — two slots. module paths point to the IIFE bundles Vite will produce in step 6:

"ui_extensions": [
  { "slot": "settings.plugin.before_settings",
    "module": "ui/dist/google-auth.js", "order": 10 },
  { "slot": "connection-modal.connection_content",
    "module": "ui/dist/google-sheets-db-field.js", "order": 10,
    "driver": "google-sheets" }
]

settings.plugin.before_settings mounts a component above the settings form of this plugin — perfect for an OAuth setup wizard. connection-modal.connection_content replaces the default host/port/user/pass form in the "new connection" modal with a custom layout — we need this because a Google Sheets connection has one field (spreadsheet id or URL) and none of the usual ones.

Data types — the three Sheets uses. infer_type in src/sheets.rs will pick one of these per column when the user opens a table:

"data_types": [
  { "name": "TEXT",    "category": "string",  "requires_length": false, "requires_precision": false },
  { "name": "INTEGER", "category": "numeric", "requires_length": false, "requires_precision": false },
  { "name": "REAL",    "category": "numeric", "requires_length": false, "requires_precision": false }
]

3. Three helper modules

Google Sheets is an API call away — the heavy lifting lives in three small Rust modules you drop into src/. They're not generated by the scaffolder because they're Sheets-specific; everything in src/handlers/ routes through them.

src/auth.rs — a module-level Mutex<AuthState> holding OAuth tokens. Exposes access_token(&client) -> Result<String> that transparently refreshes via https://oauth2.googleapis.com/token if the cached token is expired. ~110 lines. The initialize RPC (step 5) pushes saved settings into this state.

src/sheets.rs — a blocking reqwest client for the Sheets REST API. The public surface is thin:

pub fn get_sheet_names(spreadsheet_id: &str) -> Result<Vec<String>>
pub fn get_sheet_data(spreadsheet_id: &str, sheet_name: &str) -> Result<(Vec<String>, Vec<Vec<Value>>)>
pub fn append_row(spreadsheet_id: &str, sheet_name: &str, row: Vec<String>) -> Result<()>
pub fn update_cell(spreadsheet_id: &str, sheet_name: &str, col: &str, row: usize, value: &str) -> Result<()>
pub fn delete_row(spreadsheet_id: &str, sheet_id: i64, row: usize) -> Result<()>
pub fn infer_type(values: &[Value]) -> &'static str    // TEXT | INTEGER | REAL
pub fn extract_spreadsheet_id(raw: &str) -> &str       // accepts full URL or bare id

Every call goes through auth::access_token(). No service accounts — OAuth2 desktop flow only. ~300 lines.

src/sql.rs — a regex-based parser for the subset of SQL the driver handles:

pub enum Query { Select(...), Insert(...), Update(...), Delete(...) }
pub fn parse(raw: &str) -> Result<Query>
pub fn eval_where(where_clause: &str, row: &HashMap<String, String>) -> bool
pub fn extract_row_num(where_clause: &str) -> Result<usize>  // for UPDATE/DELETE "WHERE _row = N"

Don't write this by hand. It supports SELECT, INSERT, UPDATE WHERE _row = N, DELETE WHERE _row = N, COUNT(*), plus basic WHERE with AND/LIKE/=/>/etc. Nothing fancy. Copy from the companion repo — it's 320 lines of compiled regexes and string slicing. Replace with sqlparser when you care about joins and subqueries.

Add the dependencies to Cargo.toml:

anyhow = "1"
serde = { version = "1", features = ["derive"] }
serde_json = "1"
reqwest = { version = "0.12", features = ["blocking", "json"] }
regex = "1"

And register the modules in src/main.rs:

mod auth;
mod handlers;
mod rpc;
mod sheets;
mod sql;
// ...plus the scaffold leftovers for now

4. Metadata — make the sidebar come alive

src/handlers/metadata.rs starts with every method returning an empty array. Three of them need real data.

get_databases — one "database" per connection: the spreadsheet id extracted from the database field of the connection form. The host calls this when opening the connection picker — it drives what shows up in the sidebar as the top-level node.

pub fn get_databases(id: Value, params: &Value) -> Value {
    match spreadsheet_id(&id, params) {
        Ok(sid) => ok_response(id, json!([sid])),
        Err(resp) => resp,
    }
}

get_tables — each sheet tab becomes a table. get_sheet_names calls GET /v4/spreadsheets/{id}, reads sheets[].properties.title, returns a list.

pub fn get_tables(id: Value, params: &Value) -> Value {
    let sid = match spreadsheet_id(&id, params) { Ok(s) => s, Err(resp) => return resp };
    match get_sheet_names(&sid) {
        Ok(names) => {
            let tables: Vec<Value> = names.into_iter()
                .map(|n| json!({ "name": n, "schema": null, "comment": null }))
                .collect();
            ok_response(id, json!(tables))
        }
        Err(e) => error_response(id, -32000, &e.to_string()),
    }
}

get_columns — read row 1 as headers, sample rows 2..102, infer each column's type. Prepend a synthetic _row INTEGER PRIMARY KEY — this is what UPDATE/DELETE will WHERE on (the Sheets API indexes by position, there's no surrogate key).

Fill in get_schema_snapshot (for the ER diagram) and get_all_columns_batch (batch fetch at connection load) with the same pattern. Everything else (get_foreign_keys, get_indexes, get_views, routines) stays empty. Google Sheets has no such concepts; returning empty is the correct answer, not a stub.

Checkpoint. cargo check. If it compiles, the driver will light up the sidebar when installed. Save yourself some time and keep a second terminal open with cargo check --all-targets on fswatch — the scaffold's rust-toolchain.toml pins a stable channel so you won't hit nightly incompatibilities.

5. Initialize and execute

Two more handler files.

src/handlers/init.rs

The scaffold's default initialize returns null — fine for simple plugins, not fine here. The host sends params.settings containing whatever we saved via the UI extension (client_id, tokens, etc.), and we need to push those into the auth module:

pub fn initialize(id: Value, params: &Value) -> Value {
    let settings = params.get("settings").cloned().unwrap_or(Value::Null);
    let mut state = auth().lock().unwrap();
    *state = AuthState::default();
    state.oauth_client_id     = string_setting(&settings, "client_id");
    state.oauth_client_secret = string_setting(&settings, "client_secret");
    state.oauth_access_token  = string_setting(&settings, "access_token");
    state.oauth_refresh_token = string_setting(&settings, "refresh_token");
    state.oauth_token_expiry  = settings.get("token_expiry").and_then(Value::as_u64);
    ok_response(id, Value::Null)
}

Register it in src/handlers/mod.rs (pub mod init;) and in src/rpc.rs:

"initialize" => handlers::init::initialize(id, &params),

src/handlers/query.rs

Replace the scaffold's hard-coded test_connection with a real check, then implement execute_query by dispatching on the parsed query:

match parsed {
    Query::Select(sel) => run_select(id, &sid, sel, page, page_size, t0),
    Query::Insert(ins) => { /* fetch headers, build row in column order, sheets::append_row */ }
    Query::Update(upd) => { /* extract _row from WHERE, sheets::update_cell per SET entry */ }
    Query::Delete(del) => { /* extract _row from WHERE, sheets::delete_row */ }
}

run_select is the biggest function (~80 lines): fetches the sheet, prepends a synthetic _row column to every row, applies sql::eval_where in-memory, handles COUNT(*), applies LIMIT/OFFSET, projects columns. Copy it from the companion repo's handlers/query.rs.

Fill in handlers/crud.rs (insert/update/delete via _row primary key) and handlers/ddl.rs (get_create_table_sql reflects types inferred from row samples; every other DDL method returns -32601 with a clear message like "Google Sheets does not support indexes." Users see these messages in the UI — ambiguity costs them a trip to GitHub issues).

Checkpoint.

cargo build --release

30–60 seconds. The binary is at target/release/google-sheets-plugin. It's ~3 MB thanks to the scaffold's [profile.release] with lto, codegen-units = 1, strip = "symbols".

6. UI extensions, the typed way

Tabularis loads plugin UI as IIFE bundles — self-contained .js files assigning a React component to __tabularis_plugin__. You can hand-write raw IIFE and drop it in, or — the point of this whole exercise — you write TSX, Vite produces the IIFE, and the @tabularis/plugin-api npm package gives you typed slot contracts and hook signatures.

The scaffold's --with-ui flag already wired this up for one slot (data-grid.toolbar.actions). We need two slots, so we replace the single-entry Vite config with two configs sharing the same externals and output directory.

Workspace

ui/
├── package.json              # @tabularis/plugin-api + react + vite
├── tsconfig.json             # strict mode
├── vite.auth.config.ts       # entry: src/google-auth.tsx
├── vite.db-field.config.ts   # entry: src/google-sheets-db-field.tsx
└── src/
    ├── google-auth.tsx
    ├── google-sheets-db-field.tsx
    └── styles.ts             # shared CSSProperties objects

Each Vite config is a ~20-line defineConfig with build.lib.entry pointing at one TSX file, formats: ["iife"], and the critical externals map:

rollupOptions: {
  external: ["react", "react/jsx-runtime", "@tabularis/plugin-api"],
  output: {
    globals: {
      react: "React",
      "react/jsx-runtime": "ReactJSXRuntime",
      "@tabularis/plugin-api": "__TABULARIS_API__",
    },
  },
},

That's the whole protocol contract: the host injects the globals, the bundle consumes them. No React gets shipped twice.

The connection form (src/google-sheets-db-field.tsx)

Slot: connection-modal.connection_content. When the user picks "Google Sheets" as the driver in the new-connection modal, the host renders this component in place of the usual host/port/user/pass grid. One labeled text input for the spreadsheet ID or URL.

import { defineSlot, type TypedSlotProps } from "@tabularis/plugin-api";
import { PLUGIN_ID } from "./styles";

// plugin-api v0.1.0 types this slot's context as { driver: string }, but the
// host also passes `database` and `onDatabaseChange`. Augment locally until
// the next plugin-api release tightens the shape.
type FieldContext =
  TypedSlotProps<"connection-modal.connection_content">["context"]
  & { database?: string; onDatabaseChange?: (value: string) => void };

const GoogleSheetsDatabaseField = defineSlot(
  "connection-modal.connection_content",
  ({ context }) => {
    const c = context as FieldContext;
    if (c.driver !== PLUGIN_ID) return null;  // don't render for other drivers

    return (
      <div>
        <label>Spreadsheet ID or URL</label>
        <input
          type="text"
          value={c.database ?? ""}
          onChange={e => c.onDatabaseChange?.(e.target.value)}
          placeholder="https://docs.google.com/spreadsheets/d/…"
        />
      </div>
    );
  },
);

export default GoogleSheetsDatabaseField.component;

defineSlot is what the package brings. It wraps your component in a tagged { __slot, component } and — more importantly — types context per slot. If you wrote context.tableName here, TypeScript would refuse to compile: that field exists on data-grid.toolbar.actions, not here. The as FieldContext cast is only needed because this one slot's types are temporarily too narrow.

default export must be the component itself (.component) — the host loader reads that off the IIFE return value.

The OAuth wizard (src/google-auth.tsx)

Slot: settings.plugin.before_settings. Renders in the plugin's row in Settings. Click "Connect with Google" → a two-step modal wizard handles the OAuth dance.

Three plugin-api hooks do the heavy lifting:

const { getSetting, setSetting, setSettings } = usePluginSetting(PLUGIN_ID);
const { openModal, closeModal }               = usePluginModal();
// plus the standalone `openUrl` helper

• usePluginSetting(PLUGIN_ID) — typed getSetting<T>, setSetting, setSettings for the five OAuth fields from the manifest. Persists across restarts; the Rust side reads the same keys on initialize.
• usePluginModal() — host-managed modal. Pass it a React element as content and it portals to document.body. We use it for the wizard's two steps (credentials → paste redirect URL).
• openUrl(url) — window.open does not open external URLs in a Tauri webview. openUrl routes through @tauri-apps/plugin-opener and launches the system browser. Always use this for external URLs in plugins.

Slot component outline:

const GoogleSheetsOAuth = defineSlot(
  "settings.plugin.before_settings",
  ({ context }) => {
    if (context.targetPluginId !== PLUGIN_ID) return null;  // typed!
    const { getSetting, setSetting, setSettings } = usePluginSetting(PLUGIN_ID);
    const { openModal, closeModal } = usePluginModal();

    const isConnected = !!(getSetting("refresh_token") || getSetting("access_token"));

    return (
      <div className="google-account-panel">
        <Header connected={isConnected} />
        {isConnected
          ? <ConnectedActions onReauth={/* openModal(...) */} onDisconnect={/* setSettings(...) */} />
          : <ConnectButton onClick={/* openModal(...) */} />}
      </div>
    );
  },
);
export default GoogleSheetsOAuth.component;

Inside the wizard, the exchange is plain fetch:

async function exchangeCode(clientId, clientSecret, code) {
  const body = new URLSearchParams({
    code, client_id: clientId, client_secret: clientSecret,
    redirect_uri: "http://127.0.0.1",
    grant_type: "authorization_code",
  });
  const resp = await fetch("https://oauth2.googleapis.com/token", {
    method: "POST",
    headers: { "Content-Type": "application/x-www-form-urlencoded" },
    body: body.toString(),
  });
  if (!resp.ok) throw new Error(await resp.text());
  return resp.json();
}

Complete file (~330 lines with the full wizard UI and styling) at ui/src/google-auth.tsx.

Build

cd ui
pnpm install
pnpm run typecheck    # strict mode catches slot/context mismatches at build time
pnpm run build        # → dist/google-auth.js (≈8.5 KB) + dist/google-sheets-db-field.js (≈1.2 KB)

Gzipped, the two bundles add up to ~4 KB — because React and @tabularis/plugin-api are externalised, not bundled.

7. Install and demo

With just (one command builds Rust + UI, copies everything):

just dev-install

Without just:

cargo build --release
pnpm --dir ui install && pnpm --dir ui build

PLUGIN_DIR="$HOME/.local/share/tabularis/plugins/google-sheets"
mkdir -p "$PLUGIN_DIR/ui/dist"
cp target/release/google-sheets-plugin "$PLUGIN_DIR/"
cp manifest.json "$PLUGIN_DIR/"
cp ui/dist/*.js "$PLUGIN_DIR/ui/dist/"

Restart Tabularis (or toggle the plugin in Settings → Plugins if it was already enabled). Then:

1. Settings → Plugins → Google Sheets → gear icon. The OAuth wizard renders above the settings form thanks to settings.plugin.before_settings.
2. Paste Client ID + Client Secret from Google Cloud Console. Click Open Authorization Page →. Grant access in the browser, copy the redirect URL, paste it back, click Save Token.
3. New Connection → Driver: Google Sheets. The whole form collapses to a single "Spreadsheet ID or URL" input thanks to connection-modal.connection_content. Paste a spreadsheet URL.
4. Connect. The sidebar lists every tab as a table. Click one: row 1 becomes the column header, rows 2..N the data.
5. Try it in the editor: SELECT * FROM "Sheet1" LIMIT 5.

That's the full loop.

What this tutorial cut

The 20-minute budget was honest. These each deserve their own post:

• Row-level editing in the data grid. The crud.rs handlers are implemented but not demoed — once capabilities.readonly is false the Tabularis grid offers inline row editing via the _row primary key.
• Deep dive on @tabularis/plugin-api. The tutorial uses defineSlot, usePluginSetting, usePluginModal, and openUrl. The package also ships usePluginQuery, usePluginToast, usePluginTranslation, usePluginTheme, usePluginConnection, and version-compatibility helpers — all typed, all worth a separate post.
• Release packaging. The scaffold's .github/workflows/release.yml builds for 5 platforms on every v* tag and uploads zipped artifacts ready for the registry.
• A real SQL parser. The 320-line regex parser handles Sheets' needs; it won't handle joins, CTEs, or window functions. Swap in sqlparser when your driver grows up.

Where to go next

• plugins/PLUGIN_TUTORIAL.md — the canonical, repo-versioned copy of the walkthrough above.
• plugins/PLUGIN_GUIDE.md — the complete reference. Every RPC method, every manifest field, every UI slot, every capability flag.
• @tabularis/plugin-api — TypeScript types for slot contexts and host hooks.
• @tabularis/create-plugin — scaffolder CLI source and flags.
• tabularis-google-sheets-plugin — the finished plugin from this tutorial. Clone it for the full working state.
• Plugin registry — eight community drivers with eight different shapes worth copying from.

The promise from v0.9.0 was that adding a database to Tabularis should not require a patch to the core app. With the scaffolder and the plugin-api package, it now takes about twenty minutes.

Write one. It's faster than you think.

v0.9.20 owes a lot to the community. The two headline app features, clipboard data import and plan import for Visual EXPLAIN, ship alongside two outside contributions that change how Tabularis feels to use: a readability pass across every built-in theme, and a full visual overhaul of the website with video demos instead of screenshots.

If v0.9.19 was about polish, v0.9.20 is about reach. Getting data into Tabularis, understanding query plans inside it, and figuring out what Tabularis actually is before you install it are all easier in this release.

A New Look & Feel for the Website

The most visible change in v0.9.20 is not inside the app. It's on tabularis.dev itself, and it comes from @Nako0 in PR #142.

Screenshots are fine for static features, but a database client is about motion: you type in the editor, results appear, tabs get flipped, plans get expanded. A still image can't really carry any of that, and the old site didn't try to.

Here's what changed:

• The hero section now auto-plays a short overview video instead of a static screenshot, so the first thing you see is the app actually running.
• The wiki gained 11 embedded video demos: first connection, SQL editor, Visual Query Builder, SQL Notebook, Visual EXPLAIN, data grid, split view, plugins, AI assistant, keyboard shortcuts, and more. Each one has an auto-generated poster frame so the page still reads well before the video loads.
• A reusable VideoPlayer client component with loading states, an error overlay with a retry button, multi-event readiness detection (canplay, playing, loadeddata, timeupdate), and prefers-reduced-motion support for visitors who don't want autoplay.
• A server-side wrapVideosInHtml helper so wiki, blog, and SEO markdown authors can drop a plain <video> tag into content and get the same player for free.
• The GitHub README now opens with an overview.gif instead of a static PNG, so people coming in from search or social see the product in motion before they reach the site.

The site used to be a page of screenshots. It's a page of demos now, and that's entirely Nako's work.

Here's the overview video itself, the one that sits at the top of the home page. It's a good sample of the care that went into the rest:

Nako's own project, devglobe.xyz, is a genius idea and worth a detour. It's a live 3D globe of developers coding around the world in real time: you can see who is writing what, in which language, from which city, right now. A small Language Server plugin sends a heartbeat every 30 seconds while you're active, sharing only the language, a city-level location, and the editor name. There's a Zed extension already, and more editors in the works. It's the kind of thing that sounds obvious in hindsight and somehow nobody had built yet.

Readability Across Every Theme

@thomaswasle's PR #139 is a readability pass across every built-in theme, not just the default.

Tabularis ships with a range of themes (Dracula, light, dark, high-contrast, and more), and each one had picked up small contrast issues over time. Thomas went through all of them and normalized the spots where text, borders, or highlighted rows were harder to read than they should be. v0.9.18 did this for Dracula on its own; v0.9.20 brings the rest up to the same bar.

Easy to miss if you stick to one theme. Very noticeable if you switch around, or if you've been quietly putting up with low contrast in one of the less-used ones.

Clipboard Import — Paste Data Directly Into a Table

Sometimes the shortest path from a spreadsheet to a database is a copy and a paste.

v0.9.20 adds a Clipboard Import flow: copy tabular data from a spreadsheet, a CSV preview, a rendered Markdown table, or another SQL client, and paste it straight into Tabularis. The app detects the structure, proposes a target table and column mapping, and lets you review the rows before they're inserted.

It pairs well with the existing CSV and SQL dump imports. When you only have a handful of rows and no file on disk, opening a dialog just to save a throwaway .csv is friction. Clipboard import skips that step.

The wiki has the full walkthrough, and the website's Features section now has a dedicated entry on when clipboard import is the right choice versus a file-based import.

Import Existing Plans Into Visual EXPLAIN

Visual EXPLAIN gains import support in v0.9.20: EXPLAIN output captured elsewhere (a plan pasted from a colleague, a snippet from a GitHub issue, an export from another client) opens straight into the viewer without re-running the query.

Makes it much easier to share a plan and reason about it together, instead of treating Visual EXPLAIN as a purely local tool.

Comparison Pages and Other Website Work

v0.9.20 also ships the first batch of comparison pages: side-by-side pages showing where Tabularis lines up with (and differs from) other database clients. They use a shared comparison-builder component, proper logos (now in PNG for crisper rendering), and styling consistent with the rest of the site.

Alongside them:

• The website now reads the app version from a single APP_VERSION source of truth, so release-tied strings stay in sync automatically.
• The sitemap is referenced from robots.txt, which helps the new comparison pages get indexed faster.
• A new long-form post, Databases Are Not Becoming Chatbots, ships alongside the release.

Under the Hood

Two smaller changes worth calling out:

• React hook deps and tooltip wrapper fix. A rare case where memoized settings definitions could end up with stale state in a few tooltip-wrapped controls. Memoization and callbacks are stable now, state no longer drifts.
• CLI parsing extracted into its own module. The Tauri entry point in the Rust backend used to carry its argument-parsing logic inline. Pure refactor, no behavior change, but it makes future CLI flags (and their tests) a lot easier to add.

A Community Release

Worth naming plainly what this release is: of the six headline changes, three came from outside contributors. That ratio is new for Tabularis, and it's a good sign.

To @Nako0 for turning the site from screenshots into demos: thank you, seriously. Tabularis looks like a different product now. And go check out devglobe.xyz while you're at it.

To @thomaswasle for quietly pushing the themes towards being uniformly readable: the app is more comfortable to spend a day in because of your work.

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

Over the last months, while building Tabularis, I started realizing that I was not just building a database client.

I was running into a bigger question: what happens to databases when software no longer just reads and writes records, but also tries to interpret schema, suggest queries, explain execution plans, preserve working context, and collaborate with language models?

I do not have a final answer, but I am starting to form a position.

My current view is that the natural evolution of databases is not that they become chatbots. I also do not think they become "AI-native" in the vague marketing sense that phrase usually carries.

What is changing is the layer around the database.

Databases still matter because structured truth still matters. Tables, constraints, indexes, transactions, and schemas are not becoming obsolete just because language models are good at generating plausible text. If anything, they become more important when the surrounding software becomes probabilistic.

What AI changes is not the need for a system of record. It changes the system of interpretation, navigation, and action around that record.

That shift is becoming very concrete to me in Tabularis.

Once you put a SQL editor, AI-assisted query generation, query explanation, visual explain plans, notebooks, MCP integration, and a plugin system in the same product, the old idea of a database client starts to feel incomplete.

A database client used to be a place where you connected to a server, browsed tables, wrote some SQL, inspected results, and moved on. That model is still useful, but it no longer feels sufficient.

The moment AI enters the workflow, the client becomes something else: a coordination layer between a human trying to understand a system, a database holding structured truth, and a model trying to compress, interpret, and act on context.

One of the signals for me: the useful part is not just generating SQL, but helping make reasoning around queries and plans more legible.

The Part I Keep Coming Back To

The strongest idea I keep circling back to is this: the real change is not that databases start speaking natural language. The real change is that the workflow around data becomes more contextual, more stateful, and more collaborative.

In Tabularis, that is visible in small ways and large ones.

An AI overlay in the editor is not just a shortcut for writing SQL faster. Query explanation is not just a convenience feature for beginners. Visual EXPLAIN is not just a prettier way to look at query plans. Notebooks are not just a nicer place to collect queries. MCP is not just another integration checkbox.

Taken together, they point in the same direction. Database work is moving away from isolated commands and toward systems that help users build, inspect, preserve, and reuse context.

That is the part that feels important to me.

The Technical Decisions I Am Making in Tabularis

Building Tabularis has forced me to make a few technical bets. They are still bets, not conclusions, but they say a lot about what I currently believe.

1. AI should not become the source of truth

This is the most important one.

I do not want AI to replace schema, queries, plans, or results. I want it to sit above them as a layer of interpretation.

That sounds obvious, but it is easy to blur this boundary. A generated query can start feeling authoritative. A natural-language explanation can sound more reliable than the actual execution plan. A confident answer can quietly push the user into trusting the model more than the database.

I do not think that is a healthy direction.

In Tabularis, the database should remain the thing that is real. The AI layer should help the user access, understand, and manipulate that reality, but it should not quietly replace it.

2. AI should stay optional

I am keeping AI optional in Tabularis, and that choice is partly practical but also philosophical.

I do not think the future of database tooling should collapse into a single provider, a single model family, or even a single interaction style. Some users want OpenAI-compatible APIs. Some want Anthropic. Some want Ollama. Some want no AI at all.

I do not think that flexibility is just a commercial checkbox. I think it reflects the right abstraction. The stable thing is not the model. The stable thing is the workflow.

3. Preserved context matters more than one-shot generation

This is probably the bet that has become stronger as I kept building.

A lot of AI product design still assumes that the main value is in producing an answer quickly. Sometimes that is true. But in database work, I suspect a large part of the value is not generation but preserved context.

Why did I run this query?

What assumption was I testing?

What did the previous result suggest?

Which part of the schema turned out to matter?

Why does this plan get expensive at this join?

That is why notebooks and explainability feel so important to me in Tabularis.

A notebook is not just a better place to put SQL and Markdown. It is a form of working memory. Visual explainability is not just an educational feature. It is a way to make optimization reasoning legible.

The more I work on the product, the more I think memory and explanation are more durable primitives than raw generation.

The more I work on notebooks, the more I think preserved context is a deeper primitive than one-shot AI output.

4. The future probably looks more composable than monolithic

I am also leaning into MCP and plugins because I increasingly doubt that the future here will be monolithic.

I do not think there will be one magical "AI database" that cleanly absorbs querying, reasoning, context management, automation, and verification into a single perfect layer.

I think the more likely future is composable.

Databases will remain databases. Models will remain models. Clients, agents, plugins, and protocols will mediate between them.

Tabularis keeps pushing me toward that conclusion because the moment you try to support real workflows, you discover that no single surface is enough.

The Mistakes I Think I May Be Making

This is the part I trust the most, because it is the least polished.

I am not just making decisions. I am also building under uncertainty, and some of that uncertainty is probably pointing at mistakes.

I may be using AI where better UX would solve the problem more cleanly

There is always a temptation to add a generative layer when the actual problem is discoverability, information architecture, or interface design.

If a user cannot find the right table, understand a relationship, or inspect a plan easily, an AI-generated explanation may help. But it may also hide the fact that the product itself is not yet clear enough.

I think this is one of the easiest traps to fall into. AI can compensate for weak product decisions just well enough to make those decisions look acceptable.

I may be overestimating how often users want generation instead of control

It is easy, especially when building AI features, to assume that the more the system does for the user, the better.

I am not convinced that is true in database tooling.

A lot of serious database work is not blocked by typing speed. It is blocked by ambiguity, risk, context switching, and lack of confidence.

In that world, the winning feature may not be "generate the query for me." It may be "help me trust what I am about to run."

Those are very different product instincts.

I may be underestimating reproducibility and auditability

A query written by a human is imperfect, but it is usually inspectable in a straightforward way.

A suggestion generated from a changing prompt, dynamic schema context, model-specific behavior, and hidden retrieval steps is much harder to reason about after the fact.

If AI becomes part of database work, then being able to understand why something was suggested, what context was used, and how a decision was derived becomes much more important.

I suspect the industry still talks too much about generation quality and too little about decision traceability.

I may be designing too much for the future

This is the most uncomfortable possibility.

Once you start seeing where things might go, it becomes tempting to over-architect for a world that has not arrived yet.

Maybe some of what I think will become core will remain peripheral. Maybe the average user does not want an AI-mediated database environment. Maybe they just want a fast editor, a clear schema browser, and fewer rough edges.

I try to keep that possibility in mind because future-facing product conviction can become self-indulgent very quickly.

What I Think Is Actually Emerging

I do not think databases are going away.

I do not think SQL is going away.

I do not think language models replace the need for carefully modeled data, explicit constraints, or systems that can be trusted.

But I do think the center of gravity is shifting.

More of the value around data work will sit in context management, interpretation, explainability, derivation, memory of prior work, and tool-mediated action around the database itself.

That does not make the database less important. If anything, it makes it more important, because the rest of the system becomes softer and less deterministic.

The database remains the anchor.

What changes is everything around it.

Tabularis, at least for me, is a way to explore that shift in concrete form.

Not as a grand theory, and definitely not as a finished answer, but as a product that keeps forcing the question.

Every time I add AI to query writing, explanation to plans, notebooks to analysis, or MCP to agent workflows, I feel the same tension: the old boundaries between client, assistant, and interface to the database are getting weaker.

I may be wrong about where that leads.

I may be making some of the wrong bets too early.

But I am increasingly convinced that the old model of "database client as editor plus grid plus manual querying" is no longer enough.

Something wider is emerging around the database, and building Tabularis is my way of trying to understand what it is.

v0.9.19 is a short follow-up to v0.9.18. It does not introduce a new headline feature. Instead, it smooths out the rough edges around the History and Favorites workflows that just landed, fixes a few bugs, and brings two new locales — French and German — into the UI.

If v0.9.18 was about shipping the new sidebar workspace, v0.9.19 is about making it feel finished.

Two New Languages: French and German

Tabularis now ships in six languages: English, Italian, Spanish, Chinese, French, and German.

Both new locales were produced with AI assistance and then wired into the standard i18n pipeline alongside the existing translations. Language detection is still automatic based on your system locale, with a manual override in Settings → General.

AI-generated translations are a practical way to unblock users who were locked out by the language barrier, but they are not a replacement for a native speaker's eye. Some phrasings will feel off, some terminology will not match what a French or German developer would actually say in front of a database.

If you speak either language and spot something that should be rewritten, the locale files are plain JSON — no build step, no toolchain, no ceremony. Open a pull request against src/i18n/locales/fr.json or src/i18n/locales/de.json and it will land in the next release. The same invitation stands for the other locales too.

The project README is also available in both languages: README.fr.md and README.de.md.

Sidebar Polish

The Explorer sidebar gained a few small but noticeable touches on top of the structure introduced in v0.9.18.

• SQL preview highlighting — history and favorites entries now render their SQL preview with lightweight syntax highlighting instead of flat text. It makes the sidebar much easier to scan when you are looking for a specific query at a glance.
• Grouped favorites — saved queries are now sorted and grouped in a way that keeps related items close together, instead of relying on a single flat list.
• Delete confirmation — removing a favorite now goes through a confirmation step, so a misclick in the sidebar no longer silently loses a saved query.
• Single-click selection — sidebar items now highlight on a single click, which makes keyboard and mouse navigation feel consistent with the rest of the app.
• SQL preview truncation — long queries in the sidebar now truncate cleanly instead of pushing the layout around.

Database Context for History and Favorites

A subtle but important fix around multi-database sessions: both query history and saved queries now persist the database the query was originally run against.

That means when you re-run a query from History or reopen a favorite, Tabularis brings you back to the right database automatically, instead of leaving you on whichever database happened to be active in the editor. It is the kind of small correctness fix that you only appreciate after it has been wrong once in production.

On top of that, connections that transition from a single-database setup to multi-database mode now have their database field backfilled, so existing history and favorites remain valid across the change.

Other Fixes

A handful of smaller improvements rounding out the release:

• The Query History section in the sidebar got layout and interaction polish alongside the new highlighting.
• The saved-query modal now surfaces timestamp metadata and a database picker when it matters.
• The website's overview image was refreshed.

Nothing dramatic, but each item removes a small friction point reported after v0.9.18 went out.

Small Release, Real Improvements

v0.9.19 is not a big release on paper. It does not add a new tab, a new engine, or a new mode. What it does is take the new workflows introduced in v0.9.18 and bring them closer to feeling finished — cleaner sidebar previews, correct database handling on re-run, and two more languages in the UI.

If you are already on v0.9.18, the upgrade is painless and worth it for the polish alone. If you speak French or German and want to improve the fresh translations, pull requests are very welcome.

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

v0.9.18 is mainly about one thing: making History useful enough to become part of the normal SQL editing loop.

Before this release, Tabularis already gave you strong editing, favorites, notebooks, and now Visual EXPLAIN. What was missing was a lightweight way to go back through the actual queries you ran during exploration. This update adds that missing layer: a per-connection query history in the Explorer sidebar, with search, grouping, quick actions, and retention controls.

Query History, Per Connection

Every executed query is now stored in the Explorer's History tab for the active connection.

That sounds straightforward, but the important part is the scope: history is per connection, not global. Your PostgreSQL session, your MySQL analytics connection, and your local SQLite scratchpad each keep their own timeline.

This matters because query history is only useful when it stays close to context. If you are debugging a production issue in one connection and testing a schema idea in another, you do not want those timelines mixed together.

A Better Sidebar for Ongoing Work

To make room for these new workflows, the Explorer sidebar also becomes more clearly structured.

Instead of treating everything as one long schema tree, Tabularis now gives the active connection a small workspace of its own: Structure, Favorites, and History live side by side in the same panel.

That change matters because the feature set is no longer just about browsing tables. The sidebar now has to support three different kinds of work:

• Structure when you need schema objects and navigation
• Favorites when you want to keep reusable SQL close at hand
• History when you want to go back through what you just ran

It is a small UI change on paper, but it is an important one architecturally. It turns the sidebar from a database tree into a more complete working surface for exploration, repetition, and recall.

Built for Real Iteration

The new History tab is not just a raw log.

Each entry stores:

• The executed SQL
• The execution timestamp
• The duration
• Whether it succeeded or failed
• Rows affected when available

From there, Tabularis gives you the actions you actually need while iterating:

• Search by SQL text
• Date grouping such as Today and Yesterday
• Double-click to reopen a previous query in the editor
• Run again or run in a new tab
• Copy SQL
• Save to Favorites
• Delete a single entry or clear all history for the current connection

This turns history into a fast loop: run a query, tweak it, compare with an older version, reopen it, and keep going without hunting through tabs or clipboard fragments.

Small Details That Make It Better

Two practical choices make the feature feel more polished than a basic history panel.

First, repeated executions of the exact same SQL do not immediately spam duplicate entries one after another. Tabularis de-duplicates consecutive identical queries and updates the latest entry instead.

Second, history surfaces failures as first-class information instead of pretending only successful queries matter. That is important in real database work, because the query you need to revisit is often the one that failed five minutes ago.

There is also a retention control in Settings → General → Query History, with queryHistoryMaxEntries defaulting to 500 per connection.

Multi-Caret Editing

The SQL editor in Tabularis supports multi-caret editing, which lets you place several cursors in the editor and type, delete, or select at all of them simultaneously.

This is useful more often than it sounds. Renaming a column alias in four places at once, wrapping several lines in a function call, adding commas to a list of values, commenting out a block of conditions one by one: these are the kind of micro-edits that slow you down when you have to repeat them manually.

Here are the shortcuts that make it work:

Paste Into Multiple Carets

v0.9.18 adds one more piece to this workflow: pasting into multiple carets.

When you have multiple cursors active and paste text from the clipboard, Tabularis distributes the pasted lines across the cursors, one line per caret. If the number of lines in the clipboard matches the number of cursors, each cursor receives its own line. Otherwise, every cursor receives the full pasted text.

This makes column-wise edits, repeated line transformations, and bulk query rewrites much less awkward. It is the kind of change you notice immediately because it removes a break in muscle memory.

Other Notable Improvements in v0.9.18

The release is centered on History, but there are several other useful additions and fixes around it.

This is @midasism's contribution in PR #132: PostgreSQL schema mode now gets a proper table search filter, bringing it closer to the multi-database browsing experience already available elsewhere in the app.

This is @traustitj's contribution in PR #133: MySQL connections now expose SSL configuration options directly in the connection flow, which is an important upgrade for real deployments where plaintext local-style settings are not enough.

This is @thomaswasle's contribution in PR #134: MySQL connection URLs now use the system timezone correctly instead of forcing UTC behavior.

This is @thomaswasle's contribution in PR #135: the Dracula theme gets a readability pass, improving contrast in places that previously felt harder to scan.

This is @krissss's contribution in PR #138: custom OpenAI provider URLs no longer duplicate path segments or assume a hardcoded /v1, which makes alternative provider setups much more reliable.

Alongside the community contributions, the core app also picks up several maintainer-authored improvements in this release: a plugin settings page, better plugin config caching, an explain-selection modal, an open source libraries modal, a welcome screen toggle, and a few sidebar and editor polish fixes.

History That Stays in the Editor

The value of this feature is not just that Tabularis now stores past SQL. The useful part is that the history stays inside the same workspace where you browse schema objects, save favorites, write notebooks, and inspect query plans.

That makes v0.9.18 a smaller release than v0.9.17, but also a very practical one. It removes friction from the everyday loop of writing SQL, rerunning it, comparing versions, and returning to something that worked.

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

v0.9.17 is centered around one feature: Visual EXPLAIN.

Instead of treating query plans as raw text you have to decode manually, Tabularis now opens them in a dedicated full-screen workflow with a graph view, a table view, raw output, and optional AI analysis. If you spend time tuning joins, tracking down slow scans, or checking whether an index is actually used, this is the release that makes that workflow much more practical.

Visual EXPLAIN, Now Built In

You can now run Visual EXPLAIN directly from the SQL Editor and from Notebook SQL cells.

Tabularis selects the right explain format for the current driver, parses the result, and shows the plan in four synchronized views:

• Graph for the execution tree and expensive nodes
• Table for exact metrics and per-node details
• Raw for the original database output
• AI Analysis for a second-pass explanation of likely bottlenecks

The goal is simple: less time decoding plan output, more time understanding what the optimizer is doing.

Why This Matters

EXPLAIN is one of the most useful tools in SQL, but the output is rarely pleasant to work with. PostgreSQL gives you rich JSON, MySQL changes behavior depending on the server version, MariaDB exposes its own fields, and SQLite gives you a much flatter structural plan.

In v0.9.17, Tabularis smooths over those differences and turns them into one consistent inspection workflow.

That means you can:

• Spot the highest-cost node without scanning raw output line by line
• Compare estimated rows against actual rows when ANALYZE data is available
• Inspect filters, index conditions, loops, and buffer data in one place
• Re-run the plan after an index or query rewrite and check what changed

For PostgreSQL in particular, this is a major upgrade over bouncing between the editor and external tooling just to inspect a single plan.

The Main Pieces of Visual EXPLAIN

The new workflow is more than a single graph.

Graph and Node Details

The default view renders the execution plan as a node graph with cost-based coloring, so the expensive parts of the query stand out immediately. Selecting a node opens a detail panel with the metrics and conditions attached to that step.

This makes it much easier to answer questions like:

• Where is the scan happening?
• Which join is dominating cost?
• Is the estimate badly wrong at a specific node?
• Is the plan using the index you expected?

Overview Bar

An overview section highlights the most relevant signals from the plan, including the highest-cost node, the slowest step, large estimate gaps, sequential scans, and temporary operations. Instead of reading the whole plan top to bottom first, you can jump directly to the suspicious areas.

AI Analysis

Visual EXPLAIN also adds a dedicated AI analysis flow. Tabularis can send the query and raw plan output to the configured provider and return a structured explanation of what the plan is doing, where the likely bottlenecks are, and what might be worth testing next.

This release also introduces a cleaner AI dropdown button in the notebook and editor UI, which fits well with the new explain-analysis workflow.

Cross-Database Support

Visual EXPLAIN is not PostgreSQL-only.

v0.9.17 adds driver-aware handling for:

• PostgreSQL with JSON plans, ANALYZE support, and buffer statistics
• MySQL with automatic version detection and fallback between EXPLAIN ANALYZE, EXPLAIN FORMAT=JSON, and tabular EXPLAIN
• MariaDB with JSON parsing improvements for filesort, wrappers, and subquery cache details
• SQLite with reconstructed plan trees from EXPLAIN QUERY PLAN

That cross-driver work is a large part of what makes this release important. The UI is visible, but most of the value comes from normalizing very different execution-plan formats into one model that Tabularis can actually visualize.

Safer Explain Workflows

There are also a few practical guardrails in this release.

Tabularis now checks whether a query is actually explainable before sending it to the database, strips leading comments before validation, and handles EXPLAIN ANALYZE more carefully for data-modifying statements.

In practice, that means:

• DDL statements are blocked before they turn into confusing errors
• Annotated queries still work as expected
• INSERT, UPDATE, and DELETE are treated more carefully when ANALYZE would execute them

These details matter because they keep Visual EXPLAIN useful in real-world workflows, not just in ideal demos.

Smaller Improvements

Visual EXPLAIN is the headline, but not the only change in v0.9.17.

• Multi-database connection editing now auto-loads databases

That keeps the release focused, with a small usability improvement around connection setup alongside the new query-plan workflow.

Read the Plan, Stay in Context

The interesting part of this release is not just that Tabularis can run EXPLAIN. Plenty of tools can do that. The useful part is that the result stays inside the same environment where you are writing and testing the query.

Run the query. Open the plan. Inspect the graph. Check the exact node metrics. Re-run after a change.

If you want the full walkthrough, there is now a dedicated Visual EXPLAIN documentation page and the earlier feature preview post with more screenshots and background.

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

Eleven weeks ago I pushed the first binary of Tabularis to GitHub. A database client. One person, a late-night frustration, a Tauri app with a SQL editor and not much else.

Last week, ten weeks in, the repo crossed 1,000 stars. Today, at week eleven, there are 1,086 stars, 70 forks, 15 contributors, 41 releases, and a plugin ecosystem that didn't exist eight weeks ago. The project started as "debba.sql". I renamed it to Tabularis a few days in because I wanted it to feel like something bigger than a personal tool.

It became bigger than a personal tool. Not because of a launch strategy. Because people showed up.

This post is what I'd tell myself ten weeks ago if I could go back. Not a growth playbook (those already exist and most of them are noise). This is what actually happened, what I think mattered, and what I got wrong.

Week 1: Ship Fast, Ship Broken, Ship Anyway

The first week produced fifteen releases. Fifteen. From v0.2.0 to v0.8.6. Some of them were embarrassing. I shipped a version that crashed on Wayland. I shipped a version where the database dropdown didn't work properly. I shipped anyway.

Here's what I learned: nobody remembers your v0.3.0. People remember whether the tool was useful when they tried it, and whether it got better when they came back. Shipping fast builds that muscle: the ability to push a fix in hours, not weeks. By the end of week one the release pipeline was solid, the update flow worked, and I had the confidence that I could fix anything that broke within a day.

The alternative, polishing in private for months, would have meant launching into silence. Instead, the first few users arrived while the project was still rough, and they stayed because they could see it moving.

Week 2-3: The First External Contributor Changes Everything

@niklasschaeffer opened the first external PR in week two: support for custom OpenAI-compatible API endpoints. It was a clean, well-scoped contribution. It also changed my relationship with the project overnight.

Before that PR, Tabularis was my code. After it, Tabularis was a codebase other people could read, understand, and modify. That shift, from "my project" to "our project", is the most important thing that happened in the first month.

By week three, @kconfesor contributed PostgreSQL schema selection and a full Spanish locale. Someone I'd never met decided the tool was worth translating into their language. That's a signal no star count can match.

What I'd do differently: I should have written contributor documentation from day one. The first contributors succeeded despite the lack of guides, not because of them.

Week 4-5: The Plugin System, the Bet That Paid Off

At the one-month mark we had ~270 stars and 5 contributors. Good momentum. But the decision that actually changed the trajectory was shipping the plugin system in v0.9.0.

A language-agnostic JSON-RPC protocol. Any language, any database. The first plugin (DuckDB) was ready on day one. Within two weeks the community had added Redis, ClickHouse, CSV, and a Hacker News plugin that turned a public API into a SQL-queryable database.

The plugin system did three things at once:

1. It multiplied what Tabularis could do without multiplying my workload. I didn't write the Redis driver. I didn't write the ClickHouse driver. The community did.

2. It gave contributors a sandbox. Writing a plugin is self-contained: you don't need to understand the Tauri backend or the React frontend. That dramatically lowered the barrier to contribution.

3. It changed the story. Tabularis went from "a database client that supports three databases" to "a platform that can support any database." That's a much more interesting pitch.

Lesson: building an extension point early is one of the highest-leverage things a solo maintainer can do. It turns users into builders.

Week 6-8: Momentum Compounds

This is the phase where everything started compounding. New contributors arrived every release. @gzamboni and @nicholas-papachriston with the Redis plugin. @SergioChan fixing modal behavior. @sycured adding PostgreSQL SSL modes. @fandujar building connection groups. @GreenBeret9 fixing SQLite issues.

Three things were happening simultaneously:

• The product was improving faster than I could improve it alone. Community PRs were shipping features I hadn't planned: connection string import, drag-and-drop, bug fixes for databases I don't even use daily.

• The blog was building trust. I wrote about every major release, honestly. What worked, what didn't, what was coming. The HN plugin post was as much a stress test report as a feature announcement. People responded to that transparency.

• Word of mouth was doing the work. I never paid for promotion. Never ran ads. I did post on Reddit, Hacker News, X, Daily.dev, and dev.to, but from there the growth took on a life of its own: people sharing Tabularis in Slack channels, blog posts, and conversations I never saw.

Lesson: consistency > virality. A new release every few days, a blog post every week, a Discord channel where questions get answered. That steady rhythm builds more trust than any single launch.

Week 9-10: International, AI-Powered, Notebook-Ready

The last few weeks brought some of the most exciting contributions:

• Chinese (Simplified) language support from @GTLOLI, the first Asian locale, opening up Tabularis to a massive developer community.
• MiniMax as a first-class AI provider from @octo-patch, expanding the AI assistant beyond the usual suspects.
• Extended PostgreSQL type support from @dev-void-7: arrays, JSON, custom types. The kind of deep, unglamorous work that makes a database tool actually reliable.
• SQL Notebooks, the biggest feature release since the plugin system. Cell-based SQL analysis with inline charts, cell references, parameters, and parallel execution. Built directly into the app.

And last week, @thomaswasle contributed drag-and-drop for connection groups. A small feature, but it represents something important: people are building the tool they want to use, not just the tool I envisioned.

The Numbers, Honestly

The 1,000-star milestone landed at week ten. Here's where things stand today, one week later:

One thing that surprised me: where those stars come from. About half of our stargazers have a public location on their GitHub profile, and they span 72 countries across every continent:

The United States and China lead, but what stands out is the long tail: South Korea, Germany, France, Brazil, Indonesia, Vietnam. Tabularis isn't a tool for one market. It's a tool for developers, and developers are everywhere.

The download breakdown by operating system tells a complementary story. Windows leads at 40.8%, followed by macOS at 32.3% and Linux at 26.9%:

What I find encouraging is that all three platforms have meaningful adoption. The Linux share is especially notable for a desktop app — it reflects the developer audience we're building for. And within each OS, the format diversity (setup vs. portable on Windows, .deb vs. AppImage vs. .rpm on Linux) suggests people are actually integrating Tabularis into their workflows, not just trying it once.

These numbers feel good. But I want to be honest about what they don't measure.

Stars are a vanity metric. I know that. A star doesn't mean someone uses Tabularis daily, or that it solved a real problem for them, or that they'll come back for v0.10. What I care about more: issues opened by people who actually tried the product. PRs from people who cared enough to fix something. Messages on Discord from people running Tabularis against their production databases.

1,000 stars is a milestone worth marking. It's not a destination.

What Didn't Work

Not everything landed. A few honest misses:

• Documentation lagged behind features. The wiki exists, but it's still thin. Features shipped faster than docs, and some users bounced because they couldn't figure out setup. This is the biggest gap I need to close.

• Windows testing was always behind. Most contributors (including me) develop on macOS or Linux. Windows bugs took longer to surface and longer to fix. A few early Windows users had a rough experience.

• I underestimated the support load. Solo maintainer math: every new feature creates new questions. Every new plugin creates new edge cases. I love that people are engaged. I'm still learning how to scale my attention.

The AI Factor

I need to be honest about something: Tabularis would not exist without AI-assisted development. Specifically, without Claude Code.

A Tauri app with a Rust backend, a React/TypeScript frontend, a plugin system, an MCP server, SQL notebooks, and 41 releases in eleven weeks. One person. That math doesn't work without a force multiplier, and AI was that multiplier.

But here's the part that gets lost in the hype: AI doesn't replace experience. It amplifies it. Claude Code didn't design the plugin architecture. It didn't decide that JSON-RPC was the right protocol, or that the credential cache needed to wrap the system keychain, or that the notebook execution model should support parallel cells. Those decisions came from years of building software, understanding trade-offs, and knowing what users actually need.

What AI did was collapse the distance between a decision and its implementation. Once I knew what to build, I could build it in hours instead of days. The Rust backend, the React components, the test suites, the CI pipeline: Claude Code handled the volume while I handled the direction.

The analogy I keep coming back to: AI is like having an incredibly fast junior developer who never gets tired and knows every API. Powerful, but only if you know what to ask for. Without a clear architectural vision, without the experience to spot when the output is subtly wrong, without the judgment to know which corners not to cut, you just get bad code faster.

Three years ago, Tabularis would have been a side project that took a year to reach v0.5. Today it's at v0.9.16 with a real community. The difference isn't just speed. It's that AI let me stay in the creative, architectural layer, the part that actually matters, instead of spending most of my time on implementation details.

If you're an experienced developer and you're not using AI-assisted tools yet: try it. Not as a replacement for thinking, but as a way to spend more of your time on the thinking that counts.

What I'd Tell Someone Starting Today

If you're building an open source project and wondering whether it can find an audience, here's what I actually believe after ten weeks:

1. Ship before you're ready. Your first version will be embarrassing in retrospect. That's fine. The feedback you get from real users in week one is worth more than three months of private iteration.

2. Build an extension point early. A plugin system, a hook system, a theme system — anything that lets other people build on top of your work without needing your permission or your codebase knowledge.

3. Write about what you're building. Blog posts, release notes, changelogs. Not marketing copy. Honest accounts of what you built and why. People can tell the difference.

4. Respond to every contributor. Review PRs quickly. Say thank you publicly. The first five contributors set the culture for the next fifty.

5. Don't ask for stars. Build something useful. The stars follow.

What's Next

The plugin ecosystem is growing but still young. Notebooks need polish: performance with large documents, circular reference detection, keyboard navigation. The AI features are useful but could be smarter about schema context. And the documentation needs serious attention.

Beyond specific features: I want Tabularis to be the database client that developers actually enjoy using. Not the one with the most features on a comparison chart, but the one that feels fast, looks good, and gets out of your way. That's been the north star since day one, and it hasn't changed.

We're also approaching a plugin registry redesign, better onboarding for new contributors, and, if the community keeps growing at this pace, the possibility of Tabularis becoming more than a solo-maintained project.

Thank You

1,000 stars means 1,000 people decided this project was worth remembering. Some of them went further — they opened issues, submitted PRs, translated the interface, wrote plugins, and helped shape what Tabularis is becoming.

A special thanks to our sponsors: turboSMTP, Kilo Code, and Usero. They believed in the project early and help keep it free and independent. Their support covers development time that would otherwise come entirely out of pocket.

To every contributor, every user, every person who mentioned Tabularis to a colleague or dropped a link in a chat: thank you. This stopped being a solo project the moment you showed up.

If you want to get involved, the Discord is the fastest way in. Come say hi. There's plenty to build.

Here's to the next thousand.

The Tabularis Team

After the much bigger notebook release, v0.9.16 is a smaller one. The focus here is on making connection organization less clunky: fewer context menu steps, more direct manipulation. If you use groups heavily, this release removes a bit of friction you'll feel immediately.

Drag and Drop for Connection Groups

This is @thomaswasle's contribution in PR #126.

Connection groups on the Connections page are now draggable.

You can:

• Drag a group by its grip handle to reorder it
• Drag a connection onto another group to move it there
• See a visual highlight on the target group while dragging

That sounds small, but it changes the workflow quite a bit. Before, reorganizing connections meant using menus and explicit move actions. Now it's the interaction you'd expect: grab, drop, done.

For anyone with separate local, staging, production, analytics, or client-specific setups, this makes keeping the list tidy much less annoying.

Pagination Logic, Cleaned Up

There is also a useful backend cleanup in the built-in drivers: pagination logic is now centralized for PostgreSQL, MySQL, and SQLite instead of each driver carrying its own slightly different implementation.

The practical effect is consistency. When Tabularis paginates a SELECT, it now preserves ORDER BY more safely and respects user-written LIMIT / OFFSET clauses as a cap instead of treating them differently depending on the driver.

This is not the kind of change that needs a screenshot, but it is the kind that prevents subtle "why is page 2 weird?" behavior later.

Small Follow-Up Fix

A small UI follow-up also landed right after the drag-and-drop work: a corrected useDatabase destructure in the sidebar. Not headline material, but exactly the kind of cleanup worth shipping in a point release.

What's Next

One of the next updates will be Visual Explain — the new query plan analysis workflow previewed in the dedicated blog post.

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

Most of the time, you do not look at an execution plan out of curiosity. You look at it because a query is slow, a join is behaving strangely, an index is not being used, or the optimizer is doing something you did not expect. EXPLAIN is the tool you reach for when you need to answer a concrete question: where is the work happening, and why?

The problem is that execution plans are useful, but not especially pleasant to inspect in their raw form. You usually get a tree encoded as indented text, JSON meant more for machines than humans, or engine-specific output that changes depending on the server and version. To get from that output to an actual diagnosis, you have to reconstruct the shape of the plan, compare estimated and actual values, and identify which node is likely responsible for the cost.

Take a plan like this:

Nested Loop Left Join  (cost=4.18..1247.32 rows=2400 width=128)
  ->  Hash Join  (cost=3.75..142.56 rows=800 width=72)
        Hash Cond: (p.category_id = c.id)
        ->  Seq Scan on posts p  (cost=0.00..124.00 rows=5000 width=68)
              Filter: (status = 'published')
        ->  Hash  (cost=2.50..2.50 rows=100 width=12)
              ->  Seq Scan on categories c  (cost=0.00..2.50 rows=100 width=12)
  ->  Index Scan using idx_post_id on comments cm  (cost=0.29..1.35 rows=3 width=64)
        Index Cond: (post_id = p.id)

The information is there, but the inspection work is still mostly manual. You have to read the tree structure, compare node costs, check estimated versus actual rows, and keep the query itself in your head while doing it. On MySQL you also need to know which EXPLAIN format your server version supports. On SQLite you get a flat list with parent IDs and have to rebuild the tree mentally.

That is the reason for Visual EXPLAIN in Tabularis. The goal is not to replace EXPLAIN, but to make it faster to inspect. Tabularis takes the execution plan, turns it into a graph, highlights the expensive nodes, shows estimated and actual metrics side by side, and keeps the raw output available when you need it. If you want, it can also generate an AI analysis as a second pass over the plan.

It is still in active development on the feat/visual-explain-analyze branch, but it already works on PostgreSQL, MySQL, MariaDB, and SQLite.

How It Works

Select a query and click the EXPLAIN button. Tabularis opens a full-screen modal, picks the right EXPLAIN syntax for the current database, runs it, parses the result, and exposes four views:

• Graph — interactive node tree (ReactFlow + Dagre layout)
• Table — hierarchical tree table with a detail panel
• Raw — the original JSON/text output in Monaco
• AI Analysis — AI summarizes the plan and points out likely issues

The top bar shows the main summary metrics: planning time, execution time, and total cost. You can switch views without re-running the query.

The Graph View

This is the default view.

Each operation in the plan becomes a node. Seq Scan, Index Scan, Hash Join, Nested Loop, Sort, Aggregate: the full tree is rendered as a graph, with edges showing the flow from leaf scans to the final result. Layout is computed with Dagre, so plans with multiple branches stay readable without manual positioning.

Each node shows:

• Node type and relation (which table or index)
• Estimated rows and cost (startup + total)
• Actual rows, time, and loops (when ANALYZE is on)
• Filter and index conditions

Nodes are color-coded by relative cost: green for cheap operations, yellow for moderate ones, red for expensive ones. The scale is relative to the most expensive node in the current plan, so the expensive parts stand out immediately without having to compare raw numbers line by line.

The view supports zoom, pan, and fit-to-view. For larger plans, a minimap appears in the corner.

The Table View

The graph is useful for structure. The table is better when you want exact metrics.

On the left there is an expandable tree with columns for node type, relation, cost, estimated rows, time, and filter. Selecting a row opens a detail panel on the right with all metrics available for that node: cost breakdown, actual vs estimated rows, loops, buffer hits and reads, index conditions, hash conditions, and any engine-specific fields present in the source plan.

If you have used EXPLAIN in pgAdmin or DBeaver, the layout will feel familiar. The main difference is consistency: the same view model is used across PostgreSQL, MySQL, MariaDB, and SQLite.

Raw Output

Sometimes you just want the original payload.

The raw view shows the database response in a read-only Monaco editor, with syntax highlighting, wrapping, and search. No transformation, no interpretation.

AI Analysis

The AI tab sends the query and the raw EXPLAIN output to the configured provider and returns a structured analysis: what the query is doing, where the likely bottlenecks are, which indexes may help, and which rewrites are worth testing.

It works with OpenAI, Anthropic, Ollama, and custom OpenAI-compatible endpoints. The response is generated in the language configured in Tabularis, which makes it more practical if you do not normally reason about plans in English.

It is not a replacement for knowing how to read execution plans. It is closer to a second pass over the plan, which is useful when the issue is not obvious or the query is large enough that manual inspection is slow.

EXPLAIN vs EXPLAIN ANALYZE

There is a toggle in the footer. EXPLAIN gives you the estimated plan: what the optimizer expects to happen. EXPLAIN ANALYZE executes the query and reports what actually happened, including actual rows, actual time, loop counts, and, where supported, buffer statistics.

The difference matters. A plan might estimate 100 rows and actually scan 100,000. You only see that with ANALYZE.

ANALYZE is enabled by default, except for data-modifying queries. For INSERT, UPDATE, and DELETE, the checkbox starts disabled and the UI shows a warning. EXPLAIN ANALYZE executes the statement, so treating those queries as read-only would be misleading.

DDL statements such as CREATE, DROP, ALTER, and TRUNCATE are blocked entirely. They are not valid inputs for this workflow, so Tabularis stops them before they turn into opaque database errors.

Multi-Database Support

Visual EXPLAIN adapts to each engine. The differences are significant.

PostgreSQL

PostgreSQL is the primary target. Tabularis uses EXPLAIN (FORMAT JSON, ANALYZE, BUFFERS), which gives structured output with planning time, execution time, buffer hit/read statistics, and the full node tree. All graph and table metrics are derived from that JSON.

This is the most complete implementation right now.

MySQL

MySQL is more version-dependent. Tabularis runs SELECT VERSION(), parses the result, and chooses the best supported format:

• MySQL 8.0.18+ — EXPLAIN ANALYZE (text tree with actual execution data)
• MySQL 5.6+ — EXPLAIN FORMAT=JSON (structured plan, estimates only)
• Older versions — tabular EXPLAIN fallback

There is no manual configuration for this. Detection is automatic.

MariaDB

MariaDB has similar capabilities, but with different syntax and fields. Tabularis detects the MariaDB version string and uses:

• MariaDB 10.1+ — ANALYZE FORMAT=JSON (executes the query, returns JSON with both estimated and actual r_* fields)
• MariaDB 10.1+ — EXPLAIN FORMAT=JSON (estimates only)

SQLite

EXPLAIN QUERY PLAN returns a flat list of operations with parent IDs. Tabularis reconstructs the parent-child tree from that output. There are no execution metrics because SQLite does not expose an ANALYZE-style result here, but the structure of the plan is still useful.

Current State

This feature is still under active development. Current status:

• PostgreSQL is the most complete — full JSON parsing, all metrics, ANALYZE with buffers.
• MySQL and MariaDB work well — version detection, multiple format fallbacks, JSON and text tree parsing. Edge cases across the many server versions in the wild are the main gap.
• SQLite is basic — plan tree is there, execution metrics are not.
• Node interaction — clicking a graph node does not open the detail panel yet. Table view supports it, but the views are not linked.
• Cost bar visualization — proportional cost bars inside graph nodes, not just border colors.
• Plan comparison — EXPLAIN before and after a query or index change, side by side. Planned, not implemented yet.
• Plugin drivers — community database drivers can implement explain_query in the driver trait and get Visual EXPLAIN for free.

Contributions Welcome

This is open source, and there are several places where contributions would be useful.

If you know PostgreSQL internals well, the parser can expose more node-specific details such as parallel workers, CTE scans, and materialization hints. If you use MySQL or MariaDB heavily and run into parsing edge cases, bug reports with the raw EXPLAIN output are especially helpful. If you want to work on visualization, there is room for better layouts, cost distribution views, and comparison workflows.

The driver trait defines a standard explain_query interface. Any community plugin that implements it gets Visual EXPLAIN automatically.

Development is happening on the feat/visual-explain-analyze branch. Issues and PRs are welcome on the GitHub repository.

Why This Matters

Every database has some form of EXPLAIN. Very few database clients make it easy to work with.

In practice you usually get raw text, a table with overloaded columns, or a static tree that is hard to inspect once plans get larger. The underlying data is useful. The presentation is usually not.

The result is predictable: people delay looking at the plan until a query is already causing trouble, and then they spend time decoding output instead of fixing the actual problem.

Visual EXPLAIN is an attempt to make that workflow shorter. Run the query, inspect the plan in the same client, identify the expensive nodes, and iterate without copying JSON into external tools or switching to another application.

It is landing soon. Progress is tracked on feat/visual-explain-analyze.

Try It Yourself

If you want to test Visual EXPLAIN on MySQL or MariaDB, I put together a demo database and a Tabularis notebook with more than 25 queries covering table scans, index access patterns, joins, subqueries, CTEs, aggregations, UNIONs, and deliberately expensive cases.

• explain-demo-database.sql — MySQL/MariaDB schema with ~15k rows across 8 tables, a mix of indexed and unindexed columns
• explain-showcase.tabularis-notebook — importable notebook with annotated queries, one per optimizer strategy

Run the SQL file on your server, import the notebook into Tabularis, and click Explain on any cell.

This is the one where Tabularis stops being just a query editor. SQL Notebooks — the feature previewed in the dedicated blog post a few days ago — ship in this release. Alongside them, the regular query editor gets a major upgrade: multi-query execution with tabbed and stacked results, AI-powered tab naming, and a proper query splitter that finally handles edge cases correctly.

SQL Notebooks

The headline feature. A full notebook environment inside Tabularis — no Jupyter kernel, no Python runtime, no context switching.

A notebook is a sequence of SQL and Markdown cells. SQL cells run against your database and show results inline — the same data grid, sorting, and filtering you already know from the query editor. Markdown cells let you document your analysis between queries.

But the real power is in what connects the cells:

Cell references — any SQL cell can reference a previous cell's query using {{cell_N}} syntax. Tabularis resolves this at execution time by wrapping the referenced query in a CTE. Change the base query, re-run the downstream cells, everything stays consistent.

Inline charts — bar, line, and pie charts render directly inside SQL cells. Pick a label column and value columns, and the chart updates live. Not a BI tool replacement — a quick visual check while you explore.

Parameters — define @start_date = '2024-01-01' once, use it across every cell. Change the value, re-run, every query picks it up.

Parallel execution — mark independent cells with the lightning bolt icon and they fire concurrently during Run All instead of waiting in line.

AI integration — each cell has AI Generate and Explain buttons. The sparkles icon generates a descriptive name based on cell content, which feeds into the outline panel — a navigable table of contents for long notebooks.

Persistence and export — notebooks auto-save to disk as .tabularis-notebook JSON files. Export as HTML for a standalone, dark-themed document ready to share. Import/export .tabularis-notebook files to collaborate with colleagues.

For the full walkthrough — cell management, execution history, multi-database queries, keyboard shortcuts — see the SQL Notebooks wiki page.

Multi-Query Execution

Run a script with multiple semicolon-separated queries and instead of a modal asking you to pick one, Tabularis now executes all of them and shows results in a dedicated multi-result panel.

The result panel ships with two view modes, switchable via a toggle button:

Tab view (default) — each query gets its own tab with:

• Collapsible query preview — expand any tab to see the SQL that produced it.
• Tab context menu — right-click to close, close others, or close tabs to the right.
• Inline rename — double-click a tab name to rename it.
• AI rename — click the sparkles icon to let AI generate a descriptive name based on the query content.
• Scrollable tabs — when you have more results than fit, tabs scroll horizontally.

Stacked view — inspired by SQL Server Management Studio, all results are displayed vertically in a single scrollable panel. No tab switching — every result set is visible at once.

• Collapsible sections — click any result header to collapse or expand it. A top-bar button collapses or expands all at once.
• Resizable — drag the handle between results to adjust the height of each data grid.
• Full per-result actions — rename, AI rename, re-run, and close are available on each result header, just like in tab view.
• Compact metadata — row count, execution time, pagination controls, and auto-paginated badges are inline in the header so nothing is hidden.

If your script uses parameters (:param syntax), Tabularis prompts for values once before running all queries.

The query selection modal also got a revamp — you can now run a single query from the list without switching to single-query mode.

Query Splitting: Done Right

This is @dev-void-7's contribution in PR #119. The old regex-based query splitter had blind spots — string literals containing semicolons, dollar-quoted blocks in PostgreSQL, comments with semicolons — all would trip it up and split queries in the wrong places.

The fix replaces the custom splitter with dbgate-query-splitter, a proper parser that understands SQL dialects. It correctly handles:

• Semicolons inside string literals and comments
• PostgreSQL $$-quoted blocks
• MySQL DELIMITER statements
• Nested BEGIN...END blocks

This was a prerequisite for multi-query execution to work reliably, and it quietly fixes a class of bugs that affected the existing query selection modal too.

AI Tab Rename

The AI features in Tabularis extend to a new place: tab naming. Click the AI icon on any editor tab and Tabularis generates a descriptive name based on the query content. Instead of staring at "Query 1", "Query 2", "Query 3", you get names that actually describe what each tab does.

The prompt is customizable in Settings > AI > Tab Rename Prompt.

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

The theme of this release is reliability. Tabularis now monitors every open connection in the background and tells you when something drops. The PostgreSQL type system takes another massive leap forward — this time covering network addresses, geometric shapes, full-text search, and a dozen more families. And the DDL modals get the UX pass they've needed for a while.

Connection Health Check

This is the headline feature. Previously, if a database connection dropped — network hiccup, server restart, idle timeout — you wouldn't find out until your next query failed. Now Tabularis knows before you do.

A background Tokio loop pings every active connection at a configurable interval (default: 30 seconds). Built-in drivers use a pool-level ping — no query is executed, no overhead. Plugin drivers receive a ping JSON-RPC call; if the plugin hasn't implemented it, Tabularis falls back to test_connection automatically.

After 2 consecutive failures, the connection is closed, any SSH tunnel is torn down, and a toast notification tells you what happened with a button to jump to the Connections page.

The interval is configurable from Settings → General → Connection Health Check — a slider from 0 to 120 seconds. Setting it to 0 disables pings entirely.

For plugin authors: implementing ping is optional but recommended if your driver can do a cheaper liveness check than a full test_connection. The Plugin Guide and the wiki document the protocol and fallback behavior.

PostgreSQL: 40+ New Types

This is @dev-void-7's second major contribution in a row. After range, multirange, and enum support in v0.9.13, PR #114 lands with binary-level deserialization for an enormous set of PostgreSQL types that were previously opaque. The implementation lives in a dedicated advanced_types.rs module — over 1,500 lines of Rust, each type parsed from its binary wire format and serialized to a human-readable JSON representation.

What's new

Network types — INET, CIDR, MACADDR, MACADDR8. IP addresses display as 192.168.1.0/24, MAC addresses as aa:bb:cc:dd:ee:ff.

Geometric types — POINT, LSEG, BOX, PATH, POLYGON, LINE, CIRCLE. Each renders in standard PostgreSQL notation: (x, y) for points, <(cx, cy), r> for circles, open [...] or closed (...) for paths.

Full-text search types — TSVECTOR and TSQUERY. Vectors display lexemes with positions and weights. Queries are fully parsed as expression trees — operators, phrase matches, prefix wildcards, weight filters — and serialized back to readable query syntax.

Time types — TIMETZ with timezone offset, INTERVAL with full decomposition into years, months, days, hours, minutes, seconds, and microseconds. Overflow is normalized correctly (e.g. 25 hours → 1 day + 1 hour).

Money, XML, RefCursor, JsonPath — MONEY renders as a number (stored as i64 cents), XML and REFCURSOR as strings, JSONPATH strips the internal version prefix and returns the path expression.

System internals — PG_LSN (log sequence numbers), TXID_SNAPSHOT / PG_SNAPSHOT (transaction snapshots), AclItem, PgNodeTree, and various statistics types (PG_MCV_LIST, PG_DEPENDENCIES, PG_NDISTINCT).

Object identifiers — XID, CID, XID8, TID, and all REG* types (REGCLASS, REGTYPE, REGPROC, etc.) — returned as their underlying OID or formatted string.

Bit types — BIT and VARBIT, decoded to human-readable binary strings with correct padding.

Along the way, the type picker in the schema editor also gained these types — grouped by category (network, geometric, fulltext, xml, system, reg) — plus extension-aware types: HSTORE, LTREE/LQUERY/LTXTQUERY, CITEXT, PostGIS types (GEOMETRY, GEOGRAPHY, and common GEOMETRY(...) variants), INTARRAY, and common array variants (INTEGER[], TEXT[], UUID[], JSONB[], etc.).

This is the kind of work that turns "PostgreSQL support" from a marketing bullet into a real claim.

Searchable Type Picker in DDL Modals

The raw HTML <select> elements in the Create Table and Modify Column modals are gone. They've been replaced with the custom searchable Select component — the same one used elsewhere in the app. Start typing and the list filters instantly.

This matters more than it sounds. With the PostgreSQL type list now exceeding 100 entries (thanks to the expansion above), scrolling through a native dropdown was painful. Now you type "geo" and see GEOMETRY, GEOGRAPHY, POINT, POLYGON — nothing else.

The column type column in the Create Table modal table has also been widened to accommodate longer type names like GEOMETRY(Point, 4326).

Column Type Parsing and Extension Tracking

A new utility module handles the round-trip between database-reported type strings and the form fields in the schema editor. parseColumnType correctly splits VARCHAR(255) into type + length, but knows not to strip the parenthesized arguments from PostGIS types like GEOMETRY(Point, 4326) where the parentheses are part of the type name.

buildColumnDefinition does the reverse — composing a backend-compatible string from form data.

getRequiredExtensions scans the columns in a table and returns the deduplicated list of PostgreSQL extensions they need (e.g. ["postgis", "hstore"]). Each type in the picker now carries an optional requires_extension field so the UI can surface this information before you apply the DDL.

SMALLSERIAL Auto-Increment

A missing branch in the PostgreSQL DDL generator. When you enabled auto-increment on a SMALLINT column, Tabularis would emit SERIAL instead of SMALLSERIAL — silently creating a column with a larger type than intended. Fixed. The logic now correctly maps SMALLINT → SMALLSERIAL, INTEGER → SERIAL, BIGINT → BIGSERIAL.

The UI also got a sync pass: enabling auto-increment now forces NOT NULL checked and disabled (serial columns are always NOT NULL) and clears the default value field.

Query Selection Modal: Keyboard Navigation

The modal that appears when you execute a script with multiple semicolon-separated queries now supports full keyboard navigation:

• Arrow Up / Down — move focus between queries, with auto-scroll
• Enter — execute the focused query
• Number keys 1–9 — directly execute query N

The focused item gets a blue border and a numbered badge. Mouse hover syncs with keyboard focus. All strings are translated (English, Spanish, Italian, Chinese).

Autocompletion Fix for Multiple Databases

This is @thomaswasle's contribution in PR #115. The Monaco autocomplete provider was always using the top-level table list, ignoring which schema or databases were actually active. If you had a PostgreSQL connection with a non-default schema selected, or a MySQL connection with multiple databases checked, the suggestions were wrong.

The fix computes the effective table list based on context: schema tables for schema-aware connections, the union of selected database tables for multi-db connections, or the global list as fallback. The useEffect dependency array is corrected to re-register autocomplete when context changes.

ORDER BY Without Swallowing LIMIT / OFFSET

When you click a column header to sort, Tabularis injects or replaces an ORDER BY clause in your query. The string manipulation was naive — it would slice from ORDER BY to the end of the query, destroying any LIMIT or OFFSET you had written. Now it detects trailing LIMIT/OFFSET clauses and preserves them. Fixed across all three built-in drivers (PostgreSQL, MySQL, SQLite).

Smaller Changes

• CI/CD — GitHub Actions bumped across all workflows: actions/checkout v6, actions/setup-node v6, pnpm/action-setup v5, swatinem/rust-cache v2.9.1.
• Driver fallback hardened — the ping fallback now catches both "Method not found" and "not implemented" error strings from plugins.
• Test coverage — new tests for TsQuery, TsVector, advanced types, and the column type parsing utilities (273 lines).

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

Every database client has a query editor. You write SQL, you run it, you see a table. If you need to build on that result, you copy-paste it into the next query. If you need a chart, you export to CSV and open a spreadsheet. If you want to document your analysis, you paste queries into a Notion doc and hope nothing drifts out of sync.

I have been doing this for years, and it has always felt like the wrong workflow. The database client knows your data. It knows your schema. It has the connection. Why should analysis happen somewhere else?

That question has been driving the next big feature in Tabularis: Notebooks. A cell-based environment for SQL analysis, built directly into the app. No Jupyter kernel to configure, no Python runtime to install, no context switching.

This is still a work in progress — not shipped yet, not final. But the core is functional, the pieces are connecting, and I want to share where this is heading and why I think it matters.

The Idea

A notebook is a sequence of cells. Each cell is either SQL or markdown.

SQL cells run against your database and show results inline — the same data grid you already know from the query editor, with sorting, filtering, and resizable result panels. Markdown cells let you document what you are doing, why, and what the results mean. Together they create a single, self-contained analysis document.

But cells are just the foundation. The interesting part is what connects them.

Cell References: Queries That Build on Queries

This is the feature I am most excited about.

Any SQL cell can reference a previous cell's query using {{cell_N}} syntax. Tabularis resolves this at execution time by wrapping the referenced query in a CTE:

-- Cell 1: Base query
SELECT customer_id, SUM(amount) AS total
FROM orders
GROUP BY customer_id

-- Cell 3: References Cell 1
SELECT * FROM {{cell_1}} WHERE total > 1000

When Cell 3 runs, Tabularis rewrites it to:

WITH cell_1 AS (
  SELECT customer_id, SUM(amount) AS total
  FROM orders
  GROUP BY customer_id
)
SELECT * FROM cell_1 WHERE total > 1000

No temp tables, no copy-paste, no drift. Change the base query, re-run the downstream cells, everything stays consistent. You can chain references across multiple cells to build complex analyses step by step, and each intermediate result remains visible and inspectable.

Inline Charts

Every SQL result with at least two columns and one row can be visualized as a chart — directly inside the cell.

Three chart types so far: bar, line, and pie. You pick a label column and one or more value columns. Bar and line charts support multi-series. Pie charts take a single series. The chart configuration is saved with the cell — close the notebook, reopen it, the chart is still there.

This is not meant to compete with dedicated BI tools. It is for the moment when you are exploring data and want a quick visual confirmation of a pattern before writing the next query. That moment used to mean leaving the database client. Now it does not.

Parameters

Define a parameter once, use it across every cell:

@start_date = '2024-01-01'
@end_date   = '2024-12-31'
@min_amount = 500

Any SQL cell containing @start_date will have it substituted before execution. Change the value, re-run, every query picks up the new value.

Particularly useful for recurring analyses — monthly reports, cohort comparisons, threshold testing — where the logic stays the same but the inputs change.

Parallel Execution

Not every cell in a notebook depends on the previous one. Some are independent queries — pulling data from different tables, running complementary aggregations that do not reference each other.

Mark a cell with the lightning bolt icon, and it runs concurrently during "Run All" instead of waiting for the cells above it to finish. For notebooks with heavy queries against different datasets, this can cut total execution time significantly.

Sequential cells still run in order. Parallel cells fire together. You control it per cell, one click.

Stop-on-Error and Run All

Hit Run All (or Ctrl+Shift+Enter) and every SQL cell executes top to bottom. The Stop on Error toggle controls whether execution halts at the first failure or powers through the rest of the notebook.

After execution, a summary card shows succeeded, failed, and skipped cells. Failed cells are clickable — tap one and the notebook scrolls straight to it. No hunting through a long document for the red cell.

Multi-Database Queries

If you have multiple databases connected, each SQL cell can target a different one. A dropdown in the cell header lets you pick the schema — pull data from production PostgreSQL in one cell and compare it with your analytics SQLite in the next, all within the same notebook.

Works across MySQL, MariaDB, PostgreSQL, and SQLite.

Execution History

Every SQL cell keeps a record of its last 10 executions — timestamp, execution time, row count. Expand the history panel, pick any previous run, and restore that query version. Useful when you have been iterating on a cell and want to go back, or when you need to compare current results against an earlier run.

AI Integration

Notebooks plug into the AI features that already exist in Tabularis, in two ways.

In the editor: each SQL cell has "AI" and "Explain" buttons. "AI" opens the generation modal — describe what you want, get SQL back. "Explain" takes the current query and breaks it down. Same tools available in the main query editor, now available per cell.

Cell naming: click the sparkles icon in any cell header, and AI generates a descriptive name based on the cell content. Named cells appear in the notebook outline — a collapsible panel that shows all cell names and markdown headings as a table of contents. For long notebooks, this turns a wall of anonymous cells into a navigable document.

Organization

Notebooks can grow. To keep them manageable:

• Collapse any cell to hide its body and results, showing just the header.
• Drag and drop cells to reorder them.
• Cell names (manual or AI-generated) give each cell identity beyond "Cell 7."
• Markdown cells act as section headers and documentation between query groups.

Import and Export

Two export formats are taking shape:

.tabularis-notebook — a JSON file containing the notebook structure: cells, parameters, chart configurations, cell names. No results or runtime data — it is a template. Share it with a colleague, they import it, connect to their database, and run it.

HTML export — a self-contained HTML document with rendered markdown, SQL highlighting, and result tables embedded. Dark-themed, ready to share or archive. The "send it to your manager" format.

Individual cell results can also be exported as CSV or JSON from the result toolbar.

What Is Still Cooking

This is an honest preview. Some things work, some things need polish, some things might change before release. A few areas I am still iterating on:

• Performance with large notebooks — 30+ cells with heavy results need more work on virtualization and memory management.
• Cell reference validation — right now circular references are not caught before execution. That needs a proper dependency graph.
• Chart customization — axis labels, color palettes, and data formatting are minimal. Enough to explore, not enough to present.
• Keyboard navigation — moving between cells, adding cells, running cells — all of this should be possible without touching the mouse. Partially there, not fully.
• Undo/redo at the notebook level — cell-level undo works (it is Monaco), but notebook-level operations like reorder and delete are not undoable yet.

I would rather ship this with rough edges acknowledged than wait for perfection. The core value — connected, documented, visual SQL analysis inside the database client — is already there. The rest is refinement.

Why This Matters

Database clients have been stuck in a loop: connect, query, look at a table, repeat. Analysis tooling evolved — Jupyter, Observable, dbt — but the database client stayed behind. You still need to leave it the moment your work goes beyond a single query.

Notebooks in Tabularis are a bet that the database client is the right place for exploratory SQL analysis. You already have the connection. You already have the schema. You already have autocomplete and query history. Adding cells, charts, references, and parameters on top of that foundation means the entire workflow — from first query to shareable report — can happen without switching tools.

This is not a Jupyter replacement. There is no Python, no R, no arbitrary code execution. It is purpose-built for SQL. And for the kind of work most people actually do with their database every day — ad-hoc exploration, report building, data validation, performance investigation — that focus is a feature, not a limitation.

Stay tuned. This is landing soon.

This release closes the loop on something I've been building toward for a while. Plugins can now render their own UI inside Tabularis — not through hacks or workarounds, but through a proper extension system with typed contracts and error isolation. Alongside that, the PostgreSQL driver picks up three new type families, and the Settings page has been completely rearchitected.

Plugin UI Extensions: From Spec to Production

Back in v0.9.10 I published the spec for UI extensions. The idea was straightforward: define named insertion points (slots) in the host interface, let plugins register React components against those slots, and have the host render them with the right context. No iframes, no eval, no DOM hacking — just controlled React components inside controlled boundaries.

v0.9.13 ships the full implementation.

What's in the box

Ten slots across the application — from individual field annotations in the row editor, to toolbar buttons, context menu items, sidebar actions, settings panels, and connection form extensions. Each slot passes a typed context object to the plugin component: connection metadata, table name, row data, column info, whatever makes sense for that location. The full list and context shapes are documented in the plugin wiki and the PLUGIN_GUIDE.

A set of host-provided hooks that give slot components access to host capabilities: running read-only queries, showing toasts, opening modals, reading and writing plugin settings, detecting the current theme, accessing plugin-specific translations, and opening external URLs. Right now these hooks are exposed by the host as a runtime global (__TABULARIS_API__) — plugin bundles declare it as an external and reference it at build time. The plan is to publish a proper @tabularis/plugin-api package on npm so that plugin authors get type definitions, autocompletion, and a cleaner import experience out of the box.

IIFE bundles as the delivery format. Plugin authors build their components with Vite (or any bundler), targeting IIFE output with React and the host API as externals. The host provides these as globals — no duplicate React instances, no version conflicts.

Error isolation via per-contribution error boundaries. If a plugin component throws, a small badge appears in its place. The rest of the app keeps running. Other plugins in the same slot keep rendering.

Conditional rendering through two mechanisms: a driver field in the manifest that restricts a contribution to connections using a specific driver, and component-level filtering where the component itself returns null based on context values.

For the full developer reference, see the Plugin Guide. The wiki page on the plugin system has also been updated with the complete slot list, available hooks, and build instructions.

UI-only plugins and plugin modals

Plugins no longer need to be database drivers. v0.9.13 introduces support for UI-only plugins — packages that declare ui_extensions in their manifest without providing an executable or driver capabilities. This opens the door to visualization tools, data inspectors, and utility panels that work across any database.

The new usePluginModal() hook lets slot components open host-managed modals with custom React content. Useful for OAuth setup flows, configuration wizards, or anything that needs more space than a toolbar button provides.

I'm working on a set of demo plugins that showcase these capabilities in practice. Expect them in the coming days.

PostgreSQL: Range, Multirange, and Enum Types

This is @dev-void-7's work in PR #111 — 20 commits touching the Rust extraction layer, all focused on closing gaps in PostgreSQL type support. The same contributor who rewrote the PostgreSQL driver on top of tokio-postgres in v0.9.12 is back, this time expanding type coverage.

Enum types are now extracted properly. Previously they were passed through as raw bytes; now they resolve to their string label.

Range types (int4range, int8range, numrange, tsrange, tstzrange, daterange) are parsed from their binary wire format and displayed in standard PostgreSQL range notation — [1,10), (2024-01-01,2024-12-31], and so on. Empty ranges are handled correctly.

Multirange types (PostgreSQL 14+) follow the same approach. A multirange value is displayed as a set of ranges: {[1,5),[10,20)}.

Along the way, @dev-void-7 also hardened the existing extraction code. Null handling in composite types was tightened — fill_nulls now only fills remaining fields instead of overwriting the entire row. The split_at_value_len helper returns Option instead of panicking on unexpected input. Array extraction with zero dimensions returns an empty array instead of null. And the entire extract module gained a proper test suite: simple types, enums, arrays, composites, ranges, and multiranges all have dedicated test coverage now.

This is the kind of work that doesn't produce flashy screenshots but makes the difference between "it sort of works" and "it handles real data."

Settings: Modular Redesign

The Settings page was a single 800-line component. It did the job, but adding anything to it meant scrolling through a wall of JSX and hoping you didn't break something three sections away.

v0.9.13 splits Settings into dedicated tab components:

• General — basic application preferences
• Appearance — themes, fonts, zoom, and the new editor preferences (font family, font size, minimap toggle)
• Localization — language selection
• AI — provider configuration and model selection
• Plugins — plugin management (install, enable, configure, remove)
• Shortcuts — keyboard shortcut reference
• Logs — log viewer
• Info — version, links, credits

Each tab is its own file under src/components/settings/. The main Settings.tsx went from ~800 lines to ~40. Shared controls (SettingRow, SettingSwitch, SettingSelect, etc.) live in a dedicated SettingControls.tsx module, reused across all tabs.

The new editor preferences section in the Appearance tab lets you pick a font family (from a curated list of monospace fonts), adjust the font size, and toggle the minimap — all applied in real time to the SQL editor.

New Driver Capabilities: readonly and manage_tables

Two new capability flags for plugin authors:

readonly — when set to true, the driver is treated as read-only. All data modification operations (INSERT, UPDATE, DELETE) are disabled in the UI. The add/delete row buttons, inline cell editing, and context menu edit actions are hidden. Table and column management is also hidden, regardless of the manage_tables flag. This is useful for analytics databases, data lakes, or any source where writes don't make sense.

manage_tables — controls whether the table and column management UI (Create Table, Add/Modify/Drop Column, Drop Table) is shown. Defaults to true. Set it to false for drivers where DDL operations aren't supported or desirable.

Both flags are declared in the manifest's capabilities object and evaluated on the frontend to gate UI elements. Existing plugins are unaffected — the defaults preserve current behavior.

Error Modal

Native browser dialog() calls have been replaced with a proper in-app error modal. When an async operation fails — a query that errors out, a save that can't complete — the error is now displayed in a themed, keyboard-accessible modal instead of an OS-native popup that ignores your dark theme and can't be styled.

This affects error handling in both the DataGrid and the SQL Editor.

SQL Editor Fixes

A few annoyances that accumulated over the last couple of releases:

• Cursor position preserved — switching between tabs no longer resets your cursor to the top of the file. The editor remembers where you were.
• Autocomplete behavior — the suggestion popup no longer steals focus from the editor or fires in contexts where it shouldn't.
• Paste per instance — the paste action is now registered per editor instance, fixing a bug where pasting in one tab could affect another.
• Scrollbar styling — the custom scrollbar theme now applies consistently across all editor instances.
• Tab closing — simplified the tab close logic and removed the auto-create behavior that would spawn a new empty tab when you closed the last one.

Smaller Changes

• tailwind-merge removed — the dependency was unused and added weight to the bundle.
• TypeScript strictness — explicit type guards and casts replace several as unknown as X patterns across the codebase.
• Test coverage — new tests for SlotAnchor, PluginSlotProvider, SettingControls, pluginModuleLoader, and settings utilities.

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

Most of this release happened in Rust.

PostgreSQL: from sqlx to tokio-postgres

This one comes from dev-void-7 in PR #105 — the entire PostgreSQL driver has been rewritten on top of tokio-postgres. This was a long overdue move — sqlx served us well in the early days, but as Tabularis grew to support composite types, arrays, and more exotic column kinds, we kept running into limitations in how sqlx handles type extraction.

The migration touched roughly 1,200 lines across the Rust backend. Connection pooling, query execution, row extraction, dump and export — all rewired. The extract module was split into focused submodules (simple, array, composite, common) to keep things maintainable as more types get added.

From the user's perspective nothing should look different. Queries run the same, edits work the same, exports produce the same output. If something does behave differently, that's a bug — please open an issue.

One concrete fix that came out of this: columns reported as text or blob by the driver metadata but actually holding a different type (common with certain PostgreSQL extensions) are now handled through a known_type hint that overrides the wire metadata when we know better.

MiniMax AI Provider

octo-patch contributed MiniMax as a new first-class AI provider in PR #108. Two models are available: MiniMax-M2.7 and MiniMax-M2.7-highspeed.

It works exactly like the other providers — set your API key in Settings, pick a model, and the AI assistant uses it for SQL generation and query explanation. The backend talks to api.minimax.io/v1 using the same OpenAI-compatible format we already use for several other providers, so it slotted in cleanly.

This brings the supported providers to seven: OpenAI, Anthropic, OpenRouter, Ollama, OpenAI-Compatible, and now MiniMax.

JSON Editor in the Sidebar

Also from midasism (PR #107) — editing JSON columns used to mean typing raw JSON into a single-line text input and hoping for the best. Now there's a proper multi-line editor with:

• Live validation — errors show inline as you type
• Format button — pretty-prints your JSON with one click
• Proper sync — the editor state stays in sync with the underlying cell value without fighting React's effect cycle

This applies to JSON and JSONB columns in the sidebar editor. The grid cell itself still shows the compact representation, but as soon as you click into the sidebar you get the full editor.

Better PostgreSQL Error Messages

PostgreSQL errors can be verbose. The driver returns a one-line summary, then a wall of internal details (error codes, schema names, constraint definitions). Previously we dumped the whole thing into the error panel, which made it hard to spot the actual problem.

Now the error display splits the message: you see the brief summary first, and a Show details toggle reveals the rest. Small thing, but it makes a real difference when you're iterating on a query and getting syntax errors every few seconds.

MySQL JSON Columns

JSON columns in MySQL were showing as NULL in the data grid. The root cause was a misread of the field type bytes in the MySQL binary protocol — the JSON type flag was being skipped during extraction. Fixed by midasism in PR #107.

Smaller Changes

• Active database in window title — the Editor tab and the OS window title now show which database you're working in. Useful when you have multiple connections open.
• Provider icons in Settings — the AI provider dropdown now shows each provider's logo, making it easier to scan at a glance.
• Global alert modal — replaced the native browser dialog() calls with a proper in-app alert modal that respects theming and is keyboard-accessible.
• React stability fixes — several components had missing hook dependencies or unstable callback references causing unnecessary re-renders. Cleaned up.

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

Another community-driven language lands in Tabularis.

Chinese (Simplified)

Back when I built i18n in v0.6.0, I shipped English and Italian. Spanish came shortly after thanks to kconfesor's contribution in PR #30. Now GTLOLI has done the same for Chinese (Simplified) — a full translation, 879 keys, merged in PR #103.

So Tabularis now supports English, Italian, Spanish, and Chinese (Simplified). As before, the app picks your system locale automatically, or you can set "zh" in config.json.

Two out of four languages came from contributors. That's the kind of thing I was hoping for when I made the i18n files plain JSON with no build step. If you want to add your language, the bar is low — just copy one of the existing files and translate.

PostgreSQL Array Types

If you had integer[] or text[] columns in PostgreSQL, the grid would show raw strings and edits were broken. Fixed now — array columns parse correctly, and writing back works through JSON-to-ARRAY literal conversion. You edit ["a", "b", "c"] in the cell, the driver generates ARRAY['a','b','c'].

All Rust-side, no UI changes.

Inline Editing for Query Results

Running a SELECT in the editor used to give you a read-only grid. Now, if the query hits a single table, you can edit rows inline — same double-click behavior as table browsing.

Joins, aggregations, subqueries stay read-only. There's no safe way to map an edited cell back to a source row in those cases, so I'm not pretending there is.

JSON Copy and CSV Delimiter

• You can copy selected rows as JSON now. Set it as your default copy format in Settings if you want.
• The CSV delimiter is configurable — semicolons, tabs, pipes, whatever you need.

What's Next

I've been on the UI extensions branch for a few weeks, testing with the JSON Viewer and Google Sheets plugins. The two open items from the v0.9.10 post — error surfaces and theme tokens — are almost done.

I expect to ship UI extensions next week. After that, plugins won't be limited to backend drivers anymore — they'll be able to put components directly in the Tabularis UI.

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

v0.9.10 is a maintenance release — no headline features, just a set of fixes that were blocking clean usage after the multi-database work shipped in v0.9.8. Behind the scenes, feat/plugin-system-ui is heating up: the slot-based UI extension system is now far enough along to test with real plugins, and two of them are already running.

What Changed in v0.9.10

Multi-database window title

When you open a connection with multiple databases selected, the window title now reflects all of them. Previously it would show only the first database in the selection, which made it confusing to tell windows apart when you had two multi-database sessions open side by side.

Database selection in record operations

INSERT, UPDATE, and DELETE operations in the Editor now correctly target the selected database in a multi-database session. Before this fix, record mutations would fall back to the first database in the list regardless of which one was active in the UI, which was both surprising and dangerous.

Editor toolbar padding

The editor toolbar was using inconsistent padding that caused the toolbar items to feel cramped and misaligned with the surrounding UI. The spacing has been adjusted to match the rest of the interface.

Modal name input focus and placeholder

When a validation error occurs in a modal that has a name field, the input now receives focus automatically so the user can correct it without an extra click. The placeholder text was also updated to be more descriptive.

What Is in Progress: Plugin UI Extensions

Phase 2 of the plugin system was sketched out in a post from a few days ago. The design is slots: named insertion points in the host UI where a plugin can render a React component. Ten slots are currently defined:

Each slot receives a typed SlotContext — connection ID, driver name, table name, current row data, column name, and more depending on the slot. Plugin components are standard React components; they receive context and pluginId as props and return JSX. The plugin API (@tabularis/plugin-api) exposes utilities for read-only queries, toasts, theme detection, and reading plugin settings. That is the entire approved surface — direct Tauri access and DOM mutations outside the plugin subtree are blocked.

Manifests declare UI extensions alongside the existing driver configuration:

{
  "ui_extensions": [
    {
      "slot": "row-editor-sidebar.field.after",
      "module": "dist/index.js",
      "order": 50
    }
  ]
}

Modules are lazy-loaded when the target slot first mounts. Plugins that declare no ui_extensions are unaffected — everything is additive.

Testing with Two Real Plugins

The best way to find out what the slot API is missing is to write plugins against it. I am currently running two:

JSON Viewer

The JSON Viewer plugin (tabularis-json-viewer) targets two slots: row-editor-sidebar.field.after and row-edit-modal.field.after. When the active column holds a JSON or JSONB value, it renders a formatted, syntax-highlighted preview directly below the text input. No extra buttons, no modal — the preview appears inline, in both the sidebar and the modal editor.

{
  "id": "json-viewer",
  "ui_extensions": [
    { "slot": "row-editor-sidebar.field.after", "module": "dist/index.js", "order": 50 },
    { "slot": "row-edit-modal.field.after",     "module": "dist/index.js", "order": 50 }
  ]
}

This is a UI-only plugin — no driver, no backend process. It demonstrates that Phase 2 plugins do not need to speak JSON-RPC at all: if the only goal is to enhance the interface, the manifest just declares ui_extensions and ships a compiled JS bundle.

Google Sheets Plugin

The Google Sheets plugin (tabularis-google-sheets-plugin) already existed as a Phase 1 driver. With Phase 2, it picks up two UI slots:

• settings.plugin.before_settings — renders a "Connect with Google" OAuth button above the plugin's settings form. The button opens a browser, completes the OAuth flow, and writes the tokens back to the plugin settings automatically. Previously the user had to paste tokens by hand.

• connection-modal.connection_content — replaces the generic database field in the new connection modal with a Google Sheets spreadsheet selector. When the driver is google-sheets, the modal shows a search box and a list of the user's spreadsheets instead of a raw text input.

{
  "ui_extensions": [
    {
      "slot": "settings.plugin.before_settings",
      "module": "ui/google-auth.js",
      "order": 10
    },
    {
      "slot": "connection-modal.connection_content",
      "module": "ui/google-sheets-db-field.js",
      "order": 10,
      "driver": "google-sheets"
    }
  ]
}

The driver filter on the second slot is worth noting: connection-modal.connection_content contributions are only active when the selected driver matches. Other drivers do not see this component.

What Is Still Missing

Running two real plugins surfaced a few gaps that will need to land before the branch merges:

• Error surfaces — the error boundary catches crashes correctly, but the warning UI is currently just a text node. It needs a proper component with a "reload plugin" affordance.
• Stable theme tokens — the JSON Viewer needs to match the host's syntax-highlighting palette across light and dark mode. Right now it hardcodes colors. A public theme contract is the prerequisite.

None of these block testing, but all of them need to be resolved before the feature is ready for general plugin authors.

Testing with real plugins is also surfacing cases where the current ten slots are not enough. The connection modal and the settings panel are well covered, but there are interaction patterns — particularly around the data grid and the sidebar — where a plugin naturally wants to inject UI in a place that has no slot yet. I am keeping a list and will likely add a few more anchors before the branch merges.

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

The plugin system shipped in v0.9.0. Since then, the community has built Redis drivers, a Python CSV driver, DuckDB support. All of them work the same way: a process speaks JSON-RPC over stdin/stdout, and Tabularis handles the UI. The plugin never sees the interface. It sends data, the host renders it.

That was always half the story. A PostGIS driver can return geometry columns, but the data grid shows POINT(45.07 7.68) as plain text. A ClickHouse driver knows about materialized views, but there is no place to surface that in the sidebar. The plugin does the hard work and then hands it off to a UI that knows nothing about it.

I have been thinking about this since before v0.9.0 shipped. Today I am publishing the spec for Phase 2: UI extensions for plugins.

Stealing from WordPress (the good parts)

If you have built a WordPress plugin, you know the pattern. WordPress defines "hooks" — named points in the page where plugins can inject content. You register a function, WordPress calls it at the right place. The host controls the layout. The plugin controls the content.

I wanted the same idea for Tabularis, but adapted for React. Instead of PHP hooks in a template, we define slots — named insertion points inside existing components. A plugin registers a React component against a slot name, and the host renders it with the right props at the right location.

The difference from WordPress: everything is typed. The plugin declares its slots in the manifest. The host validates them. Each component receives a typed context object with exactly the data it needs. No string parsing, no global mutations, no innerHTML.

Concrete example: PostGIS

Today, if you open a row with a geometry column in the Row Editor sidebar, you see a text field with SRID=4326;POINT(45.07 7.68). Accurate, not useful.

With UI extensions, the PostGIS plugin could register a small map component in the row-editor-sidebar.field.after slot. The host renders the text field as before, and immediately below it, the plugin renders a Leaflet map with the point plotted. The plugin receives the column metadata and current value as props — it does not need to fetch anything.

Or think about export. Right now, exporting data to Parquet means copying queries to another tool. With a slot in data-grid.toolbar.actions, a plugin can drop an "Export" button right next to the filter controls. It gets the table name, current filters, column list, and connection ID as context. One click, done.

The eight slots

I went through the UI and picked eight places where plugin content makes sense without cluttering the interface:

In the row editor (modal and sidebar): After each field input. This is where validation hints, computed previews, and lookup widgets belong. There is also a slot before the modal footer buttons — good for batch actions like "fill from template."

Sidebar header: Extra buttons next to the row title in the Row Editor sidebar. "Copy as JSON", "View audit log", that kind of thing.

Data grid toolbar: Buttons alongside filter, sort, and limit. Export, analysis, visualization.

Context menu: Extra items in the right-click menu on grid rows. "Copy as INSERT", "Bookmark row", "Look up in external API."

Main sidebar footer: Global actions or status badges that persist across views.

Plugin settings: Per-plugin action buttons in the Settings page, next to the enable/disable toggle and settings gear. Diagnostics, custom configuration shortcuts, plugin-specific status indicators.

Eight slots. Not thirty. I would rather ship a small set that works well than scatter extension points everywhere and regret the maintenance cost.

How it works for plugin authors

You add a ui_extensions section to your manifest — the same JSON file that already declares your driver name, version, and capabilities. Each entry says which slot to target and which file contains the component:

{
  "ui_extensions": [
    {
      "slot": "row-editor-sidebar.field.after",
      "module": "./ui/GeometryPreview.tsx",
      "conditions": { "drivers": ["postgres"] }
    }
  ]
}

That is it. The host reads the manifest, lazy-imports the module when the slot first appears on screen, and renders the component with the right context props.

The component itself is a normal React component. It receives slotContext (column info, row data, connection details, driver capabilities — varies by slot) and pluginId. It returns JSX. There is no special framework to learn, no lifecycle to manage beyond standard React.

Plugins also get a small utility library (@tabularis/plugin-api) for common tasks: running a read-only query on the active connection, showing a toast, reading their own settings, checking whether the theme is dark. That library is the entire approved API surface. Direct Tauri calls and DOM manipulation outside the plugin's subtree are off-limits.

Nothing breaks

This was a hard requirement from the start. The ui_extensions field is optional. Every existing plugin — every manifest, every driver, every configuration — works exactly as before. The types do not change. The Rust backend does not change. The settings structure does not change.

On the frontend, the new slot anchors render nothing when the registry is empty. If you never install a plugin with UI extensions, the app behaves identically. Zero overhead.

The community has active plugin authors. I am not going to ask them to rewrite their manifests. Phase 2 is additive.

The hard problems

I do not want to pretend this is simple. There are real challenges.

Security. Plugin components run in the same React tree as the host. I chose this over iframe isolation because iframes make shared styling and context passing painful — and the whole point is seamless integration. The tradeoff is that a malicious plugin could theoretically poke at host state. The mitigation: plugins can only import from @tabularis/plugin-api. Direct Tauri access is blocked. Queries are read-only by default — write access requires an explicit permission flag in the manifest, and the user sees a prompt before granting it. This is a trust-but-verify model. It will need hardening over time.

Crashes. A broken plugin component cannot take down the host. Every slot contribution gets its own React error boundary. If a plugin throws, you see a small warning icon — not a white screen. If it throws three times in a minute, it is disabled for the session. This is defensive, but necessary. Third-party code will crash. The question is how gracefully.

Performance. Plugin modules are lazy-loaded. A plugin targeting the row editor sidebar adds zero bytes to the initial bundle if you never open the sidebar. The slot registry is empty at startup and only fills as plugins are activated and their target slots mount. The plugin ecosystem should grow without making the app heavier.

Ordering. Multiple plugins can target the same slot. Each contribution has an ordering weight, and the host sorts by it. If two plugins pick the same weight, the order is stable but arbitrary. For seven slots, this is fine. If the ecosystem grows to a point where ten plugins compete for toolbar space, I will revisit.

What is not in Phase 2

The spec covers the slot architecture, manifest format, context API, and security model. It deliberately does not cover:

• Full-page views — A plugin that wants to render an entire dashboard or monitoring panel needs a routing extension. That is a different problem.
• A stable theme API — Plugins can detect dark/light mode, but accessing the full design token set requires defining a public theme contract. Not ready yet.
• Scoped storage — Plugins have no way to persist state across sessions. A per-plugin key-value store is planned but not designed.
• Inter-plugin communication — A PostGIS preview in the sidebar might want to talk to a map view in the toolbar. There is no message bus for that. Will come if the use cases justify it.

These are future extensions, not prerequisites. The Phase 2 spec is self-contained — you can build useful plugins against it without any of them.

The point

Phase 1 solved "which databases can I connect to." Phase 2 starts solving "what can I do once I am connected."

A team using PostGIS gets geometry previews without me knowing anything about PostGIS. A company with a custom audit system can show compliance info next to each row. Someone who exports data to Parquet daily can do it from the toolbar.

The host provides the stage. The plugin does the work.

The full specification is published alongside this post. If you build plugins — or want to start — read it, file issues, tell me what is missing. The design is not final. The direction is.