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

https://github.com/debba/tabularis 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.

I’m building Tabularis, a native database client (Rust + Tauri). MySQL support is in a good place, but PostgreSQL has been much harder to get right — not for performance, but for introspection. Postgres “works”, but once you go beyond basic tables and columns, things get tricky fast. Some gaps I’ve hit so far: - Type system: Arrays, JSON/JSONB, domains, custom types, ranges, geometric types — most clients either flatten them to text or handle them inconsistently. - Schema introspection: information_schema only goes so far. pg_catalog is powerful but subtle. Triggers, functions, partitioned tables, inheritance, materialized views all require special handling. - Postgres-specific UX: CTE-heavy queries, EXPLAIN ANALYZE output, extensions like PostGIS / pgvector — these don’t map cleanly to generic DB abstractions. I’m currently u

Hi HN, We’ve just added theme support to Tabularis, our lightweight, developer-focused database management tool. It already lets you: • Browse tables and data • Run SQL queries • Create and edit table DDL • Use experimental AI features (query explain / query generation) • Expose configured DB connections via an MCP server for AI tooling With the new UI customization features, you can now: • Switch themes (light, dark, custom) • Configure font family • Adjust font size My goal is to keep the tool fast, distraction-free, and flexible for different developer setups. Open source and actively evolving. Feedback from developers who care about minimal, efficient database tools is very welcome.