Setting Up DBeaver/DataGrip for Universal Database Access

DBeaver setup for access to different databases

At an engineer's workstation, DBeaver usually grows organically: a dozen manual connections to production, test, and staging environments, custom connection names, passwords partly in local storage and partly in notes.

Source drivers are updated differently for each person, so the same database connection works differently for two people — or does not work at all.

The cost of such laissez-faire is visible in the details.

Production and test in the list differ by a single host character, and a change request goes to the wrong place; post-update verification is postponed because "it did not start locally." A new person, instead of working, spends the first week collecting access details from colleagues, and when an engineer leaves, some connections disappear along with them.

DBeaver setup is not about manually filling in fields, but about making connections a managed artifact.

Connection settings are exported to a shared template, source drivers are pinned to an agreed branch, security parameters — read-only mode, timeouts, channel encryption — are set once for everyone.

Credentials are not stored in the profile but issued through a shared provider, so access is revoked with one operation instead of visiting every machine.

Environments are separated separately: production and test are marked differently both at the connection level and at the level of granted permissions. We explain how this is handled in practice.

What a unified database connection profile provides

A unified profile is a preassembled set of connection parameters: driver, address template, tunnel, credential source, schema filters, and transaction mode.

An engineer does not assemble a connection manually from fragments in chat, but imports the profile and immediately gets working access. In DBeaver, profiles are exported and versioned together with the rest of the team's configuration.

The first effect is connection time. A newcomer opens the test environment within the first minutes, not after messaging an administrator: addresses, ports, and tunnel parameters are already set. The "it connects for me but not for you" discrepancy disappears as a class.

The second is access errors. Credentials are taken from a secure vault, each engineer has their own account instead of a shared one.

The production environment opens in read-only mode, with automatic transaction commit disabled and a color label — an accidental edit in the production database no longer depends on attentiveness.

The third is a unified way of working with test and production environments. Switching between them is a profile change, not a change of tool and habits: the same schema filters, the same query plan view, the same hotkeys.

Differences are reduced to connection parameters and permission level, so a skill honed on test carries over to the production database without surprises.

The result is measurable: first connection time is counted in minutes, and incidents with incorrect permissions and "grant access" requests become many times fewer.

DBeaver setup for different access modes

DBeaver stores connections in a local workspace: drivers, tunnel parameters, schemas, saved credentials.

While there is only one engineer, this is convenient, but as the team grows, the same database is configured differently for everyone, and access revocation turns into messaging.

Therefore, the access mode is chosen based on the number of people, the presence of contractors, and connection audit requirements.

Compatibility of modes rests on the fact that a profile is a set of configuration files, not a record inside the application: it can be versioned in a repository and transferred between the editor and other clients.

Secrets are kept outside the repository; otherwise, a shared team profile turns into a shared leak. Switching between modes is re-importing the profile and verifying that drivers, permissions, and tunnel rules work on a test connection before access is issued to the team.

Workflow: from connection audit to handover

The workflow is the same for one engineer and for a team of several dozen people: first we collect facts, then we design access, and only then do we touch production databases.

The route is predictable, and the main risk — lost access to production during an incident — is removed in the first steps.

1. Connection audit. We collect profiles from engineers' machines, connection strings in service configs and scripts, and passwords spread through chat. The output is a list of sources marked with who accesses them and why.
2. Access scheme. We sort sources by environment and role: who needs view access, who needs edit access. We separately record where secrets are stored and who issues them.
3. Setup on the test environment. In DBeaver, we assemble connection profiles, drivers, timeouts, and tunnels on a copy of the production schema: the same tables and permissions as in production, but without risk.
4. Verification on the test environment. We break things intentionally: drop the tunnel, change the password, shut down a node. We check whether the client reconnects and whether the engineer gets a clear error instead of freezing.
5. Connection policy. We describe how to create a new connection, what production permissions are by default, how to request extended access, and what to do when an employee leaves.
6. Documentation handover. We provide workstation setup instructions, profile exports, templates, and a source map — the team creates connections on its own.

Set of configurations, schemes, and access policies

The set is needed not for documentation as such, but so that database connections are reproducible rather than assembled anew on each engineer's machine. Below is what exactly remains with the customer after client setup.

• Connection configuration files — exported connection profiles with hosts, ports, databases, and schemas by environment. Passwords and tokens are not stored in them: only references to the secret vault, so the files can be kept in a shared repository.
• Profile templates — separate sets for development, staging, and production. The production profile initially comes with read-only access, so an accidental change request does not go to the production database.
• Access permission scheme — which roles exist on the DBMS side, what each can see, where read permissions end and structure change permissions begin. The scheme shows how roles are projected into the client and who owns each one.
• Connection instructions — a step-by-step procedure for a new engineer: driver installation, profile import, access verification through the tunnel, common errors and what they mean.
• Access rotation policy — credential lifetime, revocation procedure when an employee leaves, who initiates reissue, and how it is confirmed that old access is closed.
• Source inventory — a list of databases indicating environment, owner, and purpose, so that when a new database is added, it is clear where to include it.
• Connection check script — a quick test that separates a network problem from a permissions problem: first host availability, then authentication, then visibility of the required schemas.

All of this is versioned and updated together with infrastructure changes, rather than remaining in chat.

Case study: transition from manual connections to a shared profile

The customer's product department worked with three environments at once: development, pre-production, and production. Each engineer created connections in the client themselves — taking the address, port, tunnel, and schema from chat or memory.

A new person on the team spent two to three hours on their first working access, and half the questions in the general chat began with "where do I connect?"

What it was like before

Over a quarter, the database support service handled dozens of access issuance requests: some were duplicated, some were created for pre-production instead of the production environment.

Twice a data change request went to production from a connection the engineer considered test — investigating each such case took a day and required manual log reconciliation.

What was changed and what was achieved

We assembled a shared connection profile in DBeaver: connection templates with environment variables, separate sets for read and write, tunnels defined inside the profile.

The production environment received an explicit color label, a ban on automatic transaction commit, and confirmation before executing a write.

Permissions are issued by groups — access follows the person when they change teams, rather than being created manually, and the rules themselves are stored in the repository alongside the code and go through review.

After implementation: connecting a new engineer takes 15–20 minutes including the tunnel and permission verification, access requests have decreased by about five times, and errors with production databases are zero. A whole class of mistakes where a query goes to the wrong environment is gone.

What to do if database access was already granted manually?

Manual access does not need to be revoked in order to establish order.

A managed scheme is built on top of existing connections: first an inventory — which accounts are granted access to which databases and with what permissions — then the same permissions are described as configuration in the repository. Issuance continues to work; nothing is switched over in a single day.

Inventory is needed to separate active access from forgotten access: some issued permissions usually remain from long-closed tasks. Each permission is described by a declaration — role, access level, term — and goes into the shared template.

Saved connections, filters, and scripts in DBeaver are not lost: the profile is exported and transferred, and addresses and database names remain the same, so nothing is reconfigured on the engineer's side.

Backward compatibility is a key condition of the transition. New permissions are already issued from the template, old manual ones continue to apply until the team is confident that the new path covers working scenarios.

Discrepancies are visible during reconciliation: if someone accesses a database outside the template, this is recorded and addressed in advance, rather than surfacing during an incident.

Implementation proceeds by environment and team, not in a broad wave: first the development environment, then test stands, then production databases.

At each step, rollback is preserved — returning to the previous issuance is possible without stopping work, because the way permissions are managed changes, not the permissions themselves.

The result: the transition takes days, not months, and proceeds without downtime. Already issued access becomes part of the managed scheme, rather than technical debt that is scary to touch.

Describe how access is issued for you now — we will come back with a transition plan and an estimate.

Frequently asked questions about database access and permissions

Before starting, technical doubts usually surface rather than organizational ones: where credentials are stored, how not to grant excessive permissions, what to do with non-standard sources, and whether the environment will survive an engineer change. We address what is asked most often.

How to separate permissions between roles?

Access is granted by roles on the DBMS side, not by client settings: analytics gets a read-only account, development gets a separate one for writing to specific schemas.

This cannot be bypassed from the interface, so server logs provide an audit: you can see who connected, when, and what queries they ran.

What about rare data sources?

We connect through drivers: document, columnar, and legacy versions are usually available; the question is driver compatibility with the client bitness.

We record the driver set and connection parameters in the environment description so they do not have to be selected again during migration.

How is the environment handed over to a new person?

The connection profile is exported or deployed by script together with drivers and query templates. A new engineer gets working access in minutes, not days of messaging, and does not carry someone else's saved passwords with them.

Let's discuss the task and come back with a work plan

A work plan comes not from general words but from specifics: the more accurate the initial data, the fewer assumptions in the estimate. Below is a list of what is needed from the customer to start, and how the work is structured further.

• List of databases and storage systems: which systems we connect, how many environments — development, test, production, and whether there are read replicas.
• Network access scheme: where databases are deployed, what traffic goes through, whether there are closed segments, intermediate nodes, and tunneling requirements.
• Permission model: which employees should see which data, how accounts are structured, where secrets are stored, and how rotation is performed.
• Data protection constraints: connection audit rules, work outside the office, requirements for channel encryption and query logging.
• Current difficulties: which connection errors are already reproducible, how much time is spent connecting a new engineer and switching between environments.
• Workstation preferences: which clients are already used, what is unsatisfactory, whether a unified settings profile is needed for the team — for example, when migrating to DBeaver, some parameters are transferred by a configuration file.

Then the order is as follows: a 30–40 minute call, review of the list and clarifying questions on non-obvious points, then we come back with a timeline estimate, scope of work, and a stage-by-stage plan — what we do first, where access is needed from your side, and at what point we verify the result on a live database.

Describe the task in free form: which databases, how many people, and what is hindering you now. We will clarify what is missing and come back with a plan and timeline.