This wiki contains many databases[1] regarding WARFRAME's contents and requires monthly updates to reflect on the accurate data of the game's contents. This article is meant to help editors understand how these databases interact with content on the rest of the wiki as well as how to update them. No programming experience nor wiki editing experience is needed to update our databases.

Contents of /data subpages can be downloaded to your local machine by adding the ?action=raw query string to the end of the URL of the respective subpage. These can be converted to other formats like JSON or CSV using external Lua libraries such as json-lua or cerial.lua. As a disclaimer, use the aforementioned libraries at your own risk as the wiki is not responsible for any damages that may occur.

Last updated: Sat, 13 Nov 2021 03:09:22 +0000 (UTC) by User:Cephalon Scientia

List of Databases[]

Databases are denoted by /data which is the database subpage of a particular Lua module page.

How To Update[]

You must be a logged-in autoconfirmed user on the wiki to edit most of /data subpages on the wiki. This is to prevent vandalism and to uphold the integrity of our data. To be an autoconfirmed user, Fandom accounts must be at least four days old and had made 10 edits around the wiki before being able to edit these database pages. Otherwise, the contents of these pages will be publicly available in read-only mode.

To quickly find the right table entry to update, use your browser's CTRL + F hotkey or the wikitext source editor's search button in the toolbar under the "Advanced" tab.

If you make any syntax errors, the editor will alert you after you attempt to submit changes. Just navigate to the line number where it tells you an error occured and add the missing tokens before resubmitting. Common syntax errors include:

  • Missing a comma (,) at the end of key-value pairs
  • Forgetting a closing curly bracket (}) for tables
  • Invalid key name; if you want spaces or special characters in the key, make the key a string and put it inside square brackets like so: ["Key with spaces and colon:"] = "Some value"


Our databases are in the form of Lua tables which have a similar syntax as JSON files, albiet tokens and delimiters are based on the Lua programming language.

Sample table:

TableKey = {
	KeyName = "Some string value",
    ["Another Key Name w/ Spaces"] = true,
    AnotherKeyName = { "Table values", "preferably", "be the same", "data type" },
    Integer = 2,
    Float = 3.1415926535897

These tables are parsed by the respective Lua module to be outputted to wikitext on pages that {{#invoke:}} a function from that particular module. For example, Module:Weapons/infobox uses data from Module:Weapons/data to generate the infobox for a particular weapon. Template:WeaponInfoboxAutomatic calls the buildInfobox() function in {{#invoke:Weapons/infobox|buildInfobox}} so any weapon article that uses/transcludes Template:WeaponInfoboxAutomatic will automatically generate the wikitext for the infobox as seen on Braton.

Possible Entries[]

There are limitations to the type of data that can be stored in these databases. Lua tables only support the following data types as values that are mapped to keys or as indexed elements:

  • Boolean (e.g. true or false)
  • Integer number (e.g. 10)
  • Float/decimal number (e.g. 2.5)
  • String (e.g. "Text")
  • Table (e.g. { "This", "is", "a", "table with", 6, "elements" })

Despite functions being able to be stored in Lua tables, MediaWiki does not allow modules to read tables with functions as values so avoid adding these at all costs.

Maintaining and Updating[]

The following are the most important databases to update first in order of priority:

  1. Module:DropTables/data - WARFRAME Drop Tables
  2. Module:Weapons/data - used by weapon articles, Weapon Comparison, Template:WeaponNav (through a processed subset of the data on Module:Weapons/ppdata), and tooltips
    • Lots of people rely on the comparison table for Disposition values (Riven Mods), comparing weapon stats, and determining what is "meta"
  3. Module:Void/data - used by relic articles, Prime weapon/Warframe articles, Void Relic, and tooltips
    • These pages have high traffic whenver a new Prime Access or unvaulting is released since the in-game Codex is not very specific on drop chances of relics
  4. Module:Mods/data - used by mod articles and tooltips
  5. Module:Warframes/data - used by Warframe articles and tooltips
  6. Any other database related to content that was recently updated (e.g. Module:Baro/data if Baro Ki'Teer appears with new items)

Update Frequency[]

The frequency of updates are about once every three months (i.e. every quarter to match new Prime Access release) or every time a major mainline update is released by the developers. Minor updates can be made during downtime to fix values or to add additional data. Note that it is easier to add more data than to remove existing ones; wiki articles may already depend on old data to generate the pages' content so removing old/depreciated data is a more difficult task and would most likely require additional development time in the respective module pages.

New Content Update Frequency
Database Approximate Frequency
Module:Version/data Daily or weekly depending on hotfix/update schedule
Module:Baro/data 2 weeks, every other Friday when Baro Ki'Teer visits
Module:TennoGen/data 1-6 months, depending on TennoGen schedule
Module:Weapons/data 1-3 months, every other mainline update; Disposition update every 3 months with Prime Access
Module:Resources/data 1-3 months, every other mainline update
Module:DropTables/data 1-3 months, every other mainline update
Module:Enemies/data 1-3 months, every other mainline update
Module:Void/data 3 months, Prime Access or Prime Vault release
Module:Warframes/data 3 months, Prime Access release
Module:Ability/data 3 months, new Warframe release
Module:Cosmetics/data Update as needed
Module:Codex/data Update as needed
Module:Arcane/data Update as needed, rarely updated
Module:Focus/data Update as needed, rarely updated
Module:Research/data Update as needed, rarely updated
Module:Modular/data Update as needed, rarely updated
Module:Conservation/data Update as needed, rarely updated
Module:DamageTypes/data Update as needed, rarely updated
Module:Missions/data Update as needed, rarely updated
Module:Decorations/data Update as needed, rarely updated


  • Please use tabs for indentation instead of spaces.
  • Read the documentation above each /data subpage for sample formatting of key-value pairs. If there is no documentation written, try your best to follow the convention established in the Lua table entries


  • Some databases have a /data/validate subpage where editors can view to find errors in table entries.

For Developers[]

Database Design Guidelines[]

When designing new /data subpages of modules or adding new keys to existing /data tables:

  • Key names should be in TitleCase. If a key stores data that are meant to be used within modules and not presented to readers, prepend an underscore (_) in front of key name.
  • Keys should map to one value type and only that value type; do not mix and match value types otherwise it will cause more overhead in checking each individual value's types before performing a certain operation on that value. This also helps with script performance at runtime by reducing the number of conditional checks.
  • Tables should not be both array-like and dictionary-like. Stick to one usage of tables for consistent behavior when iterating over values.
  • If possible, map values to a key for faster access, especially when tables get extremely big. Internally, Lua implements table types as hash tables.[2]
    • Do not assume that keys represent data nor should they be treated as such. Keys are used to index a specific data table for faster access. It may be possible for an index to share the same value as a key-value pair inside the table, but this does not guarantee anything about the index as data. In most instances, the index will copy the Name key's value since it is more intuitive to look up data entries based on an item's in-game name.
  • Keep wikitext/HTML formatting outside of database entries as much as possible. In other words, prohibit (or at the very least limit) the use of wikitext syntax and HTML elements in string values. Databases should contain raw, unprocessed data. Any modifications to this data to display on the wiki should be done in main Lua modules and/or submodules. This is done to decouple data from business logic and user interface design like in a three-tier architecture.
  • Exported tables should not contain functions and/or metatables as values. These tables are strictly used to store data in the form of numbers, strings, booleans, and other tables.
  • Since most content in these databases will be presented to wiki readers, avoid storing string values in all capital casing or all lower casing. Use proper sentence casing or title casing instead.
  • Do not assume that an item's name is the same as its associated article's name on the wiki. Scenarios such as items with the same name, items with similar functions and/or type being represented under one generic article, items with not enough information to justify having its own page, formatting differences, or different localization may cause an article to have a different name than the item.
  • Tables should allow inversion using an inverted index to support different methods of indexing entries. For example:
    ["Abundant Mutation"] = {
    	BaseDrain = 6,
    	Image = "AbundantMutationMod.png",
    	Introduced = "27.5.4",
    	Link = "Abundant Mutation",
    	MaxRank = 3,
    	Name = "Abundant Mutation",
    	Polarity = "Zenurik",
    	Rarity = "Rare",
    	Tradable = true,
    	Transmutable = false,
    	Type = "Nidus" 
    Can be manipulated to be indexed by Type:
    ["Nidus"] = {
    	BaseDrain = 6,
    	Image = "AbundantMutationMod.png",
    	Introduced = "27.5.4",
    	Link = "Abundant Mutation",
    	MaxRank = 3,
    	Name = "Abundant Mutation",
    	Polarity = "Zenurik",
    	Rarity = "Rare",
    	Tradable = true,
    	Transmutable = false,
    	Type = "Nidus" 
    In the case that a particular inverted key has 
    multiple possible table entries, the inverted key 
    should instead map to a array-like table with each 
    element being a separate table entry.

Seeding New Databases[]

If creating new /data subpages, one could look to writing a script that parses Mobile Export or https://github.com/WFCD/warframe-items to automate the creation of new Lua tables based on existing JSON data. For Luafying data that exist on one or across many articles on the wiki, one could use Special:Export to export the contents of articles based on category or a manually created list to an XML format for extracting data programmatically. However, if what you are creating is completely new, then unfortunately, you may have to create the Lua tables by hand or write them down in a spreadsheet somewhere before converting it to Lua.

  1. As a footnote, for simplicity's sake, we use the term "database" to refer to data stored in Lua tables on /data subpages of Lua modules in a NoSQL-like format. These are not true databases in the traditional sense with advanced features like indexing, data validation, and stored procedures. In reality, these are executable programs that return Lua tables with data.
  2. https://www.lua.org/doc/jucs05.pdf