The Problem

Database IDEs typically require separate clients per database engine, creating context switching overhead and inconsistent feature sets across tools. Teams managing multiple database types waste time learning different interfaces and maintaining separate connection workflows.

What This Does

Gridex is a native cross-platform database IDE built with Swift and AppKit that consolidates seven database drivers (PostgreSQL, MySQL, SQLite, Redis, MongoDB, SQL Server, ClickHouse) into a single application. The codebase organizes across four main layers: linux/src/Presentation handles the UI layer with 200+ view and viewmodel files, linux/src/Domain contains use cases and repositories (~30 files), linux/src/Data implements database adapters and persistence (15 adapter files plus SecretStore.cpp/h and repository pattern implementations), and linux/src/Core defines protocols, enums, and error types (IDatabaseAdapter.h, GridexError.h, enums for connection modes and SSL settings). A dependency injection container at linux/src/App/DependencyInjection/DIContainer.cpp/h wires the architecture. The app includes a built-in MCP server, AI chat interface, ER diagram generation, query optimization visualization, and backup functionality — all sharing a common DatabaseAdapter protocol (~50 methods) so features work identically across engines.

How It Is Wired

Execution begins at linux/src/main.cpp, which initializes the Swift/Qt application and displays the main workspace. Connection workflows route through ConnectDatabase.cpp in the Domain layer, which interacts with IConnectionRepository.h to persist connections managed by AppConnectionRepository.cpp. Database operations flow through the adapter factory (AdapterFactory.cpp/h) which selects the appropriate driver (PostgresAdapter, MysqlAdapter, SqliteAdapter, RedisAdapter, etc.) based on connection configuration. The adapter implementations handle wire protocol communication — PostgresAdapter.cpp for PostgreSQL, MysqlAdapter.cpp for MySQL, SqliteAdapter.cpp for SQLite, RedisAdapter.cpp for Redis, plus MongoDB, MSSQL, and ClickHouse adapters. The MCP server component lives in linux/src/App/MCP/MCPConnectionProvider.cpp/h. The AI chat functionality uses ILLMService.h protocol with ChatGPTTokenBundle.h for token management, and AIChatView.cpp/h for the UI. The ThemeManager.cpp/h handles theming across dark/light modes via QSS stylesheets. The SqlHighlighter.cpp/h and AutocompleteProvider.cpp/h provide query editing features. The ExplainVisualizerWidget.cpp/h and related files (ExplainPlanParser.cpp/h, ExplainPlanHeuristics.cpp/h) visualize query execution plans. The ERDiagramView.cpp/h and ERDiagramExporter.cpp/h generate entity-relationship diagrams. The call graph has a hub at DIContainer.cpp — changing dependency resolution requires touching this file, which has wide blast radius across all modules. The adapter layer (Data/Adapters/) carries the widest individual blast radius since adding or modifying a database driver requires changes to this directory's ~15 files without a shared interface beyond the IDatabaseAdapter protocol.

How To Use It

Setup: No build-from-source commands are documented in the repository structure provided. The README offers download links for packaged distributions: macOS universal DMG, Windows Velopack installer, and Linux x86_64 AppImage. A Package.swift file exists at the root for Swift Package Manager, and linux/CMakeLists.txt drives CMake-based builds on Linux. Docker is detected in the tech stack.

Configuration: Environment variables or connection configuration files are not mapped in the provided structure. The ConnectionConfig.h and ConnectionConfigJson.h files in Core/Models/Database/ suggest JSON-based connection configuration, but no .env or schema for required variables is present in the root or .github/workflows/ci.yml.

Running it: Download the appropriate packaged distribution from the README links or from releases. The app launches as a native database IDE with MCP server and AI chat enabled out of the box.

Real-World Use

A developer opens Gridex and adds connections to PostgreSQL, MySQL, and Redis instances. They write a SQL query in the query editor with syntax highlighting and autocomplete (SqlHighlighter.cpp, AutocompleteProvider.cpp), execute it, and view results in the DataGrid view. The Explain Visualizer (ExplainVisualizerWidget.cpp) decomposes the query plan for performance analysis. They generate an ER diagram for a schema, chat with an AI assistant about the results (AIChatView.cpp), and trigger a backup from the Backup Progress Dialog (BackupProgressDialog.cpp). All features work consistently across the different database engines due to the shared adapter protocol.

Code Health & Issues

  • 736 total files with no structural red flags detected (tests/CI/license/lockfile present where expected)
  • 28 test files found
  • 10 documentation files found
  • C/C++ Header: 235 files, C++: 185 files, Swift: 181 files
  • Dependency injection container at linux/src/App/DependencyInjection/DIContainer.cpp/h serves as a hub with wide blast radius for changes
  • Database adapter layer (linux/src/Data/Adapters/) has ~15 implementations sharing IDatabaseAdapter protocol — adding a new driver requires updating this directory
  • CI/CD via GitHub Actions configured at .github/workflows/ci.yml

The Bottom Line

Gridex delivers a rare single-app experience for seven database engines with a consistent UI and feature set, all built natively with Swift. The modular adapter pattern and DI container provide reasonable extensibility, though the DI container is a coupling point worth noting for anyone planning to add non-trivial new dependencies. It's worth evaluating if your team needs cross-database query editing, schema visualization, and AI-assisted chat in one package — but verify the packaged distribution meets your OS and version requirements before committing to integration.