# Pull request reviews DBGorilla reviews the database changes in your pull requests and merge requests: migrations, schema changes and queries. It looks for issues such as migrations that take a heavy lock and queries that will miss an index, and posts what it finds on the change itself. It works with: - **GitHub**, through the DBGorilla GitHub App. See [Set up on GitHub](/docs/integrations/github-pull-request-reviews/). - **GitLab.com** on every plan, including Free, and **self-managed GitLab**, Community and Enterprise editions. See [Set up on GitLab](/docs/integrations/gitlab-merge-request-reviews/). A workspace admin sets it up in DBGorilla under **Admin › Integrations**, where each host has its own card: **DBGorilla Review for GitHub** and **DBGorilla Review for GitLab**. A card appears only when DBGorilla has made that integration available. It is available to every account at once, so a missing card means it is not available yet. There is nothing to switch on for your account. ## Diff-only and connected reviews How much the review can see depends on whether the repository is linked to a database you have connected. - **Not linked.** The review reads only the change. Working from the diff, it cannot tell you how big a table is, who still reads the column you are dropping, or how long a lock would hold. - **Linked.** The same review, plus your live schema, query traffic and query plans from the real database. DBGorilla never reaches into your databases for this. A collector you run inside your own network does the reading, as it does for everything else in DBGorilla. See [Choose your setup](/docs/connect/). ## What a review looks like Every pull request or merge request gets a review within a few minutes of being opened, and again after each push. The review has three parts. ### The summary comment The summary comment is updated in place on each push, and headed with its verdict: - No database risks found - Database concerns to address - Blocking database risk - No database changes in this pull request (or merge request) It also counts the findings by severity. On a repository that is not yet linked to a database, the summary says so and tells you what to do: > Reviewed from the diff alone. Connect your database and this review checks your > real schema and workloads. > > **To get the full review:** connect your database to DBGorilla, then link this > repository to that database. ### Inline comments Each finding gets an inline comment on the line it concerns, with the evidence behind it. ### The commit status The commit status is named DBGorilla Review. It fails when the verdict is a blocking risk. It also fails when the review could not run, for example while the review service is unavailable, and the status description says so. It passes otherwise. The status is advisory: it blocks a merge only if you require it. [GitHub pull request reviews](/docs/integrations/github-pull-request-reviews/#block-merges-on-a-failing-review) and [GitLab merge request reviews](/docs/integrations/gitlab-merge-request-reviews/#block-merges-on-a-failing-review) each explain how to require it. ### When a push fixes a finding The next review detects the fix. The bot resolves that finding's thread and replies with what fixed it. ## Connect a database The full review needs a database in DBGorilla. If you already have one, skip to the linking step on your host's setup page. Connecting a database means running a collector against it. The collector runs inside your network, reads from one or more **components**, and reports to DBGorilla. A component is one logical database endpoint: a single server, a cluster with readers and writers, or a cloud database endpoint. Everywhere else, DBGorilla calls a component a database. Follow [Choose your setup](/docs/connect/) for your platform. A component appears in DBGorilla only once the collector has sent its first topology report. Repositories are linked per component, from the component's **Settings** tab. The Settings tab has no direct URL. It is only shown to workspace admins, and only when you are looking at the whole component rather than a scope within it. The link is many to many. One component can have many repositories, and one repository can be linked to many components. A repository linked to several components is reviewed against all of them in one pass, which matters if your service writes to more than one database. Connecting a database alone does not change the review. The review is scoped by the repository being linked to that particular database, so both steps are needed. ## What the full review adds Once the repository is linked, the review reads the diff against the database it is heading for. The reviewing agent can: - read the current schema and configuration from the topology DBGorilla holds, instead of inferring them from migrations in the repository; - run `EXPLAIN` against the real database to get a plan; - look at the metrics, workload and activity for that component, so a claim about a table's size or a query's cost comes from that table and that query; - run an ephemeral experiment to test a "what if" before recommending it. The connected review is instructed not to make a recommendation it has not checked against one of those sources. The diff-only review has none of them, which is why it says so on every review it posts, including the clean ones. ## Rate limits and credits Reviews consume Gorilla Credits. When a workspace has used up its credits, the review comment gets a note that reviews are paused. They resume when the balance refreshes or Gorilla Credits are purchased. The note is appended; the existing review is not replaced. There are also per-repository and per-author rate limits, set high enough that ordinary use does not reach them. Hitting one posts a note that reviews are paused and will resume automatically.