Most real projects don't have a database. They have an app DB and an analytics DB, a MySQL here and a ClickHouse there, maybe a SQLite file for something local. So a panel that only ever holds one connection at a time is quietly lying to you about the shape of your own work.

0.4.3 stops doing that.

The tree

The DB panel is a tree now, the way you'd expect from a real client:

  Database                              ＋
    ▾ 🐬 inside_finance     (24)
         addresses
         orders
         …
    ▾ 🟡 clickhouse@local    (5)
         events
         page_views
         …

Click ＋ to add one — from the project's .env, or by hand. Each connection lives as its own branch: expand it to see its tables, and on hover it offers its own little toolbar — new query (⌗), refresh (⟳), disconnect (⏏), remove (✕).

Open a table from MySQL and a query against ClickHouse, and they sit side by side as tabs. No more tearing one down to look at the other.

It's a small structural change with a big everyday payoff: the panel finally matches the actual shape of your project.

Where the secrets live (and where they don't)

The moment you let people save connections, you're holding a question you'd better answer honestly: where do the passwords go?

The lazy answer is a config file in the project. We did briefly sketch exactly that — a gitignored .conductor/connections.json. And the feedback came back sharp and correct: these must be stored somewhere secure, and never part of a commit.

That's the right instinct, and the file approach doesn't fully earn it. Gitignored or not, it's still a plaintext password sitting in your working tree, one stray git add -f or backup tool away from somewhere it shouldn't be.

So 0.4.3 doesn't put them in the project at all. Saved connections — including passwords — go into the OS keychain (macOS Keychain), keyed per project:

• Nothing is written into the project folder. There's no file to gitignore, because there's no file. Nothing to accidentally commit.

• Secrets live in secure storage, managed by the OS, the same place your other credentials live.

• They reappear when you reopen the project — collapsed and ready, a click away from connecting.

It keeps a promise Conductor cares about: it reads your .env to connect, but when it remembers things for you, it remembers them in the right place — not scattered as plaintext across your repos.

And a proper ORDER BY

Smaller, but you'll feel it. The table view already let you sort by clicking a column header — lovely for "sort by this." But sometimes you want "newest first, then by id," and a single clickable header can't say that.

So there's now an ORDER BY box, right next to WHERE:

  WHERE   amount > 1000        ORDER BY   created_at DESC, id

Type the clause you actually want. Header-clicks still work for the quick case; an explicit ORDER BY takes over when you need something richer. The ✕ clears filters and order together and you're back to the plain table.

A two-minute tour

1. Open a project with both an app DB and an analytics DB.

2. DB panel → ＋ → From .env — your MySQL appears.

3. ＋ again → manual → ClickHouse, port 9000 → Connect & save.

4. Expand both. Open orders from MySQL and run SELECT … FROM events against ClickHouse — both open as tabs.

5. On the orders table, type total DESC, created_at DESC into ORDER BY. Apply.

6. Quit the app. Reopen the project. Both connections are right there — and git status has nothing to say, because nothing was ever written.

The throughline

There's a pattern to how this feature came together, and it's worth naming. The first sketch worked — one connection, a config file. But "works" kept bumping into "is this actually right?" The shape was wrong (projects have many databases), and the storage was wrong (secrets don't belong in the tree). 0.4.3 is what you get when you let those two corrections land: a panel that matches reality, and a memory that respects your secrets.

That's the quiet contract underneath Conductor. It's a tool, and a good tool is honest — about the shape of your work, and about where it puts the things you'd rather not lose or leak. It reads your .env, speaks each database's own protocol, keeps your passwords in the vault the OS already gave you, and never once reaches for a model.

Open a project. Add two databases. Close it. Reopen it. They're waiting, and your repo never knew. 🪵🔥

Elyra Conductor 0.4.3 adds multiple per-project database connections (stored in the OS keychain) and an ORDER BY field to the table view, with auto-update built in. Four engines now — MySQL, PostgreSQL, ClickHouse, SQLite — side by side in one panel. Conductor connects, queries, and exports; it never reasons.