Your store is already a database. It's run like a filing cabinet.

Field notes on metaobjects beyond products: tables, rows, one master copy of everything, and the schema nobody staffs.

Search any large catalog for the sentence about washing wool at thirty degrees. Not the products. The sentence.

You will find it pasted into product after product, each copy by a different hand in a different year, each slightly different. One has a typo. Nobody knows which copy is the master, because there is no master.

The geology of paste

It is never just care instructions. The ingredient list that disagrees with itself across the range. The founder bio that exists in more wordings than anyone approved. The delivery FAQ smuggled into descriptions because that is where customers actually look. The compliance line legal already fixed, except in the places nobody found.

Fixing any of these means hunting, and the catalog hides its copies well.

We used to blame discipline. Sloppy handovers, rushed copywriters, an agency that never wrote anything down. Then we watched careful, technical teams produce the same layers, paste over paste, and the theory died.

There was nowhere else to put the content.

For most of Shopify's history the content model had four shapes: products, collections, pages, blog posts. A material, a designer, a store location, an FAQ answer, none of these had a shape of its own. So each one got flattened into description fields and rewritten a little at every border crossing.

Copy-paste is not a bad habit. It is a schema decision made by nobody.

The console under Settings

The fix has been sitting in the admin for a while now, under Settings, then Custom data. Plenty of merchants have never opened it, which is fair. It is labeled like a preference pane and behaves like a database console.

Metaobjects let you define your own types. A definition is a table: name it, give it up to 40 typed fields with validation. Entries are the rows, managed under Content in the admin. Reference fields are the foreign keys, pointing rows at products, at files, at other rows.

So: define "material" once. Name, description, care paragraph, photo. One entry per fabric. Point every wool product at the wool row. The sentence about thirty degrees now exists in exactly one place, and every product that mentions it is reading, not owning.

The fences moved, too. Until October 2025, a definition topped out at 64,000 entries on most plans. Now every plan gets 1,000,000 entries per definition. Nobody needs a million care guides; the number is there to tell you what this layer is built to be.

One template, every page

The part that goes beyond products: entries can become web pages. Turn on "Publish entries as web pages" on a definition, choose which fields feed the page title and meta description, and every entry becomes a standalone page with its own URL.

The rendering side is one file: templates/metaobject/{type}.json in the theme. The first template you create becomes the default for every active entry of that definition. Build the layout once and every designer profile, care guide, and store page renders through it. In database terms, a view over a table.

Nerd detail, skip freely: storefront access on a definition defaults to NONE, so nothing leaks by accident; PUBLIC_READ exposes entries to the Storefront API; the onlineStore capability switches on webpage rendering and renderable adds the SEO fields. The new template arrives empty; sections are on you.

Who owns the schema

A store that adopts this stops being a list of products and becomes a data model of the business. Materials, guides, people, places, claims, all first-class rows with one master copy each. That is a promotion, and promotions come with responsibilities.

Standard plans get 128 merchant definitions; Plus and Enterprise get 256. That is enough room to model a business properly, and enough to build a junk drawer with extra steps. Which one you end up with depends on a question no org chart answers: who owns the schema. The naming, the types, the call on what deserves a table versus a field versus nothing at all.

Databases with no owner regress to filing cabinets. We keep meeting the evidence.

What we're keeping

• Anything the team has typed twice is a table waiting for a definition.
• Model before you migrate. Definitions are cheap; un-picking a bad schema smeared across a live catalog is not.
• Give the schema one owner. A person, not a committee, and not whoever touched it last.

The console is already in your admin, under Settings. The wool sentence is still out there, pasted and drifting, slightly different every time.

Your store is already a database.

Run it like one.

If you want to see your catalog as the data model it could be, next to the paste geology it currently is, that is the map our Infrastructure Stress-Test draws, read-only, in a few days.

Sources

1. About metaobjects: metaobject definitions, fields, entries, ownership models, and storefront access levels (NONE, PUBLIC_READ).
2. Metaobject limits: 40 fields per definition, 1,000,000 entries per definition, 128 merchant definitions on standard plans and 256 on Plus/Enterprise.
3. Metaobject theme templates: templates/metaobject/{type}.json naming, default template behavior for active entries, onlineStore and renderable capabilities, empty initial template.
4. Building web pages with metaobjects: publishing entries as standalone pages, SEO title and meta description field mapping, theme editor flow.
5. Metaobjects overview: merchant-facing concepts, use cases, definitions under Settings > Custom data and entries under Content > Metaobjects.
6. Increased limits for metafields and metaobjects: October 2025 change lifting metaobject entry limits from 64,000 (non-Plus) and 128,000 (Plus) to 1,000,000 on all plans.