Everyday workYour queries, inside each database.
Explorer and queries. The tree is organized by connection and by database. The first node in every database is its saved queries, so your work stays where it belongs instead of in stray tabs.
- Color-coded folders and groups, by client or by environment — just drag the servers in.
- Queries save automatically as you type.
- Preview tabs like in VS Code, and every tab with its own session: SET options, temp tables and transactions stick around.
An editor that speaks each engine's dialect.
Smart editor. CodeMirror 6 with each engine's language (every SQL dialect, CQL, JSON, Cypher, Flux, Redis commands) and autocomplete for tables and columns.
- Run the selection or the statement under the cursor.
- Cancel a query using the engine's native mechanism.
- Code formatting and templates for creating objects.
From result set to Excel, without limits.
Results, filters and export. A virtualized grid that shows multiple result sets per run, with a cell viewer and formatted JSON.
- Per-column filters on table data, applied on the server.
- Copy in 10 formats: CSV, JSON, YAML, INSERT, UPDATE and more.
- Export to CSV, TSV, JSON, JSONL, SQL, XLSX or XML: the full query, streamed, not just what's on screen.
- One-click charts from your results.
Edit a cell. You decide whether it runs.
Safe cell editing. When you change a cell, DBine generates the update code in the engine's language and adds it to the query. Nothing runs behind your back.
- UPDATE, Mongo or Redis commands, depending on the engine.
- Set NULL, undo changes and review everything before running.
Performance and operationsEvery query, live.
Profiler. Right-click a database and see every query any application runs against it, just like SQL Server Profiler, across dozens of engines.
- Time, duration, text, database, user, client, rows and error for every query.
- Filter, find the slow ones and open them in the editor.
- If the engine needs something turned on to capture, DBine turns it on and restores it when you're done. On read-only connections it touches nothing.
- CPU, reads and writes for each query, where the engine reports them and in its own unit (pages, blocks, rows, bytes or documents), with average, minimum, p95 and maximum when grouping identical queries.
Your server's pulse, at a glance.
Server monitor. Real-time CPU, memory, sessions and activity, one right-click on the connection away, on every engine that exposes them.
- Live charts to catch spikes.
- Active sessions and what each one is running.
Find where the time goes.
Execution plans. Graphical plans in the style of Management Studio: estimated, actual or both together, with zoom and pan.
- Available on every engine that has plans: SQL, Mongo, Neo4j, Elasticsearch and more.
- The same viewer for every engine.
DBine copies on every engine, plus the server's own.
Backups. Every database has a Backups tab: DBine copies on any engine, with the structure and data in a local script you can restore to the same database or another one, and the server's native backups on the engines that have them.
- DBine copies on every engine, with a local history of date, objects, rows and size. Restore to the same database or a different one, after confirming.
- Server backups where the engine offers them, such as SQL Server, Oracle, SAP HANA, ClickHouse, Snowflake, BigQuery, Elasticsearch or Redis: their history and the script to take, restore or delete a backup, which you review before running.
- Scripts are copied with keys and passwords hidden. Read-only connections see the history but can't take or restore backups.
Users, roles and permissions, in one place.
Users and permissions. A tab to view and manage the server's users, roles and permissions. Every change becomes a script in the engine's language that you review before running.
- Users and roles with their memberships and permissions: on which object, whether direct or inherited from a role, whether they can be granted to others, and whether they're denied.
- Create users and roles, change passwords, enable or disable logins, and grant or revoke permissions on the database, a schema or an object. Passwords never show in the preview or the history.
- DBine asks the server what the connected user can do: backups, the Profiler, killing sessions or managing users show up disabled, with the missing permission, when the user can't run them. When the engine can't tell for sure, the action stays enabled.
- On the vast majority of engines, from SQL Server, PostgreSQL, MySQL and Oracle to MongoDB, Cassandra, Redis, Elasticsearch and Neo4j; not on engines that don't allow it, such as SQLite, DuckDB or DynamoDB.
Structure and changesTwo databases, side by side. Sync them in one click.
Schema compare. Compare the structure of two databases WinMerge-style, even across different connections or engines.
- Tables, columns, indexes, keys, views, procedures, functions and triggers.
- Move each change from one side to the other with the arrows, with undo.
- A sync script in the right order, with warnings when something could lose data.
The same tables, row by row.
Data compare. Compare the rows of two tables or collections on any engine, whether they're in the same database, on different servers or on different engines, and choose which way each difference goes. DBine writes each side's script in its engine's language and runs nothing until you decide.
- Rows are matched by primary key, or by the columns you pick when the table has none. Values are compared by what they mean, not by how each engine returns them: 1 and 1.00 are equal.
- Equal rows, different rows with every changed value highlighted, and rows found on only one side. For each one you choose to update, insert or delete; deletes are never picked for you.
- One script per side that changes: SQL on SQL engines and native commands on MongoDB and the rest. Copy it, open it in a query or run it, and DBine compares again.
- Safeguards: a warning when the two tables aren't the same one, deletes always by key, updates that touch only the changed columns, and read-only connections that reject the script.
From one engine to another, no hand rewriting.
Migrate to another engine. Converts a database's tables to another engine: types, defaults, auto-increments, keys, indexes and names.
- A report on every change and why it was made.
- The target script, ready to review and run.
Move the data, not just the structure.
Transfer, clone and sync. Move tables and data from one database to another, even on a different engine, using each engine's native bulk load. Between databases on the same engine you can also clone the whole database or sync only what changed.
- Native bulk load where the engine has it (binary COPY on PostgreSQL, INSERT BULK on SQL Server, LOAD DATA on MySQL and more); batched INSERTs everywhere else, so no engine is left out.
- Several tables in parallel with bounded memory, per-table progress and rows per second, and cancel or retry for each one. The source is always opened read-only and the data arrives lossless.
- If a run is cut short, resume it later without recopying the tables that already finished.
- Clone replicates the database on the target: schemas, tables, partitions, indexes, constraints, sequences, views, routines and triggers, with the data if you want it, adapted to what the target server supports, and the preview shows what couldn't stay identical. On SQL Server, Azure SQL, and PostgreSQL and compatibles such as TimescaleDB, AlloyDB, Cloud SQL, Aurora and EDB.
- Sync matches rows by key and, in one transaction per table, inserts, updates and deletes only the rows that differ. On the same engines, plus YugabyteDB.
- Every migration is saved under its source database with its settings and run history, ready to reopen, resume or repeat. The settings travel with cloud sync.
An exact copy, right next to the original.
Clone table. From the explorer, clone any table, collection or index into the same database, with its structure and its data. The clone is exact or it isn't created: if something can't be copied faithfully, whatever was created is discarded, you're told why, and the original is never touched.
- Columns, primary key, constraints, indexes and foreign keys, with identity values preserved and the counter or sequence moved past them.
- Structure only or with the data, with or without indexes. New names respect each engine's maximum identifier length.
- Honors each engine's specifics: partitions and filegroups on SQL Server, exclusion constraints on PostgreSQL, full documents on MongoDB and Cosmos DB, mappings and settings on Elasticsearch and OpenSearch.
- On every engine whose tables or collections hold their own rows; it doesn't apply to graph, key-value or streaming engines, nor to a few others such as CouchDB or InfluxDB 2/3.
Design, visualize and regenerate your database.
Designer, ER diagrams and scripts. A table designer tailored to each engine, ER diagrams that handle hundreds of tables and a script generator for restores.
- Diagrams with relationships, schema filtering, a minimap and SVG or PNG export.
- A full database script with DROP, CREATE, indexes, keys, views, routines, data and triggers, in the right order.
- On Mongo, it designs collections, with validation.
Your files, straight into a table.
Import data. Import CSV, TSV, JSON, JSONL, XLSX and XML into a new or existing table, with column mapping.
- Run large script files in chunks, for example to restore a dump.
ProductivityAn AI that writes. You run it.
AI assistant. A chat panel beside the editor that writes queries, explains or fixes the one in the editor and answers questions about the database structure.
- It never runs anything: its code is added to the query and you decide.
- It never sends data rows: only the engine, the structure and the editor contents.
- Uses a built-in local model, Ollama, LM Studio, Claude Code or Codex.
Your AI assistants, within the limits you set.
MCP server. DBine works as a local MCP server, so Claude Code, Codex, Cursor, Claude Desktop, VS Code or Windsurf can work with your connections while DBine is open, on any engine. You decide how far each connection goes.
- Four levels per connection: nothing, structure only, read or write. Structure only out of the box.
- Connections tagged prod and read-only connections never go beyond read.
- Every write asks for your approval (or you approve all of a client's writes) and shows the exact code; if you don't answer within two minutes, it's rejected.
- One revocable token per client, and the server only listens on this machine. A local log shows every call, with no passwords or secrets.
Your DBA scripts, always at hand.
Script library. Save the scripts you use all the time, organized by engine, and open them against the active database.
- Parameters that fill in from that database's tables.
- Folders, search and a one-shot import of your .sql folder.
Switch to DBine in a minute.
Import connections. Bring your connections from DBeaver, DbGate, DataGrip, Azure Data Studio or SSMS, or paste connection URLs.
- DBine reads those tools' files and shows you what it found.
- Passwords go straight into the system keychain.
Your setup, securedYour setup, on any machine.
Cloud sync. Connections, folders, queries, preferences and passwords synced with end-to-end encryption, in your own account.
- Google Drive, OneDrive or any folder, such as iCloud or Dropbox.
- Resolves conflicts without losing data.
- AddLayer has no servers for it and never sees your data.
Peace of mind in production.
Security and read-only. Passwords go into the system keychain, never into files or logs. And read-only connections block anything that isn't a read.
- Keychain, Credential Manager or Secret Service.
- Real read-only: DBine blocks writes, including in the Profiler and schema sync.
Your private databases, over SSH.
SSH tunnels. Any connection to a network engine can reach its database through an SSH server, or a chain of bastions, so you can work with databases that are only visible from inside a private network.
- Password, private key (OpenSSH or PEM, with passphrase) or the keys in your SSH agent, such as ssh-agent, 1Password or Pageant.
- Every server is checked against known_hosts: new ones show their SHA256 fingerprint for you to confirm, and a key that doesn't match is rejected.
- SSH passwords and passphrases go into the system keychain, never into files or logs.
- A single tunnel per connection, reopened automatically if it drops and kept alive with keepalives.