JSON to a relational database
A database can accept every insert and still give you the wrong purchasing budget. See how a misplaced price corrupts a product catalog, and how Entity Enricher turns reviewed identity and relationship decisions into repeatable tables and updates.
The agent interprets your JSON and writes SQL. Supabase MCP executes that SQL through apply_migration and execute_sql. Your agent or application must supply the modeling, identity and repeated-import rules.
You review a reusable schema, including keys and shared or parent-owned relationships. The engine derives tables, constraints and structural indexes, then delivers subsequent data changes through the same model. AI helps propose the model; code applies its rules.
This comparison covers an agent building from JSON through Supabase MCP. A well-designed Supabase application can implement these safeguards too. The faulty model below is an illustration of a modeling risk, not a Supabase default or a measured failure rate.
This fictional catalog contains two product samples. Supplier SUP-7 sells a lamp for €12 and a desk for €85. The supplier is shared; the price and lead time belong to each offer.
[
{
"sku": "LAMP-01",
"name": "Reading lamp",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 12,
"lead_time_days": 3
}
]
},
{
"sku": "DESK-02",
"name": "Writing desk",
"offers": [
{
"supplier": {
"supplier_id": "SUP-7",
"name": "Northstar Supply"
},
"unit_cost_eur": 85,
"lead_time_days": 14
}
]
}
]In Entity Enricher, these are schema examples, not an automatic data import. Review the generated schema, mark the supplier as shared and the offers as parent-owned, then publish and enrich or inject matching records. Stable SKU and supplier IDs provide identity for this example.
Illustrative faulty mapping
| Column and key | SQL type |
|---|---|
| skuPK | text |
| name | text |
| supplier_idFK | text |
product.supplier_id → supplier.supplier_id
| Column and key | SQL type |
|---|---|
| supplier_idPK | text |
| name | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
Updating SUP-7 with the desk's offer overwrites the lamp's price and delivery time. The foreign key is valid. The data is wrong. This layout also limits each product to one supplier.
Entity Enricher with the reviewed model
| Column and key | SQL type |
|---|---|
| skuPK | text |
| name | text |
| Column and key | SQL type |
|---|---|
| supplier_idPK | text |
| name | text |
product 1 → N offer N ← 1 supplier
| Column and key | SQL type |
|---|---|
| product_skuPK / FK | text |
| supplier_idPK / FK | text |
| unit_cost_eur | numeric |
| lead_time_days | integer |
One supplier row is reused. Each product–supplier pair has its own price and lead time. Adding the desk's offer leaves the lamp's offer intact.
Simplified table names and natural keys; sync metadata is omitted. PK = primary key, FK = foreign key. The two offer keys form one composite key. This example assumes one current offer per pair; price histories, currencies or quantity tiers need additional modeling.
A buyer needs 100 lamps. Switch between the first and second import to see what each model returns.
Faulty model: budget for 100 lamps
€8,500
Overstated by €7,300. Your margin report and purchase forecast now use the desk's price.
Reviewed EE model: budget for 100 lamps
€1,200
The lamp's offer remains €12 with a 3-day lead time. The desk's offer is a separate row.
Illustrative arithmetic from the sample data; no database calls or measured financial losses.
Mint a new supplier ID on each import and purchases split across duplicate profiles. Spend totals and supplier comparisons become misleading.
Entity Enricher
Declared stable keys make repeated entities converge. Optional semantic IDs can help when labels vary, with matches that still need review.
A junction key starting with product_sku does not replace an index starting with supplier_id. Reverse lookups can become costly as your catalog grows.
Entity Enricher
EE generates structural indexes for its relationships, including reverse junction lookups, and avoids redundant leading-prefix indexes. Tune other indexes to your actual queries.
Your JSON gains an offer field but the target table or import SQL does not. New data fails to load or never reaches the reports that need it.
Entity Enricher
The published schema drives both table shape and data projection. Preview supported migrations before publishing; unsupported transformations are blocked.
A connection drops after an import. Without replay rules, retrying can create duplicates; an older update can replace a more recent offer.
Entity Enricher
EE supplies ordered delivery, identity-based upserts and revision guards. The PostgreSQL client applies a batch in a transaction and acknowledges after commit.
The model returns JSON, but an offer lacks a required key or the target refuses the write. A success message alone can hide missing products and offers.
Entity Enricher
Admission policies can reject an entity or omit incomplete children. EE reports partial results and tracks replica delivery separately, so you can identify what needs repair.
Rewriting unchanged offers consumes database work, maintains indexes unnecessarily and makes downstream change processing noisier.
Entity Enricher
EE detects unchanged entity state and guards row updates against unchanged values. Consumers can follow the delta feed for changes, including deletions.
Review identity, ownership and the meaning of each field before publishing. EE makes those decisions executable; it cannot prove your business model is correct. Semantic matching can make mistakes, and query performance still depends on workload and database size.
The latest enrichment replaces current state: missing values can erase earlier values, and a shorter owned-offer list removes omitted offers. Keep separate history when needed. Partial or rejected data requires correction and resubmission; a delivery status is not automatic repair.
Supabase MCP is useful when you want an agent to inspect a database and write custom SQL. EE is useful when the same data contract must keep producing consistent relational updates. You can use Supabase PostgreSQL as the destination for EE's sync client, subject to connection and database permissions. Application access policies remain yours to configure.
Reviewed September 10, 2026. Supabase provides migrations and Advisors that flag missing indexes; EE's distinction is generating and applying rules from the reviewed enrichment schema.