vtex-io-data-access-patterns

Guide VTEX IO app data storage and read patterns across stores and APIs.

Updated Mar 27, 2026
One-click install
npx skills add https://github.com/exilonX/ap2 --skill vtex-io-data-access-patterns-exilonx
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: vtex-io-data-access-patterns
Source: https://github.com/exilonX/ap2/tree/main/.agents/skills/vtex-io-data-access-patterns
Command: npx skills add https://github.com/exilonX/ap2 --skill vtex-io-data-access-patterns-exilonx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents VTEX IO apps from storing the wrong kind of data in the wrong place, which otherwise leads to duplicated sources of truth, stale reads, and performance problems caused by unbounded queries and in-memory filtering.

Core Features & Use Cases

  • Choose the right storage for each data type: Map configuration vs business records vs cache-like documents vs authoritative VTEX domains vs external system data.
  • Make source of truth explicit: Treat VTEX core APIs as authoritative for orders, catalog, pricing, inventory, and logistics, rather than copying full payloads into Master Data or VBase.
  • Design reads and caches intentionally: Prefer bounded queries, pagination, and field selection; store only minimal derived/cached views and define freshness/invalidation rules.
  • Use as a refactor and review checklist: Audit suspicious patterns (e.g., operational logs in settings, full order mirrors in VBase) and redesign data access paths accordingly.

Quick Start

Apply the vtex-io-data-access-patterns skill to review where your VTEX IO app is storing and reading data, then refactor the flow so configuration stays in app settings/config apps, core commerce data stays in VTEX core APIs, and local copies become minimal derived views with bounded queries.

Frequently Asked Questions about vtex-io-data-access-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Where should I store data in a VTEX IO app to avoid duplicated sources of truth?

To avoid duplicated sources of truth in VTEX IO, store configurations in app settings, keep core commerce records in VTEX APIs, and use VBase or Master Data only for minimal derived views.

What is the best way to read large datasets from Master Data without performance issues?

The best way to read large datasets from Master Data without performance issues is using bounded queries with pagination and field selection, avoiding full scans and in-memory filtering.

How does VBase compare to Master Data for storing cached data in VTEX IO?

VBase handles cache-like documents and minimal derived views within your app's scope, whereas Master Data manages broader business records, ensuring neither duplicates authoritative VTEX core domains.

Can I copy full order payloads from VTEX core APIs into VBase?

No, you should not copy full order payloads into VBase. VTEX core APIs must remain the authoritative source for orders, pricing, and inventory to prevent stale reads and data inconsistency.

When do I need to refactor data access patterns in my VTEX IO application?

You need to refactor data access patterns when you detect operational logs in settings, full order mirrors in VBase, or unbounded queries causing inefficient reads and stale data in your VTEX IO app.

Does this approach require external stores for new data flows in VTEX IO?

No, this approach maps new data flows across app settings, Master Data, VBase, and VTEX core APIs first, integrating external stores only when local configuration and commerce domains cannot handle the requirements.