tabularis

Every few weeks I get 2-3 CSV files and need to run a quick JOIN or aggregation. The options are always the same: fire up pandas, import into SQLite by hand, or use some janky web tool. So I built a plugin for Tabularis (my native DB GUI) that treats a folder of CSV files as a database. Drop your files in, every file becomes a table, column types are inferred automatically, and you get a full SQL editor. No code. No imports. Just SQL. Example: 3 CSV files (users, orders, products) → this query works immediately: SELECT u.name, u.country, COUNT(o.id) AS orders, ROUND(SUM(p.price * o.quantity), 2) AS total_spent FROM orders o JOIN users u ON o.user_id = u.id JOIN products p ON o.product_id = p.id GROUP BY u.id ORDER BY total_spent DESC The plugin is ~250 lines of stdlib Python (zero depend

I built Tabularis, a database GUI for MySQL/PostgreSQL/SQLite/MariaDB. The interesting bit is the plugin architecture: instead of shipping a monolith with built-in drivers, each database driver is a separate executable. The core process spawns it and communicates via JSON-RPC 2.0 over stdin/stdout. No shared libraries, no ABI concerns, process isolation for free. This means you can write a plugin in Rust, Go, Python, or anything that can read stdin and write JSON. The first community plugin is DuckDB. The app itself is Tauri 2 + React 19 – no Electron, no JVM. GitHub: https://github.com/debba/tabularis

Author here. Happy to answer questions. 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 i