For my workflow I’ve always looked for performance, especially since some time ago I had a really outdated machine and any kind of bloat was really noticeable, I remember using DBeaver and it just crashing on me multiple times, I also had to use postGIS which just made it worse. I migrated all my essential dev tools to use the ones with performance in mind (Zed, Ghostty etc) but the only thing that was missing was DB Client. The main choices everyone has are DBeaver which is a memory hog and an overkill for most of the tasks imo. The other options like Datagrid, Beekeeper, TablePlus are either electron based so bloated and memory hogs or paid and closed-source.
DBDelve 0.3.6 against DBeaver 25.3.1 on the same Postgres table, median of 5 runs each (2026-10-11, M1 Pro, 32 GB). Times are from the action to the rows rendered.
DBDelve DBeaver
Launch 1.1 s 5.2 s
Idle memory 133 MB 606 MB
1,000-row query 0.21 s 1.96 s
1M rows, time 56 s 208 s
1M rows, memory [1] 4.9 GB 17 GB
Scrolling perf with 1 million rows loaded with 100 columns each: https://youtu.be/V2MOhJYFqIE
It has most of the features most devs would need for 90% of their workflow plus some more I thought would be a nice touch: Readonly, read-write and Full Access modes Glass themes (If you’re into them, I am) Keyboard focused with every keybinding customizable Organization of connections into projects
Me and some other folks have been daily driving it for more than a month now and most good feedback comes on it having a really simple UI to navigate, very stable for its age and the performance of course. I’m also sharing here because those people tell me this has potential to grow so I’m trying my hand at distributing it.
Just want to give a huge shoutout here to the Zed team for GPUI, it's a breeze to work with if you just get through them not updating the crate officially on crates.io but the community has found the solutions for it, you just have to dig deep for it. It performs extremely well and just the HTML-like structure of it, makes it easy to understand for someone from a web dev background and agents are very good at writing it too. GPUI component also solves a lot of problems with having a good component library we can use. I think for anyone starting a GPUI project now, GPUI-kit makes a lot of sense, it just bundles GPUI, GPUI-component together and has some optimizations adding retained mode which is experimental but could provide a lot of benefit, so think all things considered it should be the default way.
The major optimization I did was just lowering the memory overhead by using packed rows which reduced the memory usage by 40% on large datasets (8.1GB to 4.9GB on a 4GB table loaded in app), everything else came bundled in with Rust and GPUI mostly or they just made it very easy.
Limitations: It's not signed and notarized, identity verification from apple's side has been a nightmare but it should be signed soon. Don’t expect feature parity with more mature clients for now, the general direction of this right now is the zed way of adding features in but after making sure the core workflows are done with a high quality.
Do give it a try, you can import your connections from dbeaver and tableplus.
How does this compare with Navicat or DBeaver feature-wise?
The data destruction thing was something I was really careful with, any destructive query opens a confirmation first, any edit opens a popup showing the query that will run. I've designed it to be really safe.
For perf, even if row listing speed doesn't matter I assume scrolling and loading a large dataset would improve your workflow, plus quick tab switches and low memory usage for all, no?
what does this mean?
the ui does look very nice
just had a quick google too because gpui is on my “to check out some time” list and the situation honestly does not inspire confidence
it seems like everyone and their dog has their own vibe coded gpui flavor and the choice is between making your own vibe coded gpui flavor instead of your desired project vs building your project on quicksand
i feel like the problem is that (putting together a website, making a bunch of commits, getting people interested) was at some point a sign of a base level of commitment
now that the cost of that is zero it’s difficult to say whether a “community edition” actually has any community which will still be there next quarter
oh well sorry for the rant good on you for making it work clearly it is possible
Would you be interested in adding support for Disc?
https://disc.sh + https://disc.md
Or are you thinking of performance in terms of UX when browsing the result-sets?
But, congrats on the project. It looks great. I can't wait to try it.
Same result set where other clients can crash, this scrolls smoothly so you can naturally load a bigger result set in the app than other clients would allow you to, It paints the UI considerably faster than DBeaver on my benchmarks, thats after the query has run. Memory footprint for the same result is considerably lower.
Basically, your db client can slow you down even after you have waited for queries so this will fix that.
[1] https://dbpro.app
What features are paywalled?
I'd like an AI agent plugin to help with my SQL queries?
Why proof of concept though? There are people daily driving it
But I absolutely hate opening DataGrip it feels like you're trying to start a crank car from the 40's.
There are many, many existing DB clients. Some of them already written in GPUI and free/open source:
https://github.com/0xErwin1/dbflux
How do you sustain continuous development of the project beyond the next two weekends?
(Workbench is a pain but it was capable, off-the-shelf and was possible to document it once, more or less, for multiple platforms; I did not actually hate using it. But alas it is old now)
I will surely test this out; good luck with it.
For me, and for customers I want to document things for, it has come down to MySQL Workbench on the free/open source side of things.
I want to support multiple platforms without having to fundamentally document multiple strategies.
Most DB tools feel like they will go the way of PostgreSQL or Insomnia — get slowly burdened with cloud facilities and then a bait-and-switch means you need a login somewhere.
I would much rather be able to talk about clients that do fewer tasks but do them well, but DB clients do seem to be prime enshittification territory for some reason.
Brain concept leakage there. I meant all those apps that start off with a simple purpose and end up with an enterprise cloud plan.