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

SSH That Knows How to Ask

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

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

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

Detach Your Results Into Their Own Window

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

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

A Smarter SQL Editor

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

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

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

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

Collapse Notebook Sections Individually

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

A Startup Script Per Connection

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

Three New Community Drivers

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

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

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

Oracle and Dameng SQL Block Splitting

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

Correctness, Across the Board

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

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

Smaller Things

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

Thanks

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

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

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

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

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

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

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

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

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

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

The mess we'd been living with

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

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

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

1Password, and being honest about what this is

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

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

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

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

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

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

1Password as a secret manager for GitHub

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

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

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

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

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

What that buys you, concretely:

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

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

The part that already works today: SSH

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

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

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

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

What we plan to do with it

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

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

Thanks

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

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

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

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

Results, Colored by Type

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

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

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

Tabs That Wear the Connection's Color

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

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

A New Theme: Gruvbox

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

A Workspace That Remembers

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

Copy CSV With (or Without) Headers

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

Louder MCP Approvals

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

Driver-Aware Kubernetes Connections

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

A Community Informix Driver

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

Smaller Things

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

Thanks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The interesting case is the fourth database.

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

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

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

The two options I didn't take

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

There are two problems with it here.

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

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

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

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

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

The boring option

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

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

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

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

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

The wire

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

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

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

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

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

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

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

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

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

The part that is actually hard

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

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

So two things must be true:

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

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

The caller side looks like this:

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

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

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

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

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

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

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

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

A call becomes:

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

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

Two bugs that showed up

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

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

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

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

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

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

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

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

The fix is one line at spawn time:

.kill_on_drop(true)

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

The registry bug

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

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

registry.insert(manifest.id, driver);

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

Nothing stopped a plugin from declaring this:

{ "id": "mysql" }

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

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

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

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

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

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

About the word "sandboxed"

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

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

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

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

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

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

Installing a plugin

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

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

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

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

What held up

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

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

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

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

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

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

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

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

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

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

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

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

Why Tolgee, specifically

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

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

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

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

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

What this is not

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

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

The part we're really here for: community translations

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

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

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

Here's how we see it rolling out:

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

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

Thanks

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

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

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

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

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

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

The part that makes this one different

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

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

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

What we're actually going to do with it

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

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

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

Thanks, and the usual honest note

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

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

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

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

The Tabularis Team

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

Five external contributors land in this tag.

Notebooks You Can Actually Manage

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

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

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

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

Query Progress, In Real Time

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

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

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

A Grid That Scrolls on Wide Tables

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

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

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

Autocomplete That Reads Your Clauses

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

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

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

Visual EXPLAIN Gets Honest Numbers

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

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

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

SSL for Plugin Drivers

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

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

Redis (Go) Plugin: v0.4.1

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

Smaller Things

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

Thanks

Five external contributors land in v0.13.2.

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

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

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

@gzamboni (Giovani Zamboni) shipped Redis (Go) plugin v0.4.1 (#314), fixing usernameless Redis connections.

@VincentZhangy is new to the contributor list with the scroll-bar button fix (#315). Welcome.

If you keep notebooks and could never find them again, run long scripts and want to see them progress, scroll wide tables and feel the lag, lean on autocomplete across multiple databases, or read Visual EXPLAIN and want the numbers to be honest — this is the upgrade.

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

We gave Fable 5 a single day after it dropped and accidentally shipped a video game.

It's called Tabularis Run — a tiny Super Mario-style platformer that runs in your browser, themed entirely around Tabularis. No download, no account, no catch. It's free, it's open source, and the whole point is to have a bit of fun — and maybe put Tabularis in front of a few people who'd never have clicked on a database client otherwise.

👉 Play it right now → game.tabularis.dev

How it plays

Run, jump, climb network cables and fire SQL "queries" across three worlds — SQLite, MySQL and PostgreSQL — each one ending in a boss fight against that database's mascot: a hummingbird, a dolphin, and an elephant.

• 12 levels, including a vertical WAL ascent climb
• 27 hidden plugins to collect, plus power-ups — an MCP gun, an Index shield, a Vertical Scaling RAM stick
• SQL flavor everywhere: COMMIT; is the flag at the end of a level, ROLLBACK is what happens when you die, BEGIN; marks your checkpoints
• 4 playable characters: TAB, PRIMARY KEY, CURSOR and TRIGGER
• Plays on desktop (keyboard or gamepad) and mobile (touch controls)

Every pixel is procedural — the sprite art is drawn from character grids, the music is WebAudio chiptune, there are zero external assets and zero runtime dependencies. It's just vanilla JavaScript and a <canvas>. Beat it and you can share a generated score card straight to your socials.

Full disclosure: we're not game developers

Let's be honest about how this got made, because it matters.

We're not game designers. We're not really game developers either. A good chunk of Tabularis Run is straight-up vibe-coded — we described what we wanted, Fable 5 wrote a lot of it, and we steered. The physics are tuned by feel, the level design is whatever felt fun at 1am, and an actual professional would probably wince at some of the choices.

And that's kind of the point. It's the same thing we keep writing about on this blog — we handed Fable 5 a real task on the Tabularis codebase and it opened an 1,800-line PR in 30 minutes. A whole game in a day is just the playful version of the same shift: the gap between "we have an idea" and "it's live on the internet" is collapsing.

Want to build a world?

Here's where you come in.

The game is fully open source, and we'd genuinely love for people who know what they're doing to jump in. Tweak the physics, fix our questionable level design, add enemies, or — the fun one — let's design entirely new worlds together. The engine already supports three; there's no reason it has to stop there. New database mascots, new mechanics, new bosses: it's all on the table.

👉 Game source on GitHub → github.com/TabularisDB/game

The codebase is small and approachable on purpose: levels are authored in a little grid DSL, sprites are character grids, and there's a test suite that validates every level is actually beatable. PRs are very welcome, and if you want to riff on an idea first, the Discord is the place.

Why a game, though?

Because Tabularis grows when people hear about it — and a game travels in places a database client never will. Someone shares a high score, a friend asks "wait, what's Tabularis?", and the curve nudges upward.

So if you enjoy it, the single best thing you can do is share it — a clip, a screenshot, your best run. Have fun with it. That's the whole brief.

And if you came here for the actual database client: Tabularis is a free, open-source database client for the AI era — one fast, native app for SQLite, MySQL, PostgreSQL and many more. The game is just a love letter to it.

The Tabularis Team

Daily Dev Experiment — a short series where we hand a real task to an AI on the Tabularis codebase and report exactly what happened. No staged demos. Today's run got a little out of hand.

We asked Fable 5 (Anthropic's new model) to add a command-line interface to the app. That's less trivial than it sounds: this is a Tauri app — Rust backend, React frontend — so "a CLI" means reaching every saved connection (keychain passwords, SSH/K8s tunnels, plugin drivers) without booting the GUI or starting the Tauri runtime at all.

One prompt. A coffee break. A draft PR waiting at the end of it.

Here's what was in it.

The numbers

We've spent longer naming a variable.

What we expected

A coherent set of clap subcommands, addressed by connection id or name:

The detail we like most: query picks its mode from the invocation. SQL argument → one-shot. Piped stdin → executes the piped statement. Interactive TTY with no SQL → drops into a proper SQL shell.

# one-shot query, pipe-friendly
tabularis query my-db "select id, name from customers" --format csv > out.csv

# pipe a statement in
echo "select count(*) from orders" | tabularis q my-db

# no SQL on a TTY → drop into a proper SQL shell
tabularis query my-db

The interactive shell is backed by rustyline: line editing, persistent history (cli_history.txt in the app config dir), multi-line statements that fire on a terminating ;, Ctrl-C drops the current buffer, Ctrl-D exits. Plus psql-style meta commands:

\l    list databases        \f table|json|csv   output format
\dn   list schemas          \limit N            row limit (0 = unlimited)
\dt   list tables           \schema NAME        set schema
\d T  describe table        \use DB             switch database
\q    quit                  \?                  help

Result data goes to stdout, logs go to stderr — so piping stays clean, and you get a non-zero exit code on failure. Exactly the kind of detail a human means to remember and usually forgets.

It even kept the GUI-launch fallback intact: macOS still passes junk like -psn_* to the binary on launch, and that must keep booting the GUI — while a misspelled subcommand should surface clap's error instead of silently opening a window. It threaded that needle, and wrote tests asserting the exact clap error kinds that fall through to the GUI versus the ones that don't.

What we did NOT expect

1. It found the refactor before writing a single feature.

The app already ships an MCP server, and that server already knew how to resolve a saved connection — decrypt the keychain password, open the SSH/K8s tunnel, register the right plugin driver. Instead of duplicating all of that for the CLI, Fable 5 dug through the codebase, realized the logic was buried inside mcp/mod.rs, and pulled it out into a shared headless.rs module that both the MCP server and the new CLI consume. The MCP server now just wraps the shared helpers with its JSON-RPC error type — zero behavior change on that side.

That's 242 lines deleted from mcp/mod.rs and a 214-line module born. It's the refactor we would have done — unprompted, because it understood why duplicating connection resolution was the wrong move.

It also didn't dump everything into one file. The old 52-line cli.rs became a real module:

src-tauri/src/cli/
├── mod.rs       clap definitions, GUI-fallback logic     (182 lines)
├── run.rs       command dispatch + execution             (338 lines)
├── repl.rs      the interactive shell                    (282 lines)
├── output.rs    table / JSON / CSV rendering             (138 lines)
├── install.rs   install-cli symlink logic                 (97 lines)
└── *_tests.rs   args, output, run, install               (442 lines)

2. It fixed two real bugs that were already there.

• keychain_utils was logging with println!, dumping straight to stdout. Harmless in a GUI — silently corrupting any piped CSV/JSON the moment a CLI exists. And it was bypassing the in-app log buffer too. It rerouted everything through the log crate.
• Headless processes never called sqlx::any::install_default_drivers(), so the default connection-test path panicked. It installed the drivers in the shared headless::register_drivers() — which also quietly fixed the existing --mcp mode.

Neither was in the prompt. It found them because it actually traced the execution path from "user pipes a query" to "bytes hit the terminal" and noticed what would break along the way.

3. It handled multi-database connections properly.

Multi-db connections used to resolve to their first database, which made the others unreachable outside the GUI. Every db-scoped command now takes -d/--database, and the shell's \use <db> doesn't just flip a variable — it validates the switch with a connection test before applying it, and the prompt shows where you are (Demo · MySQL:blog_demo>). Under the hood it reuses the GUI's per-call database-override semantics (DatabaseSelection::Single) instead of inventing a parallel mechanism.

4. It tested its own work against a live database.

The 37 unit tests aren't padding: clap parsing (including the GUI-fallback error kinds), table/CSV/JSON rendering (column alignment, control-character escaping, CSV quoting), limit and database-override semantics, and the install-cli symlink logic — idempotency, refusal to clobber a foreign file, --force.

Then it went further: it ran the new shell against a real MySQL connection, switched across the three demo databases with \use, eyeballed the table/CSV/JSON output, and fixed the formatting it didn't like — before handing over the PR.

So... do we trust it?

No. It's a draft PR and we're reviewing every line before anything ships. There are real limitations — which, to its credit, it flagged itself in the PR description:

• On Windows release builds the binary has no attached console (windows_subsystem = "windows"), so CLI output is invisible there. Same constraint the --mcp mode always had.
• Each shell statement runs on its own pooled connection, so session state — SET, transactions, temp tables — doesn't persist between statements. It even documents that caveat inside \?.

But here's the part that stuck with us: the review is genuinely worth doing. This isn't autocomplete spitting out a function body. It's an agent that read the architecture, found the seam we'd have found, refactored toward it, and cleaned up two messes on the way out — then wrote 37 tests and a PR description more thorough than most humans bother with.

Two years ago this was Tab-complete. Today it's a coworker whose work we have to code-review.

👉 Read the full PR — every line, the real description: #313

Where this is going

This experiment isn't a side quest — it's the direction. We're building a database client that's native to this new workflow: a built-in MCP server so agents like the one in this post can work against your databases, with approval gates, a read-only mode, and a full audit log so they do it on your terms. An AI assistant that also runs on open-source models — locally via Ollama, with zero schema data leaving your machine. And now a CLI, born from that same headless core.

An agent wrote today's feature. The point is that tomorrow, your agents get a first-class, safe way to use it.

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.app, 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.app 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.