The Amazon data warehouse your team would have built.

Schema-versioned raw layer. Query it with whatever you already use. You keep the keys.

databrill_amazon.sql
-- A daily P&L join across orders, ads, and FBA fees.
-- Tables ship documented; you write the marts your team needs.

with sales as (
  select * from databrill_amazon.order_items
),
ads as (
  select * from databrill_amazon.ad_spend_daily
),
fees as (
  select * from databrill_amazon.fba_fees
)
select
  date_trunc('day', s.purchase_date) as day,
  sum(s.item_price) - sum(a.spend) - sum(f.fee_amount) as gross_profit
from sales s
left join ads a on a.asin = s.asin and a.day = s.purchase_date::date
left join fees f on f.order_item_id = s.order_item_id
group by 1

The Amazon raw layer is a graveyard

Every brand we talk to has a half-built SP-API job. Token rotation works most of the time. The retry logic was added after the last incident. The schema breaks twice a year. Nobody owns it.

We own that layer. Your team owns the marts.

Engineering choices we made on purpose

Idempotent loads, not "eventually consistent"

Every report has a deterministic primary key. Re-running a window produces the same rows, never duplicates.

Semver-tagged schema migrations

Pin a schema version. Upgrade on your timeline with a changelog and a documented migration path.

Audit columns on every row

`source_run_id`, `synced_at`, `report_window_start`, `report_window_end` — full lineage back to the SP-API call.

Raw archive in your S3

Every original report is stored as JSON in your bucket. You can re-derive any table, forever.

No vendor semantic layer

We don't pre-compute "your" margin. Your team decides what margin means in your own queries. Boring is the point.

Agent-ready schema

Documented columns, foreign keys, sample queries — the metadata an LLM agent needs to query without hallucinating.

Skip building the boring part