Oxbow

Your database client.
Your agent’s, too.

Write queries, edit rows, review every change. With a built-in MCP server.

Download the betaSee it work

Beta for macOS. Works with PostgreSQL and MySQL.

The MCP pane of Settings: the server on, the agent apps with Claude Code and Claude Desktop added, three connections with what each shares, and the agent's recent requests.
The bookshop schema as a diagram: customers, orders, order_items, books, authors and the low_stock view as cards joined by their foreign keys, with books selected.
The Top customers query joining four tables, with nine result columns: orders, books, average order, total spent, first and last order dates.

Watch your agent ask.

Every request goes through Oxbow, and Oxbow answers with only what you allow.

  1. Your agentrun_query SELECT title, stock FROM books WHERE stock < 5

    Oxbow4 rows, read in a transaction that rolls back.

  2. Your agentrun_query SELECT name FROM customers

    OxbowBlocked: customers.name is hidden.

  3. Your agentpropose_changes books, id 7: stock 12

    OxbowWaiting for your Save in Oxbow.

  4. Your agentexecute_statement DROP TABLE orders

    OxbowBlocked: only INSERT, UPDATE and DELETE.

Every request stops at Oxbow.

Reads go through. Proposed changes wait for you. The rest is turned back.

  1. SELECT title, stock FROM booksGoes through, read only, and the rows come back.
  2. UPDATE books SET stock = 12Stops at Oxbow as a pending edit, until you Save.
  3. SELECT name FROM customersTurned back: customers.name is hidden.
  4. DROP TABLE ordersTurned back: only INSERT, UPDATE and DELETE.

You decide what your agent can do.

Every connection starts unshared. Share one, and choose what the agent may run on it.

Queries
Changes
Hide

Read & Write on a remote server asks you first.

  1. describe_tablebooks

    Columns, keys and indexes.

  2. run_querySELECT title, price FROM books

    Blocked: queries are off.Rows, read in a transaction that rolls back.

  3. run_querySELECT name FROM customers

    Blocked: queries are off.Blocked: customers.name is hidden.Rows, read in a transaction that rolls back.

  4. execute_statementUPDATE books SET price = 16.50 WHERE id = 1

    Blocked: queries are off.Blocked: queries are read only.Runs and commits.

  5. propose_changesbooks, id 1: price 16.50

    Blocked: changes are off.Opens as a pending edit and waits for Save.

  6. execute_statementDROP TABLE books

    Blocked: only INSERT, UPDATE and DELETE.

The MCP activity list: Claude Code sent two updates on public.books for review, a DELETE it tried was blocked because queries are read only, and a SELECT returned 4 rows.

You see every call.

The activity list shows what your agent asked and what came back. Big results are trimmed, and slow queries are cancelled.

Edits wait for Save.

Each marked change is one statement. Save runs them in one transaction.

The books table with five pending changes: two edited prices and one edited stock outlined in amber, a duplicate row struck through in red and a new book in green.
  1. DELETE FROM "public"."books" WHERE "id" = 13;
  2. UPDATE "public"."books" SET "price" = 16.50 WHERE "id" = 1;
  3. UPDATE "public"."books" SET "stock" = 12 WHERE "id" = 2;
  4. UPDATE "public"."books" SET "price" = 12.50 WHERE "id" = 7;
  5. INSERT INTO "public"."books" ("author_id", "title", "isbn", "price", "stock", "published") VALUES (2, 'The Left Hand of Darkness', '978-0000000141', 16.00, 10, '1969-03-01');

See the whole schema, and change it.

Open any schema as a diagram and edit it there: tables, columns, indexes and foreign keys. Nothing runs until you apply it.

  1. The bookshop schema as a diagram: six tables and a view as cards, foreign keys as lines, and the books card selected with its two relations in teal.

    Relations at a glance

    Foreign keys draw the lines. Select a table and its relations light up.

  2. The same diagram with Keys Only on: each card lists just its primary and foreign key columns.

    Keys only

    Large schemas fold down to their primary and foreign keys.

  3. The diagram filtered by order: orders and order_items stay bright, the other tables fade.

    Find a table

    Type a name and the rest steps back. Double-click a card to open its table.

Built around how you write SQL.

  • Two query tabs, Top customers and Restock report, above a query in the editor.

    Queries save themselves

    Saved 600 ms after your last keystroke. Tabs reopen when you reconnect.

  • A script whose statements produced four result tabs: 1. CREATE, 2. SELECT, 3. SELECT and 4. SELECT.

    Scripts split cleanly

    $$ bodies, BEGIN ATOMIC and DELIMITER are understood. One result tab per statement.

  • Typing a.co after joining authors as a suggests the country column first.

    Completion reads aliases

    Join authors as a, type a.co, and country comes first.

  • The result grid with its pager: 25 rows, 9 columns, 1 to 25 of 25, 100 rows per page.

    One run, every page

    A query runs once. Up to 10,000 rows stay in memory for paging.

Look around first.

The Top customers query joining customers and orders, with twenty result rows below.
Run the statement under the cursor, or all of them. Format SQL tidies the rest.
The orders table in Structure: its columns with types and defaults, its foreign key, the table that references it and its indexes, with the DDL folded below.
Columns, keys, indexes, checks and triggers of a table on one page, the DDL one click away.
Query History open over the editor: each statement run, with when it ran, how long it took and its row count, and a search field above.
Every statement you run, with its time and rows. Click to insert, double-click to run again.
The Export popover over a result: CSV, the current page of 25 rows, comma delimiter and a header row, with Copy and Save.
Copy a result or save it as CSV, Excel, JSON, SQL INSERT, Markdown and more.
The Connections window with a connection named Bookshop on localhost, and Test Connection, Save and Connect.
Test a connection before you save it. TLS when the server offers it, SSH when it sits behind one.

Questions

Do I need an account?

No. Download it, add a connection and run your first query.

Where are my passwords kept?

In the system keychain, never in a plain file.

Does Oxbow send my data anywhere?

No. Connections, queries and results stay on your machine. Oxbow talks only to your databases, and to GitHub to check for updates unless you turn that off.

Which servers can it reach?

Any database your machine reaches: local, in Docker, on a server or through an SSH tunnel.

Can my AI assistant use it?

Yes. Turn on the MCP server, click Add next to your agent app, like Claude Code or Cursor, and share a connection. Agents are read only unless you allow more, and you can have every change wait for your review.

Can an agent drop a table?

No. Agents can only send single INSERT, UPDATE or DELETE statements, never schema changes, and only where you allow writes. With Review in Oxbow, those changes wait for you. For a hard guarantee, give agents their own database user.

Can I change the schema without writing SQL?

Yes. Edit tables, columns, indexes and foreign keys from the schema diagram. Changes wait until you apply them, and Preview SQL shows every statement first.

Can I import a CSV or Excel file?

Yes. CSV, TSV, Excel and JSON files go into an existing table or a new one. If a row fails, nothing is imported, and Oxbow tells you which row and why.

How do I report a problem?

From Oxbow: Settings, then Report a Problem. It opens a GitHub issue with your version already filled in.

How do I get new versions?

Oxbow tells you when one is out and installs it when you say so. Your connections, saved queries and history are kept.

Bring the agent you already use.

Claude, Codex, Cursor and Windsurf in one click, or any MCP client by hand. Then choose what it sees.

Download the beta
The MCP pane of Settings: the server on, and the agent apps, with Claude Code and Claude Desktop added and Cursor, Codex, Windsurf and Antigravity ready to add.