Choose the project or direct connection
Open Database inside a DevDock project. When DevDock has detected a Laravel application, Project (.env) uses the database configuration already associated with that project and exposes its framework-aware database tasks. This keeps migration and maintenance actions attached to the same folder and run-history model as the rest of the application.
Choose Add database for a direct SQLite, MySQL/MariaDB, or PostgreSQL connection. Direct connections are session-only: DevDock does not save the password to preferences or command history. Test the connection before relying on it, and remove it from the session when the work is complete.
- Use Project (.env) for a detected Laravel application and its migration-aware tools.
- Use a direct connection for an existing SQLite file or a MySQL, MariaDB, or PostgreSQL server.
- Select Required SSL for a remote server unless its documented environment requires another mode.
- Treat a production database as a separate, explicitly reviewed target.
Understand the supported database engines
Direct database tools support an existing SQLite file, MySQL or MariaDB through the MySQL command-line clients, and PostgreSQL through its command-line clients. DevDock validates the connection fields, tests the server, and reports the database engine, version, and connection latency when the test succeeds.
SQLite schema inspection and record lookup open the selected file read-only. MySQL and PostgreSQL queries use the database clients available on the computer, pass credentials through process environment variables rather than command arguments, and honor the selected SSL mode.
- SQLite requires an existing absolute file path.
- MySQL and MariaDB operations require the appropriate mysql and mysqldump clients.
- PostgreSQL operations require psql and pg_dump.
- A successful test proves the selected credentials can reach the database; it does not prove every maintenance permission is available.
Inspect schema before querying
The schema panel identifies whether its information comes from project files or a live database. For a Laravel project, DevDock reads bounded PHP migration and model files to describe tables, fields, types, primary keys, and recognizable relationships without executing application code.
For a direct connection, DevDock reads live table and column metadata from SQLite, MySQL/MariaDB, or PostgreSQL. Review the source label before treating the schema as authoritative: project files describe intended structure, while the live database describes the structure actually deployed at that connection.
- Use project-file schema to review intended Laravel structure before connecting.
- Use live schema to confirm actual columns, nullability, primary keys, and foreign-key relationships.
- Investigate differences with migration status instead of assuming either view is current.
Find records with a constrained lookup
Find records is deliberately narrower than a general SQL editor. Select a validated table, optionally choose one field and exact value, then request 10, 25, 50, 100, or at most 200 rows. Leave both the filter field and value empty for a bounded sample.
DevDock validates table and column identifiers and encodes filter values instead of interpolating them as executable SQL. The lookup is read-only, but the returned rows can still contain personal or confidential application data; review the selected environment and table before running it or sharing the result.
- Confirm the connection label and database name first.
- Use the smallest useful result limit.
- Prefer an exact identifier, email address, or other stable field over broad sampling.
- Do not treat the result panel as a safe place to expose production customer data.
Export and restore native backups
Export backup writes a native backup for the selected engine. SQLite uses its backup API and replaces the destination atomically; MySQL/MariaDB uses mysqldump with transactions, routines, and triggers; PostgreSQL uses pg_dump without restoring ownership or privilege metadata by default.
Import backup changes the destination database and always requires destructive confirmation. DevDock first checks that the selected backup is readable; SQLite additionally validates the database and prevents using the destination file as its own source. Confirm the engine, source file, connection, and overwrite scope before proceeding.
- Create a fresh export before a risky migration or maintenance operation.
- Store the backup outside disposable build and temporary directories.
- Verify that the export can be opened by the corresponding database tools.
- Never use an import action as an exploratory way to inspect an unfamiliar backup.
Use Laravel diagnostics and maintenance
Detected Laravel projects receive structured actions for migration status, database overview, slow-table checks, table inspection, export, import, seeding, and wiping when the corresponding project task is available. Results remain connected to the DevDock project and run history.
Pending migrations compare migration files with batches applied to the selected project database. Table diagnostics can show size, counts, indexes, foreign keys, views, and timing information. Seed and wipe actions modify data or structure and require the stronger confirmation level assigned to them.
- Run migration status before applying framework migrations.
- Inspect a table before diagnosing records that depend on its keys.
- Keep seed and wipe actions out of automatic daily workflows.
- Review the visible executable, arguments, working directory, and target in every confirmation dialog.
Troubleshoot without weakening safety
If a direct connection fails, check the host, port, database, username, SSL requirement, and local client availability. A server can accept a connection while denying schema access, backups, or restores, so distinguish authentication failure from operation-specific permissions.
If a lookup returns the wrong shape, confirm whether the schema source is project files or the live database, then verify the selected table and exact filter. If an export or import fails, preserve the error and destination path, confirm free disk space and client versions, and retry only after the cause is understood.
- Do not disable SSL merely to make an unexplained remote connection succeed.
- Do not broaden database privileges before identifying the missing operation.
- Remove a session connection and recreate it if its target is ambiguous.
- Use an engine-native client to verify a backup independently when recovery matters.