Build a database driver

Prepare a separate adapter for your database system or internal service. The shared GrigDesk panel can use it through the engine contract.

Development steps

1. Study the contract and package structure and the installed GrigDesk version's adapters. Define connection, query, permission and cancellation support.
2. Create a separate repository with a unique id, engine.json and an .mjs entry point. For a custom MySQL adapter, use your own id, such as team-mysql, rather than the built-in mysql.
3. Implement all eight adapter methods. If the database cannot estimate or cancel a query in a particular way, reflect that in its behavior and capabilities instead of reporting false success.
4. Start with prepared data and a separate test database. Keep initial write and cancellation experiments away from production data.
5. Tag a stable vX.Y.Z version, follow the normal installation and restart the server manually.
6. Create a test profile, open a session and verify scenarios in the panel.

What to verify

Scenario	Expected result
Connection and an incorrect password	Successful access or a useful error without revealing secrets.
Schema and query	Agreed formats for tables, columns and rows.
Read role	Query analysis and actual connection permissions prevent hidden writes.
Result limits	The driver respects limits; truncated results are not presented as complete.
A long query	The required timeout and cancellation work.
SSH, if supported	The supplied channel is used and resources close correctly.
Package update	A live session blocks replacement; the new version loads after restart.

A driver receives passwords and network access. Keep secrets out of the repository. A readOnly declaration does not replace inspecting connection permissions. An example or a successful installation does not prove readiness for production data.

Return to database drivers or connections and sessions.