Data and Tools

Should developers give database access to operations teams via DataGrip?

As your product grows you may wonder if you should give database access to ops teams via DataGrip. Is it a good idea?

DataGrip is a fantastic tool for software developers to build, query, and edit SQL databases. You can connect to practically any database. With any connected database, you can create new tables, add columns, specify relationships, and insert data to your databases easily. DataGrip is a database “IDE”, short for Integrated Development Environment. As the name implies, it’s used for development. The product is super versatile for developers and it’s especially useful early during product development when you’re setting up your backend data model.

As your product grows however, you not only need developers to access the database via DataGrip but might also want to extend access to other team members, including those outside of engineering. But is it a good idea?

In most cases the answer is no. While DataGrip is a convenient way to access your database, it is not safe for non-technical team members. It’s not safe even for technical members who aren’t as familiar with the data model. It’s too easy to delete columns, table, and do a lot of damage that might impact your customer facing product.

What you’d want is a collaborative version of DataGrip, with a granular table permissions system, and ideally cloud-based interface that lets you perform and access the database in secure, limited, and predefined ways. For example, you might want to use it to support your customers, edit user profiles, toggle feature flags, etc. You might want to use it to lookup customers and orders and shipping address information.

One problem: DataGrip — and all other database IDEs such as DBeaver, TablePlus, MySQL Workbench are not built to handle these workflows. If you want to enable these workflows, you have roughly 2 choices. You can set up/build a custom app provides UI and permissions for your ops and support users to perform safe actions on the database, or your can use internal tooling platforms such as Dropbase to easily build them.

With Dropbase for example, you could create an internal web app that queries only specific tables and shares limited and controlled access to view or edit with members of your ops or support teams. These users can't accidentally delete tables or incorrectly edit a field that breaks a relationship between two tables. They get an easy to use spreadsheet-like interface to view, edit, and filter through. Best of all, you can set up these apps in minutes with just a few SQL queries.

Check out how you can turn a SQL query that you would normally write in DataGrip into a safely editable app that lets you edit data.

Insights and updates from the Dropbase team.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
By signing up you agree to our Terms of Service