Peptide Industry Master Database Outline

Overview

This database is meant to become a master source of truth for the peptide industry, not just a simple directory of peptides, vendors, and suppliers.

The goal is to model the full ecosystem:

What peptides are
What they do
Who makes them
Who sells them
How they are used
What evidence exists
What outcomes people report
What legal and quality risks exist
How all of these things relate to each other

The database should be designed as a relational system with strong join tables so it can behave like a knowledge graph.

1. Purpose of the Database

The database should support the following high-level use cases:

Build a comprehensive peptide knowledge base
Compare peptides scientifically and commercially
Track vendors and suppliers across the industry
Store and analyze lab testing and quality data
Track pricing, demand, and availability over time
Surface trustworthy insights and rankings
Power search, filtering, comparison, and recommendation features
Support future SEO, marketplace, intelligence, and analytics products

2. Core Design Principles

A. Model the ecosystem, not just listings

This should not be limited to a flat set of vendor or peptide entries. It should capture relationships between entities.

B. Separate entity types clearly

A peptide, a product, a vendor, a supplier, a study, and a protocol are all different things and should not be mixed together carelessly.

C. Support time-based data

Many important attributes change over time:

price
stock status
lab results
legal status
vendor trust
demand signals

D. Support structured relationships

The real value comes from connecting:

peptide to study
peptide to use case
vendor to product
supplier to lab result
protocol to outcomes

E. Build for intelligence later

The schema should support future scoring systems, rankings, recommendations, and trend detection.

3. Main Entity Groups

The database should be organized into the following major layers:

Core Entity Layer
Science and Evidence Layer
Commercial and Market Layer
Quality and Trust Layer
Clinical and Protocol Layer
Regulatory Layer
Relationship Layer
Intelligence and Scoring Layer
Content and Publishing Layer
Metadata and System Layer

4. Core Entity Layer

4.1 Peptides

This table stores the foundational information about each peptide.

Purpose

To define what a peptide is and capture its scientific identity.

Example fields

id
name
slug
aliases
sequence
peptide class
description
mechanism summary
half_life
bioavailability
storage requirements
stability notes
patent status
created_at
updated_at

4.2 Compounds / Products

This table represents actual sellable items in the market.

Purpose

To distinguish between the peptide itself and a commercial product or SKU.

Example fields

id
name
slug
peptide_id or product composition reference
product type
form factor
dosage
concentration
unit count
single peptide or blend
description
brand name
created_at
updated_at

4.3 Vendors

This table stores businesses that sell peptides to end customers.

Purpose

To track retail-facing entities such as clinics, telehealth brands, online peptide stores, and resellers.

Example fields

id
name
slug
vendor type
website
country
region
business description
fulfillment model
subscription model
trust status
active status
created_at
updated_at

4.4 Suppliers

This table stores upstream manufacturers and wholesale suppliers.

Purpose

To track B2B manufacturing and sourcing entities.

Example fields

id
name
slug
supplier type
country
region
website
manufacturing notes
GMP status
export capability
active status
created_at
updated_at

4.5 Brands

Optional but useful if multiple products belong to a commercial brand distinct from the vendor or supplier.

Example fields

id
name
slug
parent company
description
website
created_at
updated_at

5. Science and Evidence Layer

5.1 Studies

This table stores published research and evidence sources.

Purpose

To connect peptides to scientific evidence.

Example fields

id
title
publication
DOI
PMID
url
publication_date
study_type
species
sample_size
summary
evidence_quality_score
created_at
updated_at

5.2 Mechanisms / Pathways

This table stores biological mechanisms and pathways.

Purpose

To explain how peptides work.

Example fields

id
name
slug
category
description
pathway_type
created_at
updated_at

5.3 Use Cases / Indications

This table stores what peptides are commonly used for.

Purpose

To categorize outcomes and target goals.

Example fields

id
name
slug
category
description
created_at
updated_at

Examples:

fat loss
muscle growth
injury recovery
longevity
cognitive support
skin and hair
sexual health

5.4 Side Effects / Risks

This table stores known or reported adverse effects and risk categories.

Purpose

To track downside, not just upside.

Example fields

id
name
slug
severity
description
created_at
updated_at

6. Commercial and Market Layer

6.1 Product Listings

This table links products to vendors.

Purpose

To represent the actual commercial listing a user can buy.

Example fields

id
vendor_id
product_id
listing_url
title
current_price
currency
price_per_mg
stock_status
subscription_available
shipping_notes
created_at
updated_at

6.2 Pricing History

This table stores historical snapshots of listing prices.

Purpose

To track market changes over time.

Example fields

id
product_listing_id
captured_at
price
currency
price_per_mg
discount_notes

6.3 Availability History

This table stores stock and fulfillment changes over time.

Purpose

To track stock patterns and regional access.

Example fields

id
product_listing_id
captured_at
stock_status
lead_time
region_notes

6.4 Demand Signals

This table stores demand or popularity indicators.

Purpose

To understand what the market cares about.

Example fields

id
entity_type
entity_id
signal_type
source
value
captured_at
region

Examples of signals:

search volume
social mentions
forum mentions
traffic trend
click volume

7. Quality and Trust Layer

7.1 Lab Tests / COAs

This table stores third-party testing or certificate of analysis records.

Purpose

To track purity and quality claims with evidence.

Example fields

id
supplier_id or vendor_id
product_id
batch_id
lab_name
test_date
purity_percent
contamination_notes
endotoxin_result
heavy_metals_result
file_url
verification_status
created_at
updated_at

7.2 Batches

This table stores batch-level manufacturing lots.

Purpose

To track quality at the level where it actually matters.

Example fields

id
supplier_id
product_id
batch_number
manufacture_date
expiration_date
batch_notes
created_at
updated_at

7.3 Reviews

This table stores vendor, product, or peptide reviews.

Purpose

To capture trust and user perception.

Example fields

id
entity_type
entity_id
reviewer_type
rating
title
review_text
verified_status
source
created_at

7.4 Reported Outcomes

This table stores structured user-reported results.

Purpose

To connect products or peptides to real-world experience.

Example fields

id
peptide_id
product_id
vendor_id
dosage
duration
outcome_summary
benefits_reported
side_effects_reported
satisfaction_score
created_at

7.5 Certifications

This table stores trust and compliance credentials.

Purpose

To record whether an entity claims certifications and whether they are verified.

Example fields

id
entity_type
entity_id
certification_name
issuing_body
issued_date
expiry_date
verification_status
notes

8. Clinical and Protocol Layer

8.1 Clinics

This table stores clinics or prescribers offering peptide-related services.

Purpose

To track the medical side of the market.

Example fields

id
name
slug
website
specialty
country
region
telehealth_available
prescription_required
created_at
updated_at

8.2 Protocols

This table stores peptide use protocols.

Purpose

To model how peptides are used in practice.

Example fields

id
name
slug
purpose
protocol_type
summary
duration
administration_method
notes
created_at
updated_at

8.3 Stacks

This table stores combinations of peptides used together.

Purpose

To model common stacking behavior.

Example fields

id
name
slug
purpose
description
created_at
updated_at

8.4 Clinical Outcomes

This table stores structured medical or protocol-linked outcomes.

Purpose

To capture measurable results from protocols or clinic use.

Example fields

id
protocol_id
clinic_id
outcome_type
metric_name
before_value
after_value
duration
sample_size
notes
created_at

9. Regulatory Layer

9.1 Legal Status

This table stores peptide legality and restrictions by jurisdiction.

Purpose

To track what is allowed, restricted, prescription-only, or research-only.

Example fields

id
peptide_id or product_id
jurisdiction_type
jurisdiction_name
legal_status
prescription_required
import_restrictions
notes
effective_date
source_url
created_at
updated_at

9.2 Compliance Requirements

This table stores rules relevant to vendors, suppliers, clinics, or importers.

Purpose

To model operational compliance.

Example fields

id
entity_type
jurisdiction_name
requirement_type
summary
source_url
effective_date
created_at
updated_at

10. Relationship Layer

This is where the moat starts.

These should mostly be join tables that connect the major entities.

10.1 Peptide to Study

Links peptides to research studies.

Fields:

id
peptide_id
study_id
relevance_type
notes

10.2 Peptide to Mechanism

Links peptides to pathways and mechanisms.

Fields:

id
peptide_id
mechanism_id
strength_of_association
notes

10.3 Peptide to Use Case

Links peptides to indications and goals.

Fields:

id
peptide_id
use_case_id
evidence_strength
notes

10.4 Peptide to Side Effect

Links peptides to known or reported risks.

Fields:

id
peptide_id
side_effect_id
frequency_notes
severity_notes

10.5 Product to Peptide

Useful for blends and multi-peptide products.

Fields:

id
product_id
peptide_id
amount
unit

10.6 Vendor to Product

Represents which vendors sell which products.

Fields:

id
vendor_id
product_id
status
first_seen_at
last_seen_at

10.7 Supplier to Product

Represents which suppliers manufacture or source which products.

Fields:

id
supplier_id
product_id
relationship_type
first_seen_at
last_seen_at

10.8 Vendor to Supplier

Represents supply chain relationships.

Fields:

id
vendor_id
supplier_id
confidence_level
source_type
notes
first_seen_at
last_seen_at

10.9 Protocol to Peptide

Represents which peptides are used in a protocol.

Fields:

id
protocol_id
peptide_id
dosage
frequency
timing_notes

10.10 Stack to Peptide

Represents peptide combinations in a stack.

Fields:

id
stack_id
peptide_id
dosage
notes

10.11 Clinic to Protocol

Represents which clinics offer which protocols.

Fields:

id
clinic_id
protocol_id
active_status
notes

11. Intelligence and Scoring Layer

These tables should store derived data, not raw facts.

11.1 Peptide Scores

Purpose

Store computed scores such as:

effectiveness score
evidence score
safety score
popularity score

Example fields

id
peptide_id
score_type
score_value
calculation_version
calculated_at

11.2 Vendor Scores

Purpose

Store trust and market quality scores.

Example fields

id
vendor_id
score_type
score_value
calculation_version
calculated_at

Possible score types:

trust score
quality score
price competitiveness score
reliability score

11.3 Supplier Scores

Purpose

Store quality and sourcing confidence metrics.

Example fields

id
supplier_id
score_type
score_value
calculation_version
calculated_at

11.4 Insight Snapshots

Purpose

Store generated or computed insights over time.

Example fields

id
insight_type
entity_type
entity_id
title
summary
data_json
generated_at

Examples:

most affordable vendor this month
fastest-growing peptide in demand
suppliers with best recent purity scores

12. Content and Publishing Layer

This supports SEO and content generation.

12.1 Guides

Purpose

Store long-form content tied to database entities.

Example fields

id
title
slug
content
status
published_at
created_at
updated_at

12.2 Comparisons

Purpose

Store structured comparison pages.

Example fields

id
entity_a_type
entity_a_id
entity_b_type
entity_b_id
title
slug
summary
created_at
updated_at

12.3 FAQs

Purpose

Store reusable question and answer content.

Example fields

id
question
answer
entity_type
entity_id
slug
created_at
updated_at

13. Metadata and System Layer

13.1 Sources

This table tracks where data came from.

Purpose

To maintain traceability and trust.

Example fields

id
source_type
source_name
source_url
publisher
source_date
trust_level
created_at

13.2 Entity Source Links

This table connects records to source records.

Purpose

To support evidence-backed database entries.

Example fields

id
entity_type
entity_id
source_id
claim_type
notes

13.3 Change Log / Audit Log

Purpose

Track changes to important records over time.

Example fields

id
entity_type
entity_id
change_type
previous_value_json
new_value_json
changed_at
changed_by

13.4 Tags

Optional flexible categorization table.

Example fields

id
name
slug
category

13.5 Entity Tags

Join table for applying tags to anything.

Example fields

id
entity_type
entity_id
tag_id

14. Suggested MVP Scope

Do not build all of this on day one.

The correct MVP is narrow but deep.

Recommended initial scope

Core

peptides
products
vendors
suppliers

Evidence

studies
use cases
mechanisms

Market

product listings
pricing history

Trust

lab tests / COAs
batches
reviews

Relationships

peptide to study
peptide to use case
vendor to product
supplier to product
vendor to supplier

Intelligence

vendor score
supplier score
peptide score

15. Recommended Phase Plan

Phase 1: Foundational Database

Build the core schema and relationships:

peptides
products
vendors
suppliers
studies
use cases
product listings
lab tests
join tables

Phase 2: Data Collection and Normalization

Populate:

peptide data
vendor data
supplier data
pricing
COAs
studies

Phase 3: Intelligence Layer

Add:

trust scores
pricing analytics
evidence scoring
supplier quality rankings

Phase 4: Content and Product Features

Use the data to power:

comparisons
guides
filters
recommendations
SEO pages

Phase 5: Advanced Industry Graph

Expand into:

clinics
protocols
patient outcomes
legal status by region
deeper supply chain intelligence

16. Long-Term Vision

If built correctly, this database becomes more than a back-end.

It becomes the foundation for:

a peptide intelligence platform
a peptide marketplace
a vendor and supplier trust engine
a research and evidence hub
an industry analytics platform
a recommendation system
a defensible data moat