Tracking Game Assets in Notion, Confluence, and Airtable: Where General-Purpose Tools Fall Short

Why teams reach for the tool already open

A game team that needs to track cosmetic assets reaches for whatever is already in the browser. Notion is popular with indie studios. Confluence arrives free with Jira, which most studios already run. Airtable draws teams who want spreadsheet freedom with database structure. All three will hold asset data. The trouble starts at scale, once the catalog passes 100 items, each item carries several variants, and the team wants filtering, media, pipeline tracking and access control at the same time.

What follows are the friction points we see over and over in real cosmetic pipelines, tool by tool.

Notion: a database you design yourself

Notion's strength is freedom. You can build a database with any properties, embed images, link pages and save views. For a small catalog, that is enough. Four things break as it grows.

No variant hierarchy

Notion databases are flat. A hoodie with five colorways becomes either five rows in one database, repeating the shared mesh, category and description on each, or a parent page with five sub-pages, which costs you the ability to filter and sort variants as one list. Notion has no parent-child asset-variant model where the parent holds shared data and each child holds per-version data.

You can work around it with relation properties that link an Assets database to a Variants database. That means designing a custom schema, configuring every filter, view and rollup by hand, and repairing all of them the next time the schema changes.

No 3D preview

Notion embeds images and video. It will not render .glb or .gltf. An artist who wants to see a mesh with a variant's texture on it opens a second tool, and the gap between the record and the picture stretches every review cycle.

Images sit in the page, not in a field

Notion images live in page content rather than in structured fields with sort order, primary flags and gallery views. A variant with six reference images is a page with six images pasted down it. Nothing exposes an image gallery to the API, no thumbnail field exists, and no call returns the primary image for variant X.

Permissions stop at the page

Notion shares at the workspace, page or database level. You cannot grant edit access to variant records and read-only access to project settings. On a team where artists edit content, QA reviews it and producers own the taxonomy, you choose between over-permissioning everyone and fielding access requests all week.

Confluence: a wiki holding tables

Confluence is a documentation tool, and studios use it well for design documents, technical specs and meeting notes. Some teams also press it into asset tracking, usually as tables on wiki pages.

A table is not a database

A Confluence table is a formatted block of text. You cannot filter it by rarity, sort it by status, or search every table in a space for one asset name. Each query is a scroll or a Ctrl+F.

No relations

Confluence holds no typed relationships between records. An asset page cannot point at its variants in a way software can read. You can paste hyperlinks, and you can assemble the list of variants by hand, one link at a time.

History stops at the page

Confluence records that a page changed. It does not record that the price of Variant X moved from $15 to $10. An audit needs field-level history, which Confluence has never offered.

No media management

Like Notion, Confluence embeds images inline: no thumbnail fields, no galleries with sort order, no 3D rendering. Textures and mesh previews live in other tools.

The Jira argument

The strongest case for Confluence is the Jira licence you already pay for. Production tasks live in Jira, so asset data in the same suite feels tidy. Jira issues make poor asset records, though. A ticket reading "texture the Desert Camo variant" holds none of that variant's price, rarity, status, thumbnail or release target in a field you can query. You end up with production in Jira, asset data in Confluence, and nothing structural joining them.

Airtable: the closest fit, still generic

Airtable is the strongest of the three. It has typed fields, relations, filtered views and a usable API, and a team that invests the setup time can build a working asset tracker. The cost shows up in what Airtable leaves to you.

You build the whole schema

Airtable hands you a blank database. Every field, relation, view and validation rule is yours to create. The asset-variant hierarchy, rarity system, pipeline statuses, tag taxonomy, currency fields and release versioning that PolyDrobe ships on day one take hours to assemble in Airtable, then more hours each time the schema evolves.

No 3D preview

The same gap as the other two. Airtable stores image attachments and renders no meshes, so previewing a model means opening an external viewer.

Statuses carry no meaning

Airtable's single-select fields can hold status names. The system attaches no semantics to them: nothing knows that Review follows In Progress and precedes Approved, nothing blocks an invalid transition, and no view reports pipeline throughput.

The price climbs

Airtable's free tier stops at 1,000 records and 1 GB of attachments. A catalog of 200 assets with 5 variants each fills that before you add a single supporting table. Pro starts at $20 per seat per month and counts everyone who needs to look at the data, so a team of 8 pays $160 a month for a tool they still have to configure.

PolyDrobe's free plan covers 1 project with unlimited assets, 100 variants, 1 GB of storage and 3 members, and Viewer seats stay free on every plan.

What a purpose-built tool brings

Notion, Confluence and Airtable all ask you to build an asset management system out of generic primitives. PolyDrobe ships the domain structure instead:

When a general-purpose tool is the right call

If your catalog holds 50 items, none of them have variants, nobody needs 3D preview and the team is three people, use Notion or Airtable. A dedicated tool earns nothing at that scale.

The break point tends to arrive around 100 items with variants, or the day a third teammate joins and access control turns into a question. From there, maintaining a custom schema in a generic tool costs more time than setting up a project in PolyDrobe and importing the data.

Key takeaways

• None of Notion, Confluence or Airtable ships an asset-variant hierarchy, 3D preview, pipeline statuses or field-level audit trails.
• Building a game asset tracker in a generic tool costs you the schema work up front and the maintenance forever after.
• Confluence handles asset data worst of the three: its tables are text, and it holds no relations.
• Airtable comes closest, and asks for manual setup plus per-seat pricing that climbs with the team.
• PolyDrobe ships the domain structure, media management and team roles on day one.
• The free plan holds enough assets and variants to test the approach on your own catalog.