Gridex and SQLly: an AI-first client and a SQL workbench
Gridex is three native apps built around AI chat and MCP; SQLly is one Rust workbench built around SQL. Engines, agents, safety, tools and price, compared.
Gridex is a new open-source database client that a lot of people have found in the last six months. Its README calls it an “AI-native database IDE”: native apps for macOS, Windows and Linux, seven database drivers, AI chat on your own API key, and an MCP server so Claude Desktop or Cursor can work with your databases. That overlaps a good deal with SQLly, so this post sets the two side by side.
We build SQLly, so take the bias into account. We read Gridex’s README and website and the shape of its repository; we did not benchmark it. For several kinds of user it is the better choice, and we say which ones below.
Same goal, different architecture
Both projects avoid Electron and web views, and they take very different routes to native.
- Gridex is three apps. The Mac app is Swift with AppKit and SwiftUI. The Windows app is C++ on WinUI 3. The Linux app is C++ on Qt 6. Each one implements the UI separately against its own platform toolkit.
- SQLly is one app. The database engines, the parser, IntelliSense and the tools are a shared Rust core, and the UI is one Rust codebase drawn on the GPU through Metal, Direct3D or Vulkan.
Gridex’s approach gets you each platform’s own widgets, which some people strongly prefer. The cost is that the three apps drift. Its README already lists differences: ClickHouse works only on the Mac for now, and the MCP server speaks HTTP only on Windows. In SQLly a feature ships on all three platforms in the same release, because there is only one copy of it.
Gridex also has a platform win: a universal Mac build that runs on Intel. SQLly needs Apple Silicon.
Databases
| Engine | SQLly | Gridex |
|---|---|---|
| PostgreSQL, MySQL, SQLite, SQL Server | Yes | Yes |
| Redis | Yes, plus Valkey, KeyDB, DragonflyDB, ElastiCache and MemoryDB | Yes |
| ClickHouse | Yes, on every platform | macOS only for now |
| MongoDB | No | Yes |
| MariaDB, DuckDB, Oracle, libSQL/Turso | Yes | No |
| Wire-compatible services (CockroachDB, Neon, Supabase, Aurora…) | Documented and tested | Not documented |
If you live in MongoDB, Gridex has a document editor, aggregation pipelines and NDJSON backup, and SQLly has none of that. For everything else, SQLly covers more engines, and per engine it covers more ground: plans, dashboards, activity monitors and compare tools on each one. The engine list spells out which tools work on which engine.
AI and MCP
This is where Gridex puts its weight, and where the two projects make different calls.
Both apps have an AI chat that can see your schema. Gridex supports Claude, OpenAI, Gemini and a local Ollama, with your own key and requests sent straight to the provider. SQLly supports cloud providers and on-device models and labels which features stay on your machine.
Both also ship an MCP server, so an agent outside the app can use your saved connections. Their permission models differ:
- Gridex lets agents write, with approval. Its MCP server has schema, read and write tools, including
insert_rows,update_rows,delete_rowsandexecute_write_query. Each connection is locked, read-only or read-write. A row-count estimate warns about bulk changes, you approve each write, a rate limiter caps calls, and every call lands in an activity log. The Gridex website lists the MCP server under its Pro tier, which is in early access. - SQLly never lets an agent write.
sqlly-cli mcplets an agent list connections, read schemas and run oneSELECTat a time. That query runs in a transaction the database itself keeps read-only (BEGIN READ ONLYon PostgreSQL,START TRANSACTION READ ONLYon MySQL) and then rolls back, so even a function that writes behind aSELECTcan’t change anything. If the agent wants to change data, it sends a proposal. SQLly shows you the exact SQL, and you run it or decline it. Production connections are refused outright.
Neither model is wrong. If you want an agent that fixes data for you, Gridex’s approach does that and keeps an audit trail. If you want agents to look but never touch, SQLly’s approach leaves you nothing to approve by mistake at 2am. One idea we plan to borrow: Gridex’s activity log, which answers the question “what did the agent do last night?”.
Writing SQL
Gridex’s editor has tabs grouped by database, syntax highlighting, autocomplete, run selection, and a searchable history. That covers the basics.
SQLly puts most of its effort here. IntelliSense
tracks aliases and scope, writes a JOIN ON clause from real foreign keys, pulls a
column’s actual values into a WHERE clause, and flags a GROUP BY
mistake while you type. The editor also has query parameters, templates, multi-cursor editing,
split views, folding, and AI ghost text.
Results
Gridex’s grid sorts, filters and pages. You can edit cells inline, and edits wait as pending changes until you commit them together in one transaction. You can copy rows and export CSV, JSON or SQL.
SQLly’s grid streams rows to disk, so fifty million rows use about as much memory as fifty. On top of that grid are pivots, charts, conditional formatting, computed columns, result diffs and Excel export, and a one-line comment can save the layout with the query.
Safety
Gridex’s security work is concentrated on its MCP server: permission modes, an SQL sanitizer, an identifier validator and the approval gate. We couldn’t find equivalent guardrails documented for a person typing in the editor.
SQLly’s guardrails apply to everyone, including you:
SELECT-only connections that block file-reading and shell-escape tricks, a hard stop on
UPDATE or DELETE without WHERE, automatic rollback,
tenant checks, and an optional AI review before a data change. You set them on a client,
project or environment, and every connection under it inherits them.
Admin tools
Gridex has a structure viewer, function and procedure inspectors, Create Table and Create Database
sheets, an ER diagram, and backup
and restore. Its backups are especially broad: pg_dump, mysqldump,
native SQL Server BACKUP, and built-in dumps for MongoDB, Redis and ClickHouse. Its
site lists a connection monitor, scheduled jobs, cross-database sync and a visual query builder
for Pro.
SQLly has the full DBA set under one Tools menu: Activity Monitor, query plans on nine engines, schema and data compare, Query Store, SQL Agent, an index analyzer, a test data generator, disk usage and backup and restore. Anything destructive opens as SQL in a tab for you to read first.
What they cost
Gridex Community is free, needs no account, and its source is Apache 2.0. Pro is in early access with no published price. SQLly has a free tier for hobbyists (two saved servers), a one-time $100 SQLly 1.x license, and a $200 Lifetime license; see pricing. If “free for the whole company” or “open source” is a requirement, Gridex meets it and SQLly does not.
Which one to pick
Pick Gridex if:
- You need MongoDB.
- You’re on an Intel Mac.
- You need open source, or free at any company size.
- You want an AI agent to change data for you, with approval and an audit log.
- You mostly browse tables and run simple queries.
Pick SQLly if:
- You work in SQL Server or Azure SQL, or in DuckDB, Oracle or libSQL.
- You write a lot of SQL and want completions that know your data.
- You want guardrails on your own queries, not only on an agent’s.
- You read plans, compare schemas, or watch server activity.
- You want one app that behaves the same on every OS you use.
The fair test is your own database. Both apps install in a minute and neither needs an account to start. The side-by-side table is at SQLly vs Gridex, and SQLly’s download is free.