SQLlySQLly now imports and exports connections, notebooks and snippets
Import and export connections for pgAdmin, Azure Data Studio, VS Code, DBeaver, DataGrip, DbGate and pg_service.conf, plus Jupyter notebooks and VS Code snippets.
Nobody tries a new database client on a blank slate. By the time you download one, you have thirty saved connections in DBeaver, a pgAdmin server list someone curated two jobs ago, a folder of Azure Data Studio notebooks, and snippets your fingers type without asking you. Rebuilding all of that by hand is the real price of switching, and it is why most people don't.
So SQLly now reads and writes the files those tools already use. Connections from pgAdmin,
Azure Data Studio, VS Code, DbGate and PostgreSQL service files join the DataGrip, DBeaver,
TablePlus, Navicat and Redis Insight imports that were already there. Every format SQLly
reads that has a documented counterpart can also be written back out. Notebooks move as
Jupyter .ipynb files, and snippets move as VS Code snippet files.
Everything SQLly reads and writes
| Tool | File | Import into SQLly | Export from SQLly |
|---|---|---|---|
| pgAdmin | servers.json | Connections new | Connections new |
| Azure Data Studio & VS Code | settings.json, .ipynb, snippet files | Connections, notebooks, snippets new | Connections, notebooks, snippets new |
| DbGate | connection .env | Connections new | Connections new |
| psql & libpq tools | pg_service.conf | Connections new | Connections new |
| DBeaver | data-sources.json | Connections | Connections new |
| DataGrip & JetBrains IDEs | dataSources.xml | Connections | Connections new |
| Jupyter, JupyterLab | .ipynb | Notebooks new | Notebooks new |
| VS Code | .code-snippets, sql.json | Snippets new | Snippets new |
| TablePlus | Connections.plist, .tableplusconnection | Connections | - |
| Navicat | .ncx | Connections | - |
| Redis Insight | database export (JSON) | Connections, with passwords | - |
| Another copy of SQLly | SQLly connection file | Connections, optionally with passwords | Connections, optionally with passwords |
TablePlus, Navicat and Redis Insight are import-only for now. Their files are stable enough to read, but none of the three documents its format, and a file SQLly writes by guesswork is one the other tool might half-load. To take a connection to TablePlus, copy its URL from SQLly and use TablePlus’s Import from URL.
Going out matters as much as coming in
An import-only tool asks you to commit before you've decided. Export is what makes trying SQLly cheap: if it doesn't suit you, or your teammate lives in pgAdmin and isn't moving, File → Export for Other Tools writes the connections you pick in the format the other tool imports:
| Export for | File | How the other tool reads it |
|---|---|---|
| pgAdmin | servers.json | Tools → Import/Export Servers |
| Azure Data Studio / VS Code | settings.json | Merge the keys into your user settings |
| DBeaver | data-sources.json | Drop it beside your own as data-sources-sqlly.json |
| DataGrip | dataSources.xml | Paste the data sources into the Database Explorer |
| DbGate | .env | docker run --env-file, or the server's environment |
| psql and libpq tools | pg_service.conf | psql service=orders |
The picker only lists connections the target can open, so pgAdmin's list is your PostgreSQL servers and their relatives (CockroachDB, Neon, Supabase, RDS and the rest), not your Redis cache. Folders survive in both directions: SQLly projects become pgAdmin server groups, DBeaver folders and DataGrip folders, and come back as projects.
Only formats someone wrote down
Every format here is one its owner documents (pgAdmin's servers.json, DbGate's connection variables, the PostgreSQL service file, nbformat, VS Code snippets), or a plain export the tool itself reads back. That rule is why HeidiSQL, Beekeeper Studio and SSMS registered servers aren't on the list yet. Their files are private, and an importer built by guessing works right up until the next release, when it quietly starts dropping the TLS setting. The docs list those tools with the quickest way across today, which is usually copying a connection URL into SQLly's Paste URL.
Passwords stay where they are
None of these exports contains a password, even where the target format has a field for
one. Imports leave them behind too, even when the other tool kept them in the file in clear
text (Azure Data Studio's settings and DbGate's PASSWORD_ variables, for
example). SQLly asks for each password the first time you connect and keeps it in the system
keychain. The only importer that carries passwords is Redis Insight's, and only when you
ticked Include passwords when you exported; they go straight to the keychain.
Notebooks and snippets
Azure Data Studio's retirement left a lot of SQL notebooks without a home. They are ordinary
Jupyter files, and SQLly now opens .ipynb directly: code cells become SQL cells,
a leading %%sql magic is dropped, and Markdown stays Markdown. It saves back as a
standard notebook that VS Code and JupyterLab open with a SQL kernel, and
Export Jupyter in the notebook toolbar does the same for any SQLly notebook. Stored outputs don't come along. They were someone else's results
from someone else's connection, and the point of a notebook is that you can run it again.
Snippets were the easy part, because SQLly already used VS Code's placeholder syntax. Preferences → Editor → Snippets & Quick Actions has Import from VS Code… and Export for VS Code…. A snippet with three prefixes becomes three SQLly snippets, snippets scoped to Python stay behind, and if you already have a prefix, your version wins.
Try it
Point File → Import From Other Tools… at the file your current tool keeps. SQLly figures out which tool wrote it and shows what it will import and what it will skip, with reasons, before changing anything. The Compatibility section of the docs has a page per tool, covering where the file lives, what comes over and what doesn't. If your tool documents a format we've missed, send it over.