Nobody chooses to run four database applications at once, it happens because the tooling for each engine was written by whoever owns that engine, and nobody owns all of them, so a polyglot stack accumulates a client per datastore the way a shared drive accumulates a folder per project, quietly, until the desktop has four icons, four credential stores, four ways to read a connection string, and four slightly different opinions about what a schema even is.

The concrete version shows up on a Tuesday afternoon when a Postgres release is blocked on a Redis lock, the Redis key belongs to a document in MongoDB, and the deploy that caused all three is waiting on a MySQL explain plan, and now the engineer is alt-tabbing between four windows that each think they own the truth, copying connection strings out of one and pasting them into another because the tool that can run the query is never the tool that already holds the credential.

This is not a complaint about the individual tools, each of them is good at its own job and most of them cost nothing, it is a complaint about the topology, because in 2008 the honest answer was one engine per company and psql plus a Java tool was the whole story, and then the polyglot service arrived and quietly rewrote the rules, so by 2026 a single service might legitimately touch half a dozen datastores while the operator’s desktop still assumes the old world of one language, one client, one window.

The cost is attention, not memory

Holding four clients open is cheap in RAM and expensive in something harder to measure, because every switch costs a re-orientation, since the tab title tells you which engine you are in, the result grid tells you which data model you are in, and the connection dialog tells you which credential model you are in, and moving between a relational grid and a document browser is not a click, it is a re-reading of what a row means, and a re-reading is exactly where mistakes happen, because a misfired delete in a relational grid and a misfired delete in a document browser look identical right up until one of them is not.

What one connection list actually buys

The fix is not a better tab switcher, it is treating every datastore as an entry in one registry rather than as an application you launch, and the registry has to carry the things that used to make you launch one anyway, which means credentials, safety, and organization all have to live in one place, or consolidation is just four windows with a nicer frame.

Mongrel, the desktop workbench we build, keeps its connection profiles in a single list, and the shape of that list looks roughly like this:

Connections
  analytics-prod     postgresql   sslmode=verify_full        keychain: postgres-app
  session-cache     redis        tls, cluster seed nodes     keychain: redis-app
  events            mongodb      built-in driver             keychain: mongo-app
  billing-staging   mysql        ssh tunnel "prod-bastion"    keychain: mysql-app

Passwords never live in the profile, they go into the operating system keychain, which is Windows Credential Manager, macOS Keychain, and the Linux Secret Service depending on the host, and if you want one more layer, the optional master password derives an Argon2id key from what you type and encrypts the stored secret in place, with the ciphertext still sitting in the keychain where the platform already knows how to protect it.

There is also a shorter-lived option for teams that would rather not keep a durable database password at all, because Just-In-Time credentials have Mongrel fetch a short-lived secret from an external authority at connect time, renew it before it expires, and revoke it when you disconnect, which is the shape Vault dynamic database secrets produce, and it is currently a beta feature available for MySQL/MariaDB and PostgreSQL connections, so treat it as the newer path rather than the default one.

Safety travels with the profile instead of sitting in a global preference somewhere, because writes are off until you turn them on for a session, a read-only profile cannot enable them at all, and production-tagged environments can require a typed reason before the command leaves the app, and the backend still enforces its own permissions on top of that, which is the correct division of labor, the desktop gate stops accidents and the server stops attackers.

The plugin model, and what it asks of you

MongoDB and MongrelDB are built into every build, and everything else arrives as a signed .mongrel-plugin bundle containing a sidecar binary that the app launches and supervises, and the practical consequence is that you only carry the engines you actually use, because the awkward prerequisites attach to their own engine, an Oracle install drags in a Java 25 runtime you install yourself, IBM Db2 and Informix need the separately installed IBM client driver, SAP SQL Anywhere needs the SAP DBCAPI runtime, and a workstation that only ever touches Postgres never has to think about any of that.

Installing one takes a handful of clicks inside the app, from Settings, then Advanced, then Database Plugins, where the catalog refreshes, you click Install, and the bundle downloads, has its signature verified, and installs:

Settings → Advanced → Database Plugins
  Available Plugins
    PostgreSQL / CockroachDB   com.visorcraft.mongrel.driver.postgresql
    MySQL / MariaDB           com.visorcraft.mongrel.driver.mysql
    Redis / Valkey            com.visorcraft.mongrel.driver.redis
    MongoDB / MongrelDB       built in

Saved connections that are missing their driver show an install badge, and clicking that badge or clicking Connect offers to run the same verified installer, so the awkward case where you need a driver you forgot to install turns into a prompt rather than a documentation hunt. Uninstalling removes the plugin files but leaves your profiles and their keychain secrets alone, because deleting a profile should be a deliberate act and not a side effect of housekeeping.

Two constraints are worth stating plainly instead of discovering later, which is that connecting through a database plugin requires an active license or trial, and that an air-gapped machine can install an Azure-signed bundle or a full release ZIP without refreshing the online catalog at all, which is how this works on a network that never talks to the internet.

Where the three engines genuinely refuse to behave alike

The point of a shared connection list is not that Postgres and Redis and MongoDB should pretend to be the same thing, because they are not, and the honest version of this feature is that the shared shell carries the profiles, the credentials, and the safety rules, while the engine-specific surface keeps saying the truth about the engine.

PostgreSQL connections execute native SQL with no translation layer, with selection-aware multi-statement execution, named parameters, linting for dangerous operations, cancellation, and explain output in TEXT, JSON, XML, or YAML with ANALYZE, BUFFERS, COSTS, TIMING, and VERBOSE available, and the admin surface carries your current role, roles and grants, server variables, the process list, installed extensions, and the cancel or terminate actions for a running backend.

Redis is not SQL and never pretends to be, so its plugin does schema browsing, read command execution including stream ranges, lossless SCAN-based browsing, binary-safe value decoding, client and topology status, and writes behind the same write gate as everything else, and it also has an honest list of things it does not do, because Pub/Sub streaming, MONITOR streaming, blocking stream and list commands, and retunneling when a cluster reshapes itself at runtime are all still unsupported, and if your daily job depends on MONITOR you will want a dedicated client.

MongoDB is the one engine in this group that needs no plugin at all, since it is built in with the full driver, document browsing and editing, aggregation pipelines, and a Mongo Shell, and SQL written against a MongoDB connection is compiled into a find() shape with filter, projection, sort, and skip or limit, which is convenient and also occasionally surprising.

There is one more limit worth naming because it is the kind that only shows up on a bad afternoon, and it is that the Index Advisor reads PostgreSQL explain output but does not ship automatic index recommendations for PostgreSQL, the way it does for MongoDB, so on Postgres you still read the plan yourself.

The honest tradeoff

Vendor tools go deeper on their own engine, and most of them cost nothing, which is the strongest argument against consolidation, and if your week is one Postgres instance and one Redis cache and your work never crosses the database boundary, then pgAdmin or the psql prompt is the better answer and a broader workbench is overhead, because every surface you never open is still a menu sitting in your way.

Consolidation earns its keep in the other shape of job, the one where the session starts in a pricing table, moves through a bastion host, pulls a backup over SFTP, checks a Helm values diff, and confirms the fix with an API call, and in that shape the connection list is not the feature, the fact that all of it shares one credential model and one set of write gates is, because the alternative is five applications each with its own idea of where a password lives.

Where this lands

Mongrel ships for Linux as a signed AppImage and a .deb for glibc 2.39 or newer, which in practice means Debian 13, Ubuntu 24.04, Fedora 40, and the current Arch and openSUSE families, alongside macOS and Windows builds, and the plugins for the three engines in this post install from the catalog inside the app without a rebuild.

The one database app overview walks through the plugin model and the platform limits, the supported databases page lists every documented engine and where each one is deliberately narrower than its vendor tool, and if you want to point it at your own three databases the seven-day trial needs no credit card, with individual pricing starting at $99 a year for one seat and two active machines on the pricing page.