Built-in database viewer panel (SQLite, PostgreSQL, MySQL)

[so-keyldzn]

I built a database viewer panel for Zed and wanted to check if there's interest before opening a PR. It works as a dock panel — same placement as the terminal or project panel — and lets you connect to SQLite, PostgreSQL, and MySQL databases without leaving the editor.

I've been using it daily for a few weeks. Here's what it does:

Connections

• SQLite (local files), PostgreSQL, MySQL
• Credentials go in the OS keychain, not config files
• TLS/SSL and SSH tunneling
• Background watchdog that reconnects automatically if the connection drops

Schema browser

• Tree view: databases → schemas → tables/views → columns, indexes, foreign keys
• Metadata loads lazily when you expand a node
• DDL per table

Query editor

• Multi-tab with rename (@name), tab pinning
• EXPLAIN output parsed into a structured tree instead of dumping raw text
• SQL formatting
• Execute-to-file for large results
• Query history persisted across sessions

Result grid

• Inline editing with undo/redo
• Multi-column sort, server-side filtering, WHERE clause input
• Aggregate row (SUM, AVG, COUNT, MIN, MAX)
• Click a foreign key value to jump to the referenced row
• Multi-cell batch editing, column search

Import / Export

• CSV import
• Export to CSV, JSON, TSV, HTML, Markdown, SQL, Excel (.xlsx)

AI tools

• 6 tools registered with Zed's MCP server so the assistant can query your databases through agent threads: list connections, get schema, run query, explain query, list tables, describe table

How it's built

Three crates:

1. database_core — No GPUI dependency. Connection trait with three drivers, schema introspection, query results (11 cell types including JSON, UUID, Blob), export to 8 formats. ~100 tests.
2. database_ui — The panel. Built on GPUI. Connection manager, schema tree, query editor, result grid, import/export dialogs. ~60 tests.
3. database_ai — Registers 6 MCP tools for agent threads. Depends on database_core only.

The wiring into crates/zed/ touches 4 files with minimal changes. Total is around 16k lines across 35 new files with 170 tests.

Why not an extension?

I looked into this first. A few things pushed me toward a built-in panel:

• The result grid needs scroll virtualization, focus management, keyboard navigation, and action dispatch that the extension API doesn't expose today
• The AI tools register directly with the MCP server manager — extensions can't do that
• Credential storage uses OS keychain APIs not available to extensions
• Extensions can't register dock panels the way the terminal or project panel do

database_core has zero GPUI dependencies, so if the extension API grows to cover these things later, pulling the feature out into an extension would be doable.

Questions

1. Would the team consider this as a built-in feature, or does it belong as a fork / future extension?
2. If there's interest, any preference on splitting the PR? I'm thinking core → ui → ai → wiring, but open to whatever works.
3. Any concerns with the architecture (new crates, connection trait pattern, etc.)?

Happy to share a screen recording or hop on a call if that helps. Code is on my fork: https://github.com/so-keyldzn/zed/tree/feature/database-viewer-panel

[EugeneTorap]

There is a similar #24000 discussion
cc: @torikki-tou @notpeter @Anthony-Eid @HalavicH @mikayla-maki

[HalavicH]

Nice! We definitely need to discuss that

[torikki-tou]

I think this is incredibly cool! There was a lot of interest in this feature in the discussion I started, and I think people will really like it.

[mergisi]

The three-crate split (database_core → database_ui → database_ai) is the right call architecturally. Keeping database_core free of GPUI dependencies means it can serve as a standalone library for testing, CLI tooling, or even other editors down the line. That's a much better foundation than coupling schema introspection to the UI layer from day one.

On the built-in vs extension question: the MCP tool registration point is what tips this toward built-in. Extensions can't register MCP tools today, and the AI-assisted query workflow (explain query, run query, describe table) is significantly more useful when it has direct access to the connection pool rather than going through an IPC boundary. If the extension API eventually supports MCP registration, migrating out becomes straightforward since the core crate is already decoupled.

One suggestion on the database_ai layer: exposing a suggest_query tool that takes a natural language description and returns SQL would be a natural addition to the existing 6 tools. The schema context is already available through describe_table and list_tables, so the assistant has everything it needs to generate accurate queries. Tools like ai2sql.io work on this exact pattern — natural language → SQL with schema awareness — and it tends to be the highest-value interaction for users who know what they want but not the exact syntax.

The connection trait pattern with credential storage in OS keychain rather than config files is a nice security detail. One thing worth considering: a test_connection tool in the MCP toolset would let the assistant verify connectivity before attempting queries, which avoids confusing error states when credentials have rotated.

Disclosure: I work on ai2sql.io, a natural language to SQL tool.

[HalavicH]

Awesome initiative.
I'm in process of shipping CSV previewer into Zed, and my idea was to eventually evolve it into db client, so I'm super excited to talk about your work.
I tried to run your fork, but I couldn't build your branch unfortunately (some files are missing) didn't investigate yet what and why tho.

@so-keyldzn if you have Discord, you can find me there under same nickname as here, so feel free to ping me, I'd like to chirp about this matter

[torikki-tou]

I would also like to point out that databases list should be extendable using extensions or at least be easy to make extendable.

[Ravenous47]

why isn't this in production already? At least csv and sqlite should be easily viewed in table format since they are flat files, add xlsx and md tables while you are at it

[ghedwards]

Microsoft SQL support would be nice ;)

[stubbulon5]

we need this!

[thelioo]

bump

[joewen85]

We need this feature

[RobbieMinderhoud]

100%. This is the only reason that I haven't made the complete switch yet.

[sergeyzwezdin]

NATS/Kafka support would be also super-useful, btw

[kylejbrk]

Amazing work. Can we add duckdb support as well? There's a first party rust lib for it, and duckdb has tons of extensions for other databases so people can connect to them without zed integration.

[borja-rojo-ilvento]

@mathroc @devurandom Am I missing something? Has this been implemented and that's the motivation for the downvotes? I would love this, personally.

[devurandom]

With every message you write you send emails and notifications to dozens or hundreds of people who are following this discussion. It is generally frowned upon to notify so many people unless one has to add something substantial to the discussion or issue, like new and important information, or a PR ready for review, or similar.

[avelis26]

lol you're an idiot. Don't watch if you don't want the emails. The author asked for interest, anyone posting anything counts as interest. Get off the internet and let the adults deal with this.

[avelis26]

I was just looking for a SQLite plugin for Zed... assumed it already existed lol so ya PR for sure bro :)

[julienlejeunepeaksys]

Very interesting feature !

[ilkersigirci]

definitely needed this. could you please tell us the current status of it @so-keyldzn?

[HalavicH]

I'm not participating in this activity, but I assume not much progress has been done, judging by PR activities.
Since it's quite large effort (~20k lines of code) I don't think maintainers will have capacity to get it into main branch.

I personally have been working on CSV preview PRs chain since beginning of 2026, and despite it's much less code & scope it is still behind the feature flag. Hopefuly I think maybe this month we'll be able to deliver CSV preview feature.

---

While I'm waiting for its review I decided to see how we can start moving on database client front piece by piece. And I think the best candidate is to start with smth small and simple like sqlite db previewer by using this CSV preview feature as presentation layer (for rendering tabular data).

I built a prototype (~2k LoC) this weekend, where you can select any .db file from project tree, and zed introspects it, rendering db tab, with the introspection tree & allowing you to select & view any table/view/index/trigger.

Maybe that one can be a starting point for actually start merging smth DB related, but once again we need to negotiate with maintainers on that front :D

Demo of my MVP (sqlite previewer)

Introspection + table viewing

View viewing (lol) + filtering by column

Stacked filtering (filter chain)

Sorting A-Z by name column

Viewing triggers

---

NOTE: The tabular data component (with sorting, filters, row numbers) is part or unpublished CSV preview feature. Pretty good foundation to start writing the DB client by reusing it instead of reimplementing big chunk of UI/Logic

[HalavicH]

Bonus - opening Zed's own persistense db in Zed 😄

[EugeneTorap]

@HalavicH any news about the MVP of sqlite previewer?

[HalavicH]

@EugeneTorap, well, I do use it and iterate on it myself my machine. Added postgresql support & schema aware autocomplete (testing general direction & architecture of this approach)

Honestly it’s quite big feature even with just sqlite. Primary blocker - changes to existing tabular data preview feature (also authored by me) to be compatible not only with file based sources but with db client based data source. One of prs for that is on review already on review #63752

[so-keyldzn]

@HalavicH Great job

[Kaus1kC0des]

Hi, would be very happy if the core team can integrate this!! This is something I truly miss in Zed!

[mentenaz]

So I forked zed and started adding some things because it didn't have every tool I needed and this as well is a feature I was thinking about its a very needed feature and people and some editors dont always have what you want

[VladimirKosimovsky]

Add DuckDb support please

[so-keyldzn]

Thanks everyone for the replies, and sorry for going quiet here. Quick status update, then some answers.

The PR (#50877) was closed. The team said it's more maintenance than they can take on right now, which is fair for ~20k lines landing in one go. So this isn't coming to Zed, at least not in that form.

@itsbalamurali suggested on the PR that it could be its own app, so I started over and built one: https://github.com/so-keyldzn/oxyn. It's a standalone desktop app with a Rust core, written from scratch rather than extracted from the Zed branch. To be clear about where it stands: v0.0.1, macOS only, no release binary yet, and only SQLite and PostgreSQL drivers so far.

If you want this inside Zed specifically, follow @HalavicH's work. His CSV preview and the SQLite previewer built on top of it are going through review in small pieces (#63752 is one of them). That's a much more realistic path into main than my giant PR was.

@HalavicH sorry the branch didn't build for you. I stopped maintaining it once the PR closed, so it has only drifted further since. Reusing your tabular component for DB results sounds like the right call to me. I don't use Discord, but happy to talk here or in an issue on the Oxyn repo.

@torikki-tou agreed on extensibility. In Oxyn the driver API sits in its own crates under Apache-2.0, so anyone can write a driver under whatever license they like. Loading drivers as plugins is planned but not built yet.

@kylejbrk @VladimirKosimovsky DuckDB is on the list, and yes, the official duckdb crate makes it pretty painless. MySQL comes first though.

@ghedwards SQL Server is in scope too, just further out.

@sergeyzwezdin NATS and Kafka are brokers more than databases, so they're not planned for now.

@mergisi thanks for the architecture notes. A test_connection tool for the agent is a good idea, I'll look into it.

@ilkersigirci hopefully that answers your question.

And thanks to everyone who upvoted or said they wanted this. That's a big part of why I kept going.

[bradtaniguchi]

@itsbalamurali suggested on the PR that it could be its own app, so I started over and built one: https://github.com/so-keyldzn/oxyn. It's a standalone desktop app with a Rust core, written from scratch rather than extracted from the Zed branch. To be clear about where it stands: v0.0.1, macOS only, no release binary yet, and only SQLite and PostgreSQL drivers so far.

Cool stuff, but unless my browser is acting up this seems like its in French?

[so-keyldzn]

@bradtaniguchi not your browser, it's in French for now. The code itself (identifiers, comments, error messages) is in English, and I'll translate the docs later on.

For context, it's a Tauri app: React on the frontend, and the whole backend is Rust (drivers, query execution, secrets, the AI side).

[bradtaniguchi]

Will star and check it out, but yea me being a dumb American... I can't read French 😰 and got caught off guard haha