This article is my personal notes on Umamusume's master data, a.k.a. master.mdb or just "the mdb." Most of the notes are oriented toward my work on this website. It is an in-progress translation of my broader but more sparse notes into a more agreeable, navigable, and consistent form.

master.mdb is an SQLite database that the game downloads to your device. On Windows, you can find it at %USERPROFILE%\AppData\LocalLow\Cygames\Umamusume\master\master.mdb. Hakuraku has a master data explorer that you can use on the website.

Generally speaking, I am only documenting what I feel is important, both in terms of tables and columns. That does occasionally include documenting some things as being unimportant.

Roughly speaking, master data contains all the numbers needed to display the game's user interface, including during races. Skill data, support card effects, Grand Concert lesson definitions, and so on are in there. If trying to access some data in-game shows a "Connecting..." indicator while it loads, it probably isn't in the mdb. Notably, this includes everything related to career event outcomes. (Event information on sites like GameTora and GameWith are massive crowd-sourced efforts.)

Since I see this question about weekly, allow me to reiterate.

Support card event outcomes are not in master.mdb or any other locally stored file. Not even the list of possible skills.

This document is oriented toward programmers with understanding of SQL databases. Mentions of Gallop:: are references to types visible in decompilations of the game, but no C# knowledge is needed.

The text_data table contains most non-story strings in the game. Queries look up entries by category and index, i.e. SELECT "text" FROM text_data WHERE category=? AND "index"=?.

Some important categories:

• 6 is character names, 4 is [variant] character name, 5 is [variant], 14 is clothing names.
• 47 is skill names, 48 is skill descriptions.
• 75 is support card names including variant, 76 is support card variant, 77 is support card character.
• 147 is spark names, 172 is spark descriptions.
• 33 is race name by race ID, 28 is race name by race instance ID, 31 is race courses, 111 is saddle names.
• 65 is player titles, 66 is title descriptions.
• 119 is scenario full titles (e.g. The Beginning: URA Finale), 120 is scenario descriptions, 237 is scenario names (e.g. URA Finale).
• 130 is epithet names, 131 is epithet descriptions.

Other categories are usually easy enough to figure out by inspection. Text data categories have proper names given in Gallop::MasterString.Category, but a few categories that have useful strings are missing from there.

First, some terminology, as the game uses it internally. (Some UI phrasing disagrees.)

A race is an organized running competition, typically held annually. A race instance is a single holding of a race at a specific date and time; this includes special race instances like Team Trials races, Aim for the Stars races, &c. Race instances are held on a given race course, which is a fixed-length segment of a physical location called a race track. A win saddle is a given horse's victory of a race or a specific group of races, e.g. Classic Triple Crown or Dual Grand Prix. This section will cover races, race instances, race tracks, race courses, and win saddles.

text_data categories relevant to races include:

• 32 and 33 are both race names, the latter for jikkyo (the announcer's lines).
• 28 is race instance names. 29 is abbreviated race instance names, e.g. Mile Ch. instead of Mile Championship.
• 31 and 34 are race track full names, the former for jikkyo, e.g. Kyoto Racecourse. 35 is race track names without "Racecourse".
• 111 is win saddle names.

Races are defined in race, which is quite a direct name innit.

• Race ID is just id.
• group is the game situation where the race occurs. {#each raceGroups as [id, name] (id)} {/each}

  Group	Meaning
  {id}	{name}

• grade defines the race grade. {#each raceGrades as [id, name] (id)} {/each}

  Grade ID	Meaning
  {id}	{name}

• course_set gives the race course where the race occurs.
• thumbnail_id is the resource ID of the race's thumbnail image.
• entry_num is the maximum number of horses that can run the race.

Some races are ostensibly defined twice to account for variant races run during some characters' careers, e.g. Maruzensky's five opponent Spring Stakes, McQueen/Ryan/Rice's Kyoto Takarazuka Kinen, &c.

The table is race_instance.

• id is the race instance ID.
• race_id joins with race.id.
• npc_group_id should define the NPC racers allowed to appear in the race instance, although I haven't looked into it.
• date gives the month and day-of-month when the race instance occurs, expressed as M×100+d – 1 Jan is 101 and 31 Dec is 1231. This appears to decide the season that the race instance occurs in and thus the applicable green skill. E.g., we can see in career that Challenge Cup is offered on the Early December turn, but its race instance has a date of 1130 (i.e. 30 Nov), so it is a fall rather than winter race. All races occur in 2019.
• time is the time of day that the race instance is held. {#each raceTimes as [id, name] (id)} {/each}

  Time	Meaning
  {id}	{name}

• clock_time has a value of 1605 for one race and is otherwise always 0. It might be a specific hour and minute that a race instance occurs, but I'm not sure why that would ever matter.
• race_number takes every value between -1 and 12, but I couldn't find any explanation for it.

Similarly to races, some race instances are ostensibly defined twice to account for variant races run during some characters' careers.

Since race tracks are the physical locations where races are held, there are not many rows in race_track. Most of its purpose is to define appearance characteristics, but some fields are mechanically relevant.

• id is the race track ID.
• initial_lane_type describes the starting lane positions of each horse by determining the location and width of the gap between posts. {#each raceInitialLanes as [id, gate, w] (id)} {/each}

  ID	Gap After Gate	Gap Width (CW)
  {id}	{gate}	{w}

  Horses in gates after the Gap After Gate listed in this table have the gap width added to their starting lane. initial_lane_type is 2 on Oi, Kawasaki, and Funabashi; 3 on Longchamp; 4 on Morioka; and 1 elsewhere. (The race mechanics doc's description of initial lane uses horse index rather than gate number and describes lanes in units of horse lanes rather than course widths.)
• area defines the geographic region where the race track exists. {#each raceAreas as [id, name] (id)} {/each}

  ID	Region
  {id}	{name}

Race courses are physical segments of race tracks. They are defined in race_course_set.

Most tracks have one or two turf loops (the "(Inner)" and "(Outer)" or sometimes "(Outer→Inner)") and one dirt loop. The length of a race course is determined solely by the position of the gates: since the race course is a physical structure with the audience stands in a specific location, and since said audience wants to see the race finish clearly, courses of all lengths end at the same place on the front stretch. The straight opposite the front stretch is called the backstretch. Corners are counted backward from the front stretch in the order 4, 3, 2, 1; all races except Ibis Summer Dash include corners 3 and 4, while long and sometimes medium races run corners multiple times. Some courses start on an extra segment of the track which is neither straight nor corner (which means straight_random==1 skills won't fire there).

• id gives the race course ID.
• race_track_id joins with race_track.id.
• distance is the race course length in meters.
• ground is 1 for turf and 2 for dirt.
• inout gives the loop for the surface type where the race occurs. {#each raceLoops as [id, name] (id)} {/each}

  ID	Loop
  {id}	{name}

• turn gives the handedness of the track, i.e. the direction from horses to the rail as they round the track's corners. {#each raceRotations as [id, name] (id)} {/each}

  ID	Handedness
  {id}	{name}

  Stretch types have no corners and do not activate or or their variants. Niigata 1000 is the only such race course in the game.
• float_lane_max gives the initial race course width in units of ten thousandths of course widths. (Confusingly, no race course has a width of 1 course width.) Some race courses have locations where the lane max changes, but these are defined as events and are not in the mdb.
• course_set_status_id joins with race_course_set_status.course_set_status_id to define the stat thresholds. A value of 0 means no thresholds. {#each raceCourseThresholds as [id, stat1, stat2] (id)} {/each}

  race_course_set_status

  course_set_status_id	target_status_1	target_status_2
  {id}	{stat1}	{stat2}

  Status of 1 is Speed, 2 is Power, and so on up to 5 for Wit. 0 means no (second) threshold.

Characteristics like straight and corner locations, slopes, lane max changes, &c. are not in the mdb. They are defined as assets instead and must be extracted using special tools.

single_mode_wins_saddle defines the awards given to the horse (not the player) for winning a race or specific group of races. These are the medals displayed as important wins for a horse at the end of a career. They are now purely aesthetic, but I am documenting them anyway because I have the notes already since they used to determine affinity.

• id is the win saddle ID.
• priority is the sort order for win saddles.
• group_id associates multiple win saddles for the same race, for horses whose careers have special versions of some races.
• win_saddle_type is the type of the win saddle, used to determine the color of the medal displayed. {#each raceSaddleTypes as [id, name] (id)} {/each}

  ID	Type
  {id}	{name}

  Special win saddles are for win saddles requiring multiple wins, e.g. Classic Triple Crown.
• race_instance_id_1 through race_instance_id_8 define the race instance IDs that must be won to be awarded the win saddle. Columns beyond race_instance_id_3 are unused.

The table single_mode_program defines the race instances offered each turn in a career. Confusingly, races that permit both classic and senior year horses are only defined here once.

• race_instance_id joins with race_instance.id.
• race_permission gives the career years that offer the race. (More precisely, it gives the age ranges of horses that are permitted to enter.) {#each racePermissions as [id, name] (id)} {/each}

  ID	Meaning
  {id}	{name}

• month and half give the turn that the race is held.

I was unable to identify whether any of the columns indicate maiden races, despite the UI restrictions on when they can appear.

Relevant text_data categories include 47 for skill names and 48 for skill descriptions. Otherwise, info for skills lives in skill_data.

• Skill ID is just id.
• rarity is 1 for common (white) skills, 2 for rare (gold) skills, 3 for 1☆/2☆ uniques, 4 for 3☆ uniques of horses upgraded from 1☆ or 2☆, and 5 for full 3☆ uniques.
• group_id groups skills that replace each other when purchased. E.g., , , , and all have a group_id of {fallGroup}. Unique skills are generally alone in their groups.
• group_rate gives the relative strength of a skill within its group. Negative (purple) skills always have a group_rate of -1. For skills that have non-purple versions (i.e. not skills like ), the base version has a group_rate of 1 and each successive upgrade is 1 higher. E.g., is 1, is 2, , and is -1. Skills that have only common and rare versions instead assign a group_rate of 2 to the rare.
• grade_value is the amount the skill adds to a horse's rating when owned. Higher tiers of skills within a group replace the lower ones rather than adding to them, so is worth its listed grade value of 174, not 's 129 plus 174.
• skill_category gives the category where the skill is listed in the skills tab at the paddock: {#each skillCategories as [cat, name] (cat)} {/each}

  Category ID	Category
  {cat}	{name}

• tag_id gives a slash-separated list of three-digit tag values that various other mechanics can match against. E.g., Copano Rickey's unique skill counts the number of skills activated with tag values between 601 and 615 to determine the multiplier on its extra effects; mechanics like GL shop skills and MANT rivals match tags for running style (101 to 104), distance (201 to 204), and/or surface (501 and 502); and I expect that support card unique effects like Mejiro Ramonu will count "speed-increasing skills" by looking for tag 401. {#each tagMeanings as [tag, name] (tag)} {/each}

  Tag ID	Inferred Meaning
  {tag}	{name}

  E.g., has a tag_id of 401/403/603 (as text, including the slashes). The tagged skills explorer allows you to see skills by their tags.
• For inherited unique skills, unique_skill_id_1 holds the ID of the non-inherited version. When it is the inherited unique from an upgraded 1☆/2☆ horse, unique_skill_id_2 holds the ID of the 1☆/2☆ version of the unique.
• exp_type appears to be 1 when the skill is able to gain levels, i.e. is a unique skill.
• activate_lot is 1 if the skill uses a wit check.
• disp_order is the sort order used in the skill purchase menu.
• icon_id is the resource ID of the skill's icon.
• There are quite a few other columns which may be useful but which I have not bothered to figure out.

skill_data additionally holds skill conditions and effects, described in the next section.

Skills have one or two skill details, also called triggers. The first skill detail has column names with _1 appended, and the second has _2. Each skill detail has:

• precondition_1 (resp. precondition_2): Precondition text, if the skill has one, otherwise empty.
• condition_1: Condition text. (Skills like which always activate have always==1.) If the skill has only one detail, then condition_2 is empty.
• float_ability_time_1: Base duration expressed in ten thousandths of a second, or -1 for passives, or 0 for instantaneous skills (recoveries, ).
• ability_time_usage_1: Scaling type for the skill duration. {#each durScalingTypes as [id, name] (id)} {/each}

  Type	Duration Scaling
  {id}	{name}

  GameTora and the race mechanics doc describe duration scaling types in more detail.
• float_cooldown_time_1: Base cooldown duration expressed in ten thousandths of a second, or 5000000 (500s) for skills with no cooldown, or 0 for passives.
• Columns for three abilities, described in the next section.

This SQL query parses all conditions and preconditions to obtain all distinct combinations of skill condition types, operators, and arguments. This may be useful to tool authors.

Each skill detail has up to three abilities, all of which apply for as long as the skill detail is active (except for AdditionalActivate abilities). Column names append _1, _2, or _3 after the skill detail's own number.

• ability_type_1_1 (resp. ability_type_1_2, ability_type_1_3, ability_type_2_1, ability_type_2_2, ability_type_2_3) define what simulation parameter the ability affects. {#each abilityTypes as [typ, name, units] (typ)} {/each}

  Type	Effect	Value Units
  {typ}	{name}	{units}

  Types with (?) don't exist in my decomp but are used on skills in the copy of the JP mdb that I have, which I'm told is "from like 3 weeks ago" at the time of writing. Those marked (unused) do exist in the decomp, but are not used for skills even on JP.
• ability_value_usage_1_1 defines special scaling for the ability's value. {#each valScalingTypes as [id, name] (id)} {/each}

  Type	Value Scaling
  {id}	{name}

  GameTora describes value scaling types in more detail. (The race mechanics doc is missing most of them.)
• additional_activate_type_1_1 indicates abilities that only activate on additional events while the skill detail is active. {#each addlActivateTypes as [id, name] (id)} {/each}

  Type	Meaning
  {id}	{name}

• ability_value_level_usage_1_1 indicates how the ability scales with skill level (i.e. unique level, not double circle vs single circle). {#each levelUsageTypes as [id, name, inst] (id)} {/each}

  Type	Meaning	Instances
  {id}	{name}	{inst}

• float_ability_value_1_1 is the base magnitude of the ability's effect, expressed in ten thousandths.
• target_type_1_1 describes which umas the skill targets. It takes target_value_1_1 as an argument. {#each targetTypes as [id, name, arg] (id)} {/each}

  Type	Meaning	Argument
  {id}	{name}	{arg}

  Skills that take maximum targets as an argument use a target_value_1_1 of 18 to mean unlimited. Type 23 is internally named ActivateHealSkill, so it may instead mean something like "horses who activated a heal skill this frame." It is only used for and its gold.

The table skill_level_value defines the coefficients by which each ability's value scales with unique level. Curiously, it defines coefficients up to level = 10 for each ability_type, even though the maximum achievable level is 6.

The float_ability_value_coef column is a multiplier on the corresponding skill ability type's float_ability_value_?_?, expressed in ten thousandths.

The table single_mode_skill_need_point lists the SP cost of each skill.

• id is the skill ID.
• need_skill_point is the SP cost.
• status_type and status_value are always zero.
• solvable_type is nonzero for some negative (purple) skills that are applied and later healed during careers, for Sweep Tosho, Air Shakur, and Daitaku Helios. Some other JP negative skills that GameTora has no source information for also have it.

Internally called succession factors. Relevant text_data categories include 147 for spark names and 172 for spark descriptions, both indexed by factor ID.

Queries should join with succession_factor inside.

• Spark ID is factor_id. This identifies the combination of spark variety and its star level.
• factor_group_id gives the variety. E.g., the star levels of the February S. spark are factor IDs 1000101, 1000102, and 1000103, but all three have group ID 10001.
• rarity is the star level, 1-indexed.
• grade is 2 for unique (green) sparks and 1 otherwise.
• factor_type is roughly the color type of the spark plus extra subdivisions for white sparks: {#each sparkTypes as [typ, name, cls] (typ)} {/each}

  Type ID	Spark Type	Color
  {typ}	{name}

  Types 8 and above should release with 4anni.
• effect_group_id may give something like the distribution of spark effects. For current Global data, it's in bijection with factor_type × rarity. It doesn't join with anything else in the mdb.

succession_factor_effect defines all possible effects that each spark can yield (but not their distributions). Effects are organized by factor_group_id rather than by factor_id, which implies to some degree that all star levels of a given spark have the same possible results with different distributions, although it is possible that some values have zero probability for some star levels.

The process by which the game determines the effects of a given spark proc during (Classic and Senior) inspiration is as follows, or semantically equivalent.

1. The server chooses a random effect_id from the hidden distribution for the spark's effect_group_id.
2. The client (and server) selects all rows matching the spark's factor_group_id and the random rolled effect_id, i.e. SELECT target_type, value_1, value_2 FROM succession_factor_effect WHERE factor_group_id = $current_spark_factor_group_id AND effect_id = $random_choice_effect. There may be several such effects.
3. For each result row, apply the effect according to the target_type, with value_1 and value_2 as its possible arguments: {#each sparkEffects as [target, name, val1, val2] (target)} {/each}

   target_type	Description	value_1 Usage	value_2 Usage
   {target}	{name}	{val1}	{val2}

   When effect 41 applies to a skill which is already at its maximum hint value (including from previous spark procs in the same inspiration), a small amount (1-5, perhaps?) of some number (one? two?) of random stats is applied instead, but the details of this are not known.

E.g., all succession_factor_effect data for Lovely Spring Breeze (Mejiro Bright's green spark) is:

When the spark procs, the server rolls an effect ID of 1, 2, 3, or 4 according to some hidden distribution, then it applies all four effects with that effect ID.

succession_initial_factor defines thresholds for initial inspiration, i.e. the immediate effects of sparks upon starting a run. There is not much consistency to its format, but it has only thirteen rows, reproduced here.

There are six rows with factor_type = 1, referring to blue sparks. value_1 refers to the star level of each individual spark. value_2 identifies whether the effect applies to starting stats (0) or raised max stats (1). add_point is the amount to add to the respective field.

Pink sparks, i.e. factor_type = 2, have four rows. value_1 is the lower threshold of total star count, and value_2 is the upper threshold. add_point is the number of levels to raise the corresponding aptitude.

factor_type = 3 for unique sparks has three rows. add_point is always 0. The (value_1, value_2) pairs are (1, 1), (2, 2), and (3, 4), but the meaning is unclear; all rows for this factor type were added in the 1 Jul patch that introduced raised stat caps, so one would expect it to be related to those. (In particular, it does not appear to be related to the starting skill hints.)

In all cases, there is no direct association between the spark and its actual initial effects. They must be derived from the spark's normal effects instead.

Relevant text_data categories include 75 for name including variant, 76 for variant alone, 77 for character name. Category 151 gives support card effect names, 154 gives effect descriptions, 150 gives unique effect names, and 155 gives unique effect descriptions.

Support card event outcomes are not in master.mdb or any other locally stored file. Not even the list of possible skills.

Queries should join with support_card_data inside.

• Support card ID is just id.
• chara_id links to character. Implements the "no supporting yourself" and "no duplicated characters" rules.
• rarity is 1 for R, 2 for SR, 3 for SSR.
• exchange_item_id is the type of item you get for exchanging duplicates.
• effect_table_id joins support_card_effect_table.
• unique_effect_id joins support_card_unique_effect.
• command_type is generally 1 for normal support cards and 0 for pals and groups, but Throne is 1 as well. Probably not important.
• command_id gives the specialty type: 101 for speed, 102 for power, 103 for guts, 105 for stamina, 106 for wit, 0 for pal and group. There is no 104.
• support_card_type is 1 for normal cards, 2 for pal, 3 for group.
• skill_set_id gives the hint list via support_card_data sc JOIN single_mode_hint_gain h ON sc.skill_set_id = h.hint_id AND sc.support_card_id = h.support_card_id. Given that you have to use the support card ID anyway, this seems redundant.
• outing_max is the number of recreation events with the card, for pals and groups.
• effect_id is the specific instance of Pure Passion the card can grant, for groups.

support_card_effect_table gives progressions of support card stats. There is one row per stat per support card. Unique effects are not included.

• id joins with support card ID.
• type is the stat type (text_data category 151): {#each supportCardEffects as [typ, name] (typ)} {/each}

  Type ID	Effect
  {typ}	{name}

• init is the card's value at level 1, then there are subsequent limit_lv5, limit_lv10, &c. up to limit_lv50. Each value is either a threshold value for the corresponding level, or -1 to indicate that the value should interpolate per level between the previous positive value (defaulting to 0) and the next (defaulting to no interpolation).

Unique effect data is in support_card_unique_effect.

• id joins with support_card_data.unique_effect_id, but it's also always the same as the support card ID, never deduplicated or anything. (This ID is also used for unique effect name lookup, after all.)
• lv gives the level at which the unique effect becomes active, one of 25, 30, 35, or 40.
• type_0 and type_1 give the effect type ID with the corresponding magnitude in value_0 or value_1, largely same as for support_card_effect_table.type. However, there are some extra types:
  • 101 is a friendship gauge check. value_0 is the threshold value, and then value_0_1 and value_0_3 give the effects that become active at that threshold with their magnitudes in value_0_2 and value_0_4, respectively.
  • 102 is Guts Bakushin's special effect of Training Effectiveness (magnitude in value_0_1) when both above a friendship threshold (value_0) and not on her own specialty.
  • 103 is Agnes Ditigal's special effect of Training Effectiveness (magnitude in value_0_1) when the deck has at least value_0 different colors.
  • 104 is Narita Top Road's special effect of Training Effectiveness of maximum magnitude value_0_1 divided by each group of value_0 fans.
  • 105 is +value_0 initial stat to the specialty of each card in the deck and +value_0 initial all stats per pal and group card.
  • 106 is stacking effect per rainbow training, where value_0 is the maximum number of stacks, value_0_1 is the effect type granted by the stack, and value_0_2 is the value per stack.
  • 107 is scaling with how low energy is. value_0 is obviously the effect type ID that scales, but the other parameters are unclear. Currently only Bamboo Memory Guts has this, with value_0_1⪙4 being (10, 30, 15, 5).
  • 108 is scaling with maximum energy. Similar to 107, value_0 is the effect type ID that scales, but the rest is unclear, with values of (100, 75, 5, 20) for Pearl.
  • 109 is scaling with total friendship across all cards. value_0 is the effect type ID that scales, value_0_1 is the amount of bond required to increase the effect by 1.
  • 110 is scaling with the number of cards at the training. value_0 is the effect type ID that scales, value_0_1 is the amount per card.
  • 110 is scaling with the number of cards at the training. value_0 is the effect type ID that scales, value_0_1 is the amount per card.
  • 111 is scaling with training facility level. value_0 is the effect type ID that scales, value_0_1 is the amount per level.
  • 112 is Nakayama Festa Wit's value_0% chance to disable failure chance.
  • 113 is an additional effect active for rainbow training. value_0 is the additional effect ID, value_0_1 is its value.
  Certainly more types will follow.
• idle_mode_sub_rate is uncertain, but it is likely related to Independent Training (called idle single mode internally, where "single mode" is in turn the internal name for career). It takes only a few values:
  • For unique effects that don't vary, it is always 0.
  • For those that vary with the deck composition (Agnes Digital, Satono Diamond Wit), it is 10.
  • For effects that activate with 80+ friendship, it has a value of 20.
  • For 100+ friendship effects, fan count scaling, rainbow training stacking effects, effects scaling with energy or max energy, scaling with number of cards trained with, scaling with training level, and scaling with total deck friendship, it has a value of 30.

Lastly, the table single_mode_hint_gain lists the effects of hints during career.

• hint_id joins with support_card_data.skill_set_id, but it isn't unique; e.g., Seiun Sky SR has the same hint_id as prior Seiun Sky cards, despite having a different hint list. Unclear what it actually does. Doesn't seem useful for my purposes.
• support_card_id is effectively the lookup key.
• hint_group ties together the results of one hint. Skill hints are generally one each, but stat hints have two or three rows with matching hint groups.
• hint_gain_type is 0 for skill hints and 1 for stat hints.
• For skill hints, hint_value_1 is the skill ID, and hint_value_2 is always 1; presumably the latter could serve as the base value of hint levels. For stat hints, hint_value_1 is the stat ID – 1 for speed through 5 for wit, or 30 for skill points – and hint_value_2 is the amount to add.
• group_id, condition_set_id, and priority are only nonzero for Haru Urara Power, whose unique effect includes "hint event effectiveness" and who has upgraded stat hints. It's unclear exactly how it works or why it takes three columns to implement.