Skip to content

Historical table for gitlab_subscriptions table

What does this MR do?

This is a database-based history log for the gitlab_subscriptions table. It saves the previous row in gitlab_subscriptions into gitlab_subscriptions_histories

See Issue #13297 (moved)

Data Estimations

  • On Gitlab.com we expect < 50K records per month: 5K pure updates and 20K records per month updated + rare deletions

Background

Currently our GitLab.com gitlab_subscriptions table only captures the current state of our data. This is blocking us from doing any meaningful analysis on our subscriptions because we can only see who's subscribed right now. We have no data on who was subscribed two weeks ago or even two hours ago, all we know about is the state in this current moment.

The reasoning is because of the backend design of our application. In our database all records are overwritten to reflect the current state, which is a good design from an application point-of-view, but makes analysis of our data impossible. This "throwing out" of data is causing GitLab Inc. to miss out on capturing tons of valuable information.

For example: if a customers starts a trial on gitlab.com, we'll create a gitlab_subscriptions record with trial=true. If they later upgrade to a Gold plan, the existing record gets overwritten with a new record that has trial=false. By throwing out all information about the trial ever existing, we'll never be able to measure the value or success of trials at GitLab. The exact same thing can be said about free plans, we currently have no way to see any of those conversions.

Screenshots

N/A

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Alper Akgun

Merge request reports