Slay the Spire 2 Card Database

Card decisions pile up faster than any other run decision

This page exists to cut through 577 current cards without pretending every row deserves equal attention. Most run mistakes happen before the fight starts: bad drafts, lazy upgrade reads, and cards taken because the name is familiar instead of because the shell actually needs the job.

The useful part of a card database is not the search box. It is the combination of pool, cost, rarity, epoch gate, and upgrade preview that tells you whether the card belongs in the current run or only looks attractive in isolation.

The page stays tied to the live card dataset instead of editorial guesswork

Every result on this page is generated from the current card dataset used by the site. Pool, rarity, target type, cost state, epoch metadata, search text, and the short upgrade preview all come from the same normalized source instead of being hand-entered card by card.

That matters because this page is a lookup layer, not a lore page. If a rule nuance is not cleanly exposed here, the page should point you deeper instead of inventing certainty. The database is verified against the live card data model, then surfaced with filters that match draft and upgrade decisions.

• Search covers name, text, keyword, and pool metadata.
• Epoch filtering separates core cards from unlock-dependent cards.
• Upgrade preview is a fast delta read, not a replacement for full card context.

Pool, cost pressure, and upgrade delta matter more than raw text length

In practice, the first useful question is not "what does this card say?" It is "which shell can even see it?" Pool context immediately cuts the list down. After that, cost pressure and upgrade delta decide whether the card helps the current deck or just adds another pretty line to a clogged hand.

The epoch filter is here for the same reason. A card that is not live in your current unlock state is noise. A card with a huge upgrade swing is also a different object from its base version, so this page keeps the upgrade preview visible instead of hiding the real decision behind one more click.

• Use pool first, then cost, then rarity if you need the shortest path to the relevant slice.
• Treat star-cost and X-cost entries as shell-specific, not generic pickups.
• Upgrade preview is most valuable when it changes cost, targeting, or the card job itself.

The bad habits are always the same

Players search by name, spot a familiar card, and stop reading the context around it. That is how cross-pool cards get compared as if they were competing for the same draft slot. It is also how wide databases turn into confirmation machines instead of decision tools.

The other common trap is reading the upgrade preview like a verdict. It is only a shortcut to the delta. A better number is not automatically a better pick, and a flashy text change does not tell you whether the current deck can afford the cost band or support the timing window.

• Do not compare cards from different pools without checking who can actually draft them.
• Do not use rarity as a quality score. Rare still loses if the shell cannot carry it.
• Do not mistake the preview line for a full gameplay evaluation.

Go deeper once the list tells you what card you are dealing with

Use the pages below when the database gives you the name but not the answer. The point is to move from lookup to judgment fast instead of forcing one page to fake the whole analysis stack.