I'm sure this is going to be a very unpopular opinion here...but Microsoft Access 2000 was amazing for managing small databases shared on a LAN. You could build relational tables, and it managed all the keys, etc. You could build a CRUD app in less than an hour for almost any data an organization might have.
You could then scale up to ODBC or SQL databases as time went on. It was part of that golden era of tools that did lots of useful things, and could be used by those with domain knowledge, right before .NET infected Microsoft.
If you needed to interface with specialized hardware (as I did a few times), you could use VBA or Delphi to do that work, and tie it into the back-end, while providing a good UI for the person operating the hardware.
I have a love/hate, but SQL Server Management Studio. Especially if you load a couple of the Redgate tools, it is insanely powerful and the intellisense completion is amazing.
I've used almost all of the major tools for other DBs, and they feel like toys or simple query runners in comparison. The biggest downside to SSMS is that it does feel and perform like the bloated, kitchen sink it is, but honestly, things that do more than run queries, like pgAdmin are just as slow or slower and don't offer nearly as nice of an experience.
My use case is a bit different (I am a PM) but I found what pyCharm offers very useful for my use case (Postgres) . I don't create or manage DBs if that helps.
I’m not sure if it’s okay to plug my project, but I work on Mathesar (https://github.com/centerofci/mathesar) which can be used as a Postgres GUI. We’re putting a lot of product/design effort into making it nice to use for non technical users.
The worst would be pgAdmin. I tried it again this week and don’t understand why I need 7 clicks to access a table in the tree. Also I didn’t find how to actually show the content of a table. Nor how to execute a query.
If you’re on OSX I haven’t found any program better than Sequel Pro (sometimes referred to as Sequel pancakes). It’s one of a few programs that makes keeping a Mac around worth it.
I mean, you're not wrong: there is absolutely a big place for API/CLI support with DB tools, but in this specific instance, the OP specifically asked for a GUI, not CLI or APIs to roll their own.
If OP asked which cliff he should jump off, will you point to one? GUIs are written on top of DB APIs - in many cases, the same ones you can use. You can do anything with these tools. Given a DB viewing program, you are always experiencing someone else using these APIs for you. There will always be some feature you need. For many types of applications, there are no other choices except the GUI, but DBs are programmer tools, and they work brilliantly without gold-plated rigmarole.
I work with data all day and have for 20+ years. I *STRONGLY PREFER* to develop my code in a UI and then later deploy it to the production infrastructure via CLI/API. I just cannot possibly fathom how you could seriously tell someone working with data that they should interact with their systems in a CLI/API way all the time; it just doesn't make any sense whatsoever, unless you are dealing with queries and their results that are not at all complex.
There is a place and a time for both paradigms and to suggest that we should direct someone away from their preferred use case is really over the top.
You could then scale up to ODBC or SQL databases as time went on. It was part of that golden era of tools that did lots of useful things, and could be used by those with domain knowledge, right before .NET infected Microsoft.
If you needed to interface with specialized hardware (as I did a few times), you could use VBA or Delphi to do that work, and tie it into the back-end, while providing a good UI for the person operating the hardware.