Author here. I maintain Tabularis, the open-source client the post is about, so obviously I have a horse in this race.
> The part I'd most like to be challenged on: I claim the account/cloud trend in database clients is a funding-model artifact rather than a user need. The counterargument I keep hearing is that team workspaces and synced query history are genuinely valuable, and we just don't ship them. That's true — we don't, and the post lists what local-first costs us.
> One thing I checked before writing this because I knew someone here would: the only autonomous network call the app makes is the Tauri updater hitting GitHub releases. No telemetry, no crash reporting. The code is on GitHub if you want to verify.
The main thing in this release is a plugin system for database drivers. The short version: plugins are standalone executables that Tabularis spawns as child processes and talks to over JSON-RPC 2.0 on stdin/stdout.
I looked at dynamic libraries first but the cross-language ABI story is painful and would have locked plugin authors into Rust (or at least a C-compatible interface). The stdin/stdout approach means you can write a driver in whatever you want — the only contract is the JSON-RPC protocol. It also gives you process isolation for free, which matters when you're dealing with database drivers that can have their own native dependencies and failure modes.
The tradeoff is some serialization overhead per call, but in practice you're always waiting on network or disk anyway, so it hasn't been an issue.
First plugin out is DuckDB. I kept it out of core because of its binary size, but it's the database I get asked about most, so it felt like the right first target.
One thing I'm still thinking through: whether to pull the built-in drivers (MySQL, PostgreSQL, SQLite, MariaDB) out of core entirely and treat them as first-party plugins. It would make the core much leaner and the architecture more consistent, but it adds friction on first install. Currently leaning toward a setup wizard approach. Curious if anyone has dealt with a similar tradeoff.
I’m working on tabularis, a lightweight desktop database management tool designed for developers. It provides a modern interface for managing MySQL/MariaDB, PostgreSQL, and SQLite databases through a native desktop application. Built using Tauri v2 (Rust backend) and React 19 (TypeScript frontend), it offers native performance while maintaining the flexibility of web technologies.
It records escape sequences verbatim during capture, then handles them intelligently during replay.
Recording phase: All terminal output including ANSI escape codes, color sequences, and cursor movements are captured exactly as they appear - no processing or stripping occurs.
Replay phase:
- Decodes various escape formats (\u001b, \033, \x1b) back to actual
escape characters
- Filters out problematic terminal query sequences that could cause
artifacts
- Preserves visual escape sequences (colors, cursor positioning) for
faithful reproduction
So yes, escape sequences are recorded verbatim, but the replayer ntelligently processes them to recreate the original terminal experience while avoiding terminal corruption.
Not for now.
That's a side project and it is really new and still a bit rough around the edges; it’s only a few days old.
I’ll do it soon, meanwhile if you want to contribute you’re welcome :)
It's not related to asciinema, it's a totally different project.
Asciinema is a much more complex and structured project than mine; mine is the result of a few hours of free time—I was looking for a lighter solution.
Ouch sorry, I thought you meant 'it has the same features as ttyrec with JSON output.'
Regarding the issue, I need to go into a bit more detail; if you like, feel free to make a PR on GitHub.
Yeah, it’s just a side project for now, but I’m hoping to make it more solid over time.
As for C, I wanted to challenge myself and step away from what I usually do — try something a bit different.
- rewindtty record session.json # Runs a shell, records the session
- rewindtty replay session.json # Replays it step by step
Under the hood:
- Uses fork() to manage the pseudo-terminal
- Captures stdout/stderr with timestamps
- Stores everything in structured JSON for easy analysis, replay or transformation
Why I made this:
I wanted a minimal tool to track terminal interactions — for debugging, documentation, and reproducibility — without relying on heavier tools or external formats.
It’s still early, but the core works and I’d love feedback or suggestions.