debba

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 dependencies). It works because Tabularis has an open plugin protocol — JSON-RPC over stdin/stdout — so any data source can be a database.

Plugin: https://github.com/debba/tabularis-csv-plugin Tabularis: https://github.com/debba/tabularis

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

What's new n v9:

    GitHub Notifications panel — a full accordion UI to browse and manage your notifications directly from the tray

    GitHub Actions workflow runs — see the status of your CI/CD pipelines at a glance

    Refresh button — manually refresh notifications without waiting for the next poll

    Mark as read on open — notifications reload automatically when you open them

    Scrollable & paginated list — handles large notification lists without cluttering the UI

    Translations — added German , Spanish , and French 

    Bug fixes — properly clears timers and nullifies managers on destroy (no more memory leaks)

Feedback on the UI styling from last time was noted too and you can check here.

Install it from GNOME Extensions: https://extensions.gnome.org/extension/9307/github-tray/

Source: https://github.com/debba/github-tray-gnome-extension

As always, join the Discord for feature requests and discussion: https://discord.gg/YrZPHAwMSG

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 using SQLx and a mix of information_schema + pg_catalog queries, but I’m sure there are better patterns I’m missing.

I’d love feedback from people who: - Have written serious Postgres introspection queries - Have opinions on how Postgres clients should represent schemas and types - Have been frustrated by existing Postgres GUIs

Repo (Apache 2.0): https://github.com/debba/tabularis

Happy to learn, iterate, and fix wrong assumptions.

Database tooling is in a strange place.

On one side, there are powerful, commercial tools that try to be everything at once. They support every engine, every workflow, every edge case. The result is often a heavy application with long startup times, dense UIs, and a constant feeling that you’re navigating a system rather than inspecting data.

On the other side, there are lightweight or open-source tools that are fast and simple—but quickly hit a wall as soon as you need anything beyond basic querying.

What’s missing is not raw functionality, but UX discipline.

Many database managers feel like they’ve grown without ever being pruned. Features accumulate, interactions become implicit, and simple actions require unnecessary context switching. Over time, you end up paying a UX tax: more clicks, more waiting, more mental overhead.

For developers who frequently jump between databases or just want to explore data quickly, this friction adds up fast. It’s often easier to drop back to the terminal, even when a graphical tool should be the better option.

I started experimenting with a small database manager mainly to address this gap: fast startup, explicit actions, minimal abstraction, and a UI that stays out of the way.

That experiment eventually became debba.sql, an open-source database manager written in Rust and built with Tauri. It’s intentionally limited in scope and still very much a side project.

The more interesting question, though, is broader than any single tool:

Why are we still accepting poor UX as the default for database tooling?

If you’re curious, feedback is welcome—but even more welcome is the discussion around what “good UX” for developer tools should actually look like.

Link repo: https://github.com/debba/debba.sql

Ideas, stars and contributions are welcome.

Hi HN, I’ve been working on a desktop client for Storytel, as there is currently no official app for PC/Mac. I wanted something that felt more "native" than a browser tab and included features like offline listening and system tray integration. The stack: • Frontend: React 18, Tailwind CSS, Vite. • Backend: Fastify (embedded within the app to handle API logic and streaming). • Desktop: Electron with TypeScript. One of the challenges was managing the streaming API and session persistence in a way that feels seamless across different OSs. It currently supports Windows, macOS (x64/ARM64), and Linux. It is still a work in progress, but the core player and library management are stable. Any feedback on the architecture (especially the Fastify-within-Electron approach) or the app itself would be greatly appreciated.

Repo:

https://github.com/debba/storytel-player

Releases:

https://github.com/debba/storytel-player/releases