Your realm's database is yours — and it knows everything about your world: which classes race ahead, which races fill your zones, whether your factions are balanced. Community member longasleep built these three queries while investigating his own realm (and found a real quirk doing it — see the case study below). Run them with HeidiSQL or the mysql client against your characters database (wl_characters on a standard WOW Legends install, acore_characters on stock AzerothCore).

First, pick your lens

One filter changes what question you're asking. WHERE totaltime > 0 keeps only characters that have actually played — the bot factory creates spares that never log in, and they all sit at level 1, quietly dragging averages down (on our PTR that's ~470 of 20,000).

• ✓
  With totaltime > 0 — “who's actually alive in my world”: the right lens for levelling and population.
• ✓
  Without it — “what did the factory create”: the diagnostic lens; the spares and skipped slots are the evidence (that's how the case study below was found).

totaltime > 0 beats level > 1 — a genuine level-1 bot that has played is real data.

Query 1 — which classes get ahead

SELECT
    CASE class
        WHEN 1 THEN 'Warrior'   WHEN 2 THEN 'Paladin'
        WHEN 3 THEN 'Hunter'    WHEN 4 THEN 'Rogue'
        WHEN 5 THEN 'Priest'    WHEN 6 THEN 'Death Knight'
        WHEN 7 THEN 'Shaman'    WHEN 8 THEN 'Mage'
        WHEN 9 THEN 'Warlock'   WHEN 11 THEN 'Druid'
        ELSE CONCAT('Unknown (', class, ')')
    END AS class,
    COUNT(*) AS bots,
    ROUND(AVG(level), 1) AS avg_level
FROM characters
WHERE totaltime > 0
GROUP BY class
ORDER BY avg_level DESC;

On longasleep's vanilla-races realm (bots levelling normally), this produced a clean story: Warrior 40.8, Hunter 37.2 and Rogue 36.1 on top — the three lowest-downtime classes, in order (rage and energy never drink; pets soak damage) — with the pure casters at the bottom (Priest 33.1, Druid 33.0, Mage 32.7). An 8-level spread on one realm.

Run it on our demo realm and every class sits at ~42 — because the PTR freezes bot levels (AiPlayerbot.RandomBotFixedLevel = 1, our shipped default) so starting zones never drain. What this query shows you depends on your XP settings — that's the point: it's your realm's fingerprint.

Query 2 — who fills your zones

SELECT
    CASE race
        WHEN 1 THEN 'Human'     WHEN 2 THEN 'Orc'
        WHEN 3 THEN 'Dwarf'     WHEN 4 THEN 'Night Elf'
        WHEN 5 THEN 'Undead'    WHEN 6 THEN 'Tauren'
        WHEN 7 THEN 'Gnome'     WHEN 8 THEN 'Troll'
        WHEN 10 THEN 'Blood Elf' WHEN 11 THEN 'Draenei'
        ELSE CONCAT('Unknown (', race, ')')
    END AS race,
    COUNT(*) AS bots
FROM characters
WHERE totaltime > 0
GROUP BY race
ORDER BY bots DESC;

Race counts roughly follow how many classes each race can play (that's how the bot factory rolls them: class first, then a legal race). One fun exception to look for: a race that's the only option for a popular class on its faction takes all of those slots — on vanilla race-sets, Tauren punch above their weight because they're the Horde's only druids.

Query 3 — is your realm balanced?

SELECT
    CASE WHEN race IN (1,3,4,7,11) THEN 'Alliance' ELSE 'Horde' END AS faction,
    COUNT(*) AS bots,
    ROUND(AVG(level), 1) AS avg_level
FROM characters
GROUP BY faction
ORDER BY bots DESC;

Our PTR, measured today: Alliance 10,021 · Horde 10,012 — nine bots apart in twenty thousand. On a WotLK race-set the factory's 50/50 faction coin flip works almost perfectly. On a vanilla race-set it drifts — see below.

The zone-names gotcha

Want to group characters by zone name? There's a trap: the world database contains a table called areatable_dbc that looks like exactly what you need — but AzerothCore ships those DBC-shaped tables as empty shells (0 rows, verified). Zone names live in the client's AreaTable.dbc, never in the database; the closest in-DB thing is game_tele (1,989 named teleport points — destinations, not a zone map). If you want zone names in SQL, build your own small id → name table — longasleep did, and shares it in the #bots-and-ai channel on our Discord.

Case study — what these queries found on a real realm

longasleep ran vanilla races only (no Blood Elves or Draenei) and noticed his classes looked lopsided: 673 warriors, 175 shamans. The diagnostic lens (no totaltime filter) plus these queries traced it to two things in the bot factory's creation loop working together:

• ✓
  The factory flips a faction coin first, then looks for a legal race. On a vanilla race-set, paladin and shaman are faction-locked — so half the time the coin lands on the faction that can't play them, and that bot is simply never created.
• ✓
  Account top-up passes restart from the lowest class id and stop early — so low-id classes (warrior, paladin, hunter) get created again and again, high-id ones mostly on fresh accounts.
• ✓
  Net effect on his realm: a warrior-heavy roster, shaman halved, and a +225 Alliance drift — while our WotLK PTR, same code, sits 9 bots apart. The faction balancer silently depends on the TBC races existing.

On a WotLK realm (the WOW Legends default) none of this applies — every class has a race on both factions. And on vanilla it's arguably flavour: a warrior-heavy realm fits the era. It's written up on our side either way — found entirely with the queries on this page.

Run the queries, learn your realm's fingerprint — and if you find something odd, bring it to #bots-and-ai on Discord. The best bug reports we've ever had started exactly this way. Thanks again, longasleep.