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

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

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

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

Here are the invoices I found worth reading twice.

Two database stacks, on purpose

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

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

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

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

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

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

rustls, and the OpenSSL that stayed

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

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

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

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

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

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

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

The crypto shelf

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

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

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

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

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

russh and ssh. Both.

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

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

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

The 2⁵³ toll booth

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

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

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

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

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

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

The supply-chain boundary

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

Would I choose them again?

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

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

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

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

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

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

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

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

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

The Row Editor Becomes a Sidebar That Follows You

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

A Polished Rail, and Split View Grows to Four

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

SQL Formatting, Your Way

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

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

The Editor Knows Where Your Cursor Is

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

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

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

An Opt-In Nightly Channel in the Updater

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

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

PostgreSQL Learns pgvector

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

The Sidebar Notices When a Database Disappears

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

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

Tabularis Fala Português

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

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

Smaller Things

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

Thanks

Nine external contributors land in v0.17.0.

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

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

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

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

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

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

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

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

A plan visualiser needs a plan, not a database.

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

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

How the feature was tied to the app

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

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

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

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

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

The extraction test

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

Takes raw EXPLAIN output; never runs a query.

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

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

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

Where should the parsers live?

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

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

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

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

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

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

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

What the extraction exposed

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

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

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

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

Three entry points, and the bill

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

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

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

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

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

One repository or two?

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

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

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

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

The second host

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

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

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

This was technically accurate and practically useless.

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

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

Would I draw the boundary again?

Yes, and earlier.

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

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

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

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

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

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

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

The sentence that decided the architecture was this:

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

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

The program behind the pixels

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

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

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

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

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

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

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

And then there is size.

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

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

The harder comparison is native

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

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

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

So why not native? Because native to what?

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

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

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

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

This is the trade I eventually wrote down:

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

Now for the seams.

You do not ship a browser. You inherit three.

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

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

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

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

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

The Linux webview lottery

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

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

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

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

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

The 94 MB exception

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

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

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

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

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

You own the glibc floor

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

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

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

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

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

Every result page pays the IPC tax

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

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

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

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

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

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

Would I choose Tauri again?

Yes.

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

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

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

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

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

Just budget for the seams.

The AppImage users may now open an issue.

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

A Hosted Plugin Registry and a New Connection Catalogue

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

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

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

Two New Community Drivers: Elasticsearch and Cloudflare D1

Two community-built drivers joined the registry this cycle.

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

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

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

Kubernetes Tunnels, With Your kubectl and Your kubeconfig

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

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

Backups That Take Themselves

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

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

Run the Statement Under Your Cursor

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

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

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

AWS RDS IAM Authentication for MySQL

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

Stored Procedures Show All Their Result Sets

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

Tabularis Speaks Korean

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

Smaller Things

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

Thanks

Eleven external contributors land in v0.16.0.

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

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

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

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

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

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

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

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

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

Virtualized, and still janky

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

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

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

Where the work was going

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

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

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

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

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

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

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

The fix is one memo boundary

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

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

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

So the props are split by volatility.

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

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

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

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

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

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

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

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

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

Proving it, not vibing it

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

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

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

The harness records two metrics:

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

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

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

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

The numbers

Scrolling, 1,000-row table:

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

The call counts explain the ratio:

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

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

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

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

A bad mock invalidated every row

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

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

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

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

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

What's deliberately not done

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

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

If you have a slow virtualized grid

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

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

Source and reproduction

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

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

Import Connections From the Client You're Leaving

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

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

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

Folders Inside Folders

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

The workflow got the attention the data model change deserved:

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

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

Select Many, Act Once

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

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

Exports That Don't Leak Passwords

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

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

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

ENUM Columns Become Dropdowns — on Both MySQL and PostgreSQL

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

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

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

MCP Safety: EXPLAIN ANALYZE Is Not a Read

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

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

Windows Stops Flashing Terminals

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

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

Grid and Editor Refinements

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

Tabularis Speaks Tagalog

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

Smaller Things

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

Thanks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The honest part: it's not wired up yet

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

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

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

What will change for you

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

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

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

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

The usual thank-you, because it keeps being deserved

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

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

The Tabularis Team

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

Manage Stored Routines, Not Just Tables

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

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

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

A Connection in Its Own Window

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

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

Confirm Before You Wipe a Table

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

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

PostgreSQL Materialized Views

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

Find Things by Typo

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

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

Know Exactly How Many Rows

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

MySQL Through Warpgate

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

Correctness, Across the Board

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

Smaller Things

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

Thanks

Most of v0.14.0 is community work again.

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

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

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

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

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

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

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

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

When the tool sponsors the tool

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

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

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

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

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

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

The Tabularis Team

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

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

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

SQL fails differently

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

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

The inversion

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

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

Reading has to get cheaper

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

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

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

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

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

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

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

SSH That Knows How to Ask

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

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

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

Detach Your Results Into Their Own Window

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

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

A Smarter SQL Editor

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

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

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

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

Collapse Notebook Sections Individually

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

A Startup Script Per Connection

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

Three New Community Drivers

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

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

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

Oracle and Dameng SQL Block Splitting

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

Correctness, Across the Board

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

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

Smaller Things

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

Thanks

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

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

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

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

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

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

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

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

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

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

The mess we'd been living with

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

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

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

1Password, and being honest about what this is

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

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

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

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

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

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

1Password as a secret manager for GitHub

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

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

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

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

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

What that buys you, concretely:

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

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

The part that already works today: SSH

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

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

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

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

What we plan to do with it

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

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

Thanks

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

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

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

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

Results, Colored by Type

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

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

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

Tabs That Wear the Connection's Color

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

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

A New Theme: Gruvbox

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

A Workspace That Remembers

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

Copy CSV With (or Without) Headers

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

Louder MCP Approvals

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

Driver-Aware Kubernetes Connections

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

A Community Informix Driver

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

Smaller Things

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

Thanks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The interesting case is the fourth database.

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

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

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

The two options I didn't take

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

There are two problems with it here.

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

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

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

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

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

The boring option

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

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

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

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

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

The wire

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

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

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

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

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

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

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

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

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

The part that is actually hard

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

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

So two things must be true:

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

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

The caller side looks like this:

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

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

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

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

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

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

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

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

A call becomes:

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

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

Two bugs that showed up

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

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

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

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

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

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

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

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

The fix is one line at spawn time:

.kill_on_drop(true)

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

The registry bug

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

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

registry.insert(manifest.id, driver);

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

Nothing stopped a plugin from declaring this:

{ "id": "mysql" }

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

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

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

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

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

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

About the word "sandboxed"

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

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

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

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

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

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

Installing a plugin

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

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

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

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

What held up

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

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

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

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

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

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

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

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

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

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

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

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

Why Tolgee, specifically

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

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

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

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

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

What this is not

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

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

The part we're really here for: community translations

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

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

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

Here's how we see it rolling out:

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

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

Thanks

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

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

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

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

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

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

The part that makes this one different

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

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

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

What we're actually going to do with it

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

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

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

Thanks, and the usual honest note

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

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

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

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

The Tabularis Team

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

Five external contributors land in this tag.

Notebooks You Can Actually Manage

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

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

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

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

Query Progress, In Real Time

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

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

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

A Grid That Scrolls on Wide Tables

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

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

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

Autocomplete That Reads Your Clauses

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

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

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

Visual EXPLAIN Gets Honest Numbers

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

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

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

SSL for Plugin Drivers

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

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

Redis (Go) Plugin: v0.4.1

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

Smaller Things

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

Thanks

Five external contributors land in v0.13.2.

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

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

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

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

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

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

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

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

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

👉 Play it right now → game.tabularis.dev

How it plays

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

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

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

Full disclosure: we're not game developers

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

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

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

Want to build a world?

Here's where you come in.

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

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

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

Why a game, though?

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

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

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

The Tabularis Team

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

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

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

Here's what was in it.

The numbers

We've spent longer naming a variable.

What we expected

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

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

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

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

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

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

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

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

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

What we did NOT expect

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

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

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

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

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

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

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

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

3. It handled multi-database connections properly.

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

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

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

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

So... do we trust it?

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

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

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

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

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

Where this is going

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

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

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.