Synthetic dataset, CC0 1.0
Retail order events
Order events from a small synthetic shop, with duplicates, invalid rows, stale versions and conflicting IDs built in on purpose.
26 rows in 7 files, 4,672 bytes
Download and licence
Source: synthetic, written by hand by DataEngr. Licence: CC0 1.0, no attribution required.
Download includes the data and NOTICE.txt with its source, changes, licence and SHA-256. If you share it, follow that licence.
About this dataset
Each row is one delivery of an order event: the order's full state at one source version, in Australian cents and UTC. The seven files are the batches the retail-orders pipeline is tested on, from a clean first batch to replays, conflicts and ties.
The rows are few enough to check by hand. The amount is order value in this example, not recognised accounting revenue, and the shop, its orders and its channels are invented.
Schema
order_events
Grain: One row per delivery of an order event. The same event can arrive more than once, so event_id is not unique within a file.
| column_name | column_type | null | meaning |
|---|---|---|---|
| event_id | VARCHAR | NO | The source event. A repeat with the same payload is a duplicate; with a different payload, a conflict. |
| order_id | VARCHAR | NO | The order the event describes. |
| source_version | BIGINT | NO | The order's version at the source. A higher version replaces a lower one. |
| order_date | DATE | NO | The day the order counts towards in the daily report. |
| channel | VARCHAR | NO | One of web, store. Where the order was placed. |
| amount_cents | BIGINT | NO | Order value in Australian cents. |
| source_updated_at | VARCHAR | NO | When the source last changed the order, as ISO 8601 text in UTC. It breaks a tie between equal versions. |
event_id
VARCHAR, never null
The source event. A repeat with the same payload is a duplicate; with a different payload, a conflict.
order_id
VARCHAR, never null
The order the event describes.
source_version
BIGINT, never null
The order's version at the source. A higher version replaces a lower one.
order_date
DATE, never null
The day the order counts towards in the daily report.
channel
VARCHAR, never null
One of web, store. Where the order was placed.
amount_cents
BIGINT, never null
Order value in Australian cents.
source_updated_at
VARCHAR, never null
When the source last changed the order, as ISO 8601 text in UTC. It breaks a tie between equal versions.
Sample rows
order_events
| event_idVARCHAR | order_idVARCHAR | source_versionBIGINT | order_dateDATE | channelVARCHAR | amount_centsBIGINT | source_updated_atVARCHAR |
|---|---|---|---|---|---|---|
| e1 | o100 | 1 | 2026-01-01 | web | 10000 | 2026-01-01T10:00:00Z |
| e1 | o100 | 1 | 2026-01-01 | web | 10000 | 2026-01-01T10:00:00Z |
| e2 | o101 | 1 | 2026-01-01 | store | 2500 | 2026-01-01T10:00:00Z |
| e3 | o102 | 2 | 2026-01-02 | web | 7000 | 2026-01-02T10:00:00Z |
| bad1 | o103 | 1 | 2026-01-02 | web | -100 | 2026-01-03T10:00:00Z |
| bad2 | o104 | 1 | 2026-01-02 | unknown (breaks the schema on purpose) | 500 | 2026-01-03T10:00:00Z |
| bad3 | NULL (breaks the schema on purpose) | 1 | 2026-01-02 | web | 500 | 2026-01-03T10:00:00Z |
| e5 | o105 | 1 | 2026-01-02 | store | 0 | 2026-01-02T10:00:00Z |
What is wrong with it on purpose
A duplicate delivery
Event e1 arrives twice in initial.json with the same payload; it must count once.
A negative amount
Row bad1 in initial.json has amount_cents -100.
An unknown channel
Row bad2 in initial.json has the channel unknown, which is neither web nor store.
A missing order ID
Row bad3 in initial.json has a null order_id.
An invalid date
Row bad4 has the order_date invalid, in followup.json and again in conflict-batch.json.
Stale versions
In followup.json, e6 moves order o100 to version 2, while e8 and e9 carry version 1 for orders already at version 2; neither may replace the newer state.
Conflicting event IDs
conflict-batch.json sends e6 twice with different amounts, and conflict-history.json reuses e1 with a new amount; the pipeline rejects the batch before it changes anything.
Ties
tie-timestamp.json and tie-event-id.json repeat order o102 at its current version, so the timestamp, then the greater event ID, decides which event wins.
Files and provenance
- Source
- Synthetic, written by hand by DataEngr
- How it was made
- DataEngr wrote each row by hand to exercise one pipeline rule; no generator or seed was used.
- Rows last changed
- 18 September 2026
- Licence review
- DataEngr, 20 October 2026: DataEngr wrote every row itself; no third-party source, person or record is in the data, so CC0 1.0 applies, the licence the site gives its own synthetic data.
- Package
- retail-orders.zip, 7,158 bytes, SHA-256 3eeb8ffa19b30fe5adda1f9f5b87c420bcae0652f07dd77d467fff421ce44e5b
| file | what it holds | rows | bytes | sha256 |
|---|---|---|---|---|
| initial.json | The first batch: four good orders, one duplicate delivery and three invalid rows. | 8 | 1,436 | c95faeb99da38977b9a6797ec002d7e6bfd44b9a09d346a1f1ea94c21f12048d |
| followup.json | The next batch: a correction, a new order, replays, two stale versions and an invalid date. | 7 | 1,254 | 464d7430a9cf05b71e02ed1a83d178760ad05cb1a97d5a5b1e203f265562b7c7 |
| empty.json | An empty batch, which must change nothing. | 0 | 3 | 37517e5f3dc66819f61f5a7bb8ace1921282415f10551d2defa5c3eb0985b570 |
| conflict-batch.json | The next batch with one event ID sent twice with different amounts. | 7 | 1,254 | 0b71d62c2feb29f2c2eed4c4e1c840a93df0842c60c7b616b6a7d58fb0074be3 |
| conflict-history.json | An event ID the first batch already used, now with a different amount. | 1 | 182 | d13fa3903ecc0bb1dd59a9f10ef7aaf0d4e421971c6b88b2660e73e22a43be8d |
| tie-timestamp.json | A second event at an order's current version, with a later timestamp. | 1 | 182 | a23bd8bc1d08c58a0038131c985ff37addd6200b880f60e7f51b56bac0551c4c |
| tie-event-id.json | Two events at the same version and timestamp, settled by the greater event ID. | 2 | 361 | ecc6369d878380b7b3afdc0c527b540b2fdf2437e6fa3b9a378529e11efa06b1 |
initial.json
The first batch: four good orders, one duplicate delivery and three invalid rows.
8 rows, 1,436 bytes
sha256 c95faeb99da38977b9a6797ec002d7e6bfd44b9a09d346a1f1ea94c21f12048d
followup.json
The next batch: a correction, a new order, replays, two stale versions and an invalid date.
7 rows, 1,254 bytes
sha256 464d7430a9cf05b71e02ed1a83d178760ad05cb1a97d5a5b1e203f265562b7c7
empty.json
An empty batch, which must change nothing.
0 rows, 3 bytes
sha256 37517e5f3dc66819f61f5a7bb8ace1921282415f10551d2defa5c3eb0985b570
conflict-batch.json
The next batch with one event ID sent twice with different amounts.
7 rows, 1,254 bytes
sha256 0b71d62c2feb29f2c2eed4c4e1c840a93df0842c60c7b616b6a7d58fb0074be3
conflict-history.json
An event ID the first batch already used, now with a different amount.
1 row, 182 bytes
sha256 d13fa3903ecc0bb1dd59a9f10ef7aaf0d4e421971c6b88b2660e73e22a43be8d
tie-timestamp.json
A second event at an order's current version, with a later timestamp.
1 row, 182 bytes
sha256 a23bd8bc1d08c58a0038131c985ff37addd6200b880f60e7f51b56bac0551c4c
tie-event-id.json
Two events at the same version and timestamp, settled by the greater event ID.
2 rows, 361 bytes
sha256 ecc6369d878380b7b3afdc0c527b540b2fdf2437e6fa3b9a378529e11efa06b1
Run a pipeline on this
- Pipeline studioRun each batch through the pipeline with DuckDB in your browser, stage by stage.
- A daily orders pipeline you can run in DuckDBThe flagship field note walks through the same batches.
- An idempotent pipeline counts each order onceReplays these batches to show each order counts once.
- Late-arriving data can revise an earlier dayFollows the correction that moves order o100 from 1 January to 2 January.