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

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

Comments URL: https://news.ycombinator.com/item?id=47153091

Points: 2

# Comments: 0

  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

Comments URL: https://news.ycombinator.com/item?id=47138147

Points: 1

# Comments: 0

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.

The plugin guide and protocol spec are in the repo if you want to build one: https://github.com/debba/tabularis/blob/main/plugins/PLUGIN_...

Comments URL: https://news.ycombinator.com/item?id=47123186

Points: 1

# Comments: 1

    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)

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

Comments URL: https://news.ycombinator.com/item?id=47105491

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47009882

Points: 1

# Comments: 0

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.

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.

Comments URL: https://news.ycombinator.com/item?id=46868322

Points: 3

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=46845238

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46823432

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46806752

Points: 1

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=46791944

Points: 1

# Comments: 0

I built debba.sql, a lightweight, cross-platform database manager because I wanted a native, fast tool for quick data edits without the heaviness of Electron-based giants or Java IDEs.

The interesting part? This project started as an experiment in vibe coding. I utilized an AI agent to handle the entire scaffolding and heavy lifting of the implementation. We went from an empty directory to a working app with SSH tunneling, schema introspection, and data editing in record time. It allowed me to focus purely on the architectural decisions, UX "vibe", and solving my specific pain points.

The Tech Stack: * Frontend: React 19 + TypeScript + Tailwind CSS (using Monaco Editor for SQL) * Backend: Rust Tauri v2 (for native performance and small binary size) * Database Access: SQLx (pure Rust, async driver)

Current Features: * Multi-DB Support: PostgreSQL, MySQL/MariaDB, and SQLite. * SSH Tunneling: Built-in support for connecting via bastion hosts (supports key/agent/password auth). * Native Performance: Fast startup (~10MB binary) and low memory footprint. * SQL Editor: Full syntax highlighting and execution. * Data Grid: Inline editing, row deletion, and easy "New Row" insertion. * Schema Tools: Visual "Create Table" wizard (DataGrip style) and introspection. * Export: Native CSV/JSON export.

Why I built it: I often need to jump into a DB via SSH to run a query, edit a specific cell, or check a schema. I wanted something that opens instantly and feels like a native system utility, not a web browser tab.

Roadmap / Help Wanted: It's currently in Alpha (v0.1.0). I'm looking for feedback, bug reports, and contributions! Next on the list: * Multiple Query Tabs * Visual Query Builder * Dark/Light mode toggle

The code is open source. Check it out here: https://github.com/debba/debba.sql

Let me know what you think about the tool or the AI-assisted dev process!

Comments URL: https://news.ycombinator.com/item?id=46772592

Points: 2

# Comments: 0

  The extension handles both angle bracket and square bracket syntax, mixed HTML content, and all FreeMarker directives through a custom tree-sitter grammar rather than regex.

  GitHub: https://github.com/debba/zed-freemarker
  Zed Extensions: Search "FreeMarker"

  Built it mainly for my own projects, but figured others maintaining legacy systems might find it useful.

Comments URL: https://news.ycombinator.com/item?id=46599821

Points: 1

# Comments: 0

Repo:

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

Releases:

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

Comments URL: https://news.ycombinator.com/item?id=46395804

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46175713

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45998434

Points: 2

# Comments: 0

Repo & downloads here:

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

https://github.com/debba/storytel-player/releases/tag/v1.0.7

Would love feedback and suggestions from the community.

Comments URL: https://news.ycombinator.com/item?id=45476334

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45448019

Points: 1

# Comments: 1