A two-table HubDB schema for a 400-SKU configurable furniture catalogue
A 400-plus SKU furniture catalogue, many of whose products came in several finishes and parts, didn't have a HubDB table that could hold those combinations without repeating columns across rows that didn't need them. We built a second, linked HubDB table for the options instead, sized against HubDB's own row ceiling.
Executive Summary
Context
A furniture manufacturer and supplier to the education sector sold more than 400 configurable SKUs across dozens of categories to schools under negotiated pricing tiers. The catalogue's finish and part options had no data model a HubDB-driven portal could read cleanly.
What We Built
We split the product catalogue into two linked HubDB tables, a SKU-keyed Products table and a separate Colours & Finishes table for configurable options, sized to stay well inside HubDB's published row ceiling.
Tech Stack
- HubDB
- HubSpot CRM
- HubSpot CMS Hub (Membership)
Not a fit if your catalogue doesn't fit comfortably under HubDB's 10,000-row ceiling, since this is a row-based design, not a relational database. It also assumes you accept SKU as the join to your CRM's line items, since HubDB can't associate rows to Line Items directly.
The Challenge
The catalogue held more than 400 SKUs, many offered in multiple finishes and parts rather than one fixed configuration. A single HubDB table with one row per SKU had no clean way to hold a variable number of finish, colour and part options, because most rows would have repeated columns they left empty. HubDB also caps every table at 10,000 rows.
The same SKU also had to show a different price depending on the buyer's contract tier, and HubDB couldn't read that from a CRM property alone.
Our Approach
We first considered adding finish and part columns directly to the Products table. That would have forced all 400-plus rows to carry the same fixed columns, and a new finish would have meant a schema change across the table.
We built a second HubDB table instead, Colours & Finishes, with Finish, Colours, Part, Price and Products columns. It models a tote box as its own Part tied to the products it applies to. SKU stays the Products table's key, the same key that joins a catalogue row to a HubSpot Line Item once a quote becomes an order, and it carries across to the lookup table.
We sized the two-table design against HubDB's 10,000-row ceiling, which leaves the 400-plus product catalogue room to grow.
Impact
A finish or part change no longer touches the whole catalogue
Because finish and part options live in their own Colours & Finishes table rather than as columns on every Products row, adding a new option means one new row there, not a schema change across 400-plus existing products.
A 400-plus SKU catalogue stays inside one platform's row limit
HubDB's 10,000-row ceiling sits far above the 400-plus products the catalogue held at launch, even counting the Colours & Finishes table's own rows, so new product lines won't force a re-architecture any time soon.
An approved quote still reaches the right line item without a native link
HubDB rows can't be associated directly to HubSpot Line Items, so SKU carries that relationship end to end: the same key identifying a catalogue row is what a Deal's line item uses once approved.
The same catalogue row can show two different prices
The portal reads the Contract Type property already set on a viewer's Company record and matches it to the price held in the Colours & Finishes table, so two schools on different contract tiers see two different prices for one row.
The Products table holds one row per physical SKU across the catalogue's 400-plus items, spanning categories such as Tables, Desks, Chairs and Storage. SKU is the key that already let a catalogue row become a HubSpot Deal line item once approved.
A second table, separate from Products, carries Finish, Colours, Part, Price and Products columns, so finish and part combinations live in their own rows, not as extra columns on the catalogue. Tote boxes are modelled as their own Part entry there, like every other option.
Holding every finish and part option as a column on the Products table was considered and dropped: most of the 400-plus rows would have carried empty columns for options that didn't apply, and one new finish would mean a schema change across the catalogue.
HubDB caps every table at 10,000 rows, a hard platform limit, not a soft recommendation. The catalogue's 400-plus products, plus the Colours & Finishes table's own rows, sat well inside that ceiling, leaving room to grow before a different architecture would be needed.
The Products table in HubDB holds one row per SKU, and a second Colours & Finishes table holds the finish, colour, part and price combinations, keyed back to those SKUs. A Company record's Contract Type property decides which price the Colours & Finishes table returns for a viewer. When a quote is approved, the same SKU joins the catalogue row to the HubSpot Deal line item, because HubDB rows can't associate to Line Items directly.
FAQ
A second HubDB table, separate from the main catalogue, carries finish, colour, part and price options as their own rows, keyed back to the product they belong to. That keeps the catalogue table at one row per SKU regardless of how many options a product has.
The price isn't stored once on the catalogue row. The portal reads the Contract Type property on the viewer's Company record and matches it against the price for that tier, so the same SKU resolves to two different numbers for two accounts.
