The morning is a tour of "what is this table?" A fixture lives in SQLite on the laptop. The application lives in PostgreSQL. Finance has a replica in SQL Server. The reporting set is in BigQuery. Each question is small: which columns, which key, a sample of rows, the name you were told in Slack and cannot find.
Each question opens a different client. The login is different. The shortcut to describe a table is different. The filter you typed in the last window is not in this one, and the tab you meant to come back to has been closed by a laptop sleep. Half the time the work is not the schema. It is finding the right window and remembering which environment it was pointed at.
The captured workaround is to build yet another viewer, so the switching stops. Building the viewer becomes the project. The viewer speaks two of the four engines, and the other two clients stay open beside it. There are now five places to look.
The cost is the switch, not the query
Listing columns is a small query. The expensive part is everything around it. Which host, which database, which environment, whose login, which tool remembers that login, which tool is allowed to be installed on this machine. People who do this every day build a personal map in their head. The map walks out the door when they do. The next person repeats the archaeology.
Engine-specific clients are good at engine-specific work. A Postgres explain of a bad plan, a SQL Server trace, an Oracle session view: those belong in the vendor tool, and a generic viewer that tries to hide them will do that work badly. The pain here is narrower. Inspection — tables, columns, a preview of rows, the same glance you do in every engine — does not deserve a new interface each time. Teams feel that, and they respond by starting an internal product. The internal product is how the switching cost gets paid twice.
Why the usual tools keep the switch in place
The vendor client is loyal to one engine. That is a fair trade when you are a database administrator for that engine. It is a poor trade when the morning is four engines and the task is "show me the columns." You pay the loyalty four times before lunch, and you learn four dialects of the same gesture.
A BI tool hides the schema behind a model. You came to inspect the table the application writes. The tool offers you the measure someone published, which may be the table, a subset, or a join you did not want yet. Getting back to the raw columns is possible in some tools and discouraged in others. You wanted a catalog. You got a semantic layer, and the layer does not include the SQLite fixture on the laptop.
Excel is another copy. Export the columns, lose the types, lose the keys, and now the sheet is a rumor of the schema. It will not update when someone adds a column this afternoon. It is useful as a note you paste into a ticket. It is a bad place to inspect from.
A text-to-SQL product tied to one connection answers questions on that connection. The other three engines are still the other three clients. If the product is willing to open several connections, you have left "single database text-to-SQL" and started the thing this article is about: one place that can see more than one engine. Many of the chats people try first are still one connection string and one dialect. They help on Tuesday's Postgres question and send you back to the SQL Server client on Wednesday.
So the switching continues, and someone who is tired of it starts a viewer. A viewer that covers the engines you actually have is a reasonable product. A viewer that covers two of four, built in a spare quarter, is a fifth window. Write the list of engines before you write the viewer.
Keep one inspection habit, and leave admin in the vendor tool
List the engines you inspect in a normal week. Be specific and short. If the list is SQLite, PostgreSQL, SQL Server, and BigQuery, that is the list a single inspection tool has to speak before it removes a window. MySQL and Oracle count if they are actually on the tour. An engine you might have next year does not.
Pick one tool that can open that list, and use it for the glance: tables, columns, keys, a few rows. Use the vendor client when the task is engine-specific administration. The split keeps you from throwing away a good explain plan in the name of consistency, and it keeps you from opening four clients to read four column lists.
Write the connections down once. Host, database name, environment, who owns the login, and which tool you open it with. The switching cost is half login archaeology. A page in the repo, boring and current, beats a viewer that has the passwords in a config only one person understands.
Keep a short note of the tables you keep reopening. That note is the start of a map. It is cheaper than an internal product, and it tells you whether a viewer would even pay off. If three tables account for the morning, a saved query against those three is the whole tool you needed.
Before anyone builds a viewer, ask which engine it will not speak on day one. That engine remains a separate client. If the answer is "we'll add it later," you still have the switch, plus a codebase. Later is allowed. It should be a named engine and a named gap, not a hope that one UI will absorb every database that exists.
Where DataTug fits
DataTug inspects schemas from one CLI and terminal UI and one web app. The engines and sources the site marks as working today, and the ones this fits, are SQLite, PostgreSQL, MySQL, Oracle, SQL Server, and BigQuery, plus inGitDB and REST APIs. AI chat can sit on the same project. An agent can use the Claude Code skills plugin or the MCP server.
That is one place for the morning tour, for those sources. It is not a client for every database that exists. Firestore, Snowflake, Databricks, Airtable, and Google Sheets are on the homepage under "Not supported yet," and they are left out here on purpose. The vendor consoles stay the right tool for engine-specific administration. DataTug does not replace an explain plan, a trace, or a session browser.
If your actual list is inside the working set, open it in datatug.app or install the CLI and point both at the same project. Personal and public projects are free. If your list includes an engine the site does not mark as working, keep that engine's client, and do not start a fifth viewer to cover the gap until you have written down which gap you mean.