Kaggle Pharmacy & Drug Retail Datasets

Community-uploaded pharmacy data, indexed record by record and screened up front. Search Kaggle's Datasets platform for "pharmacy" or "retail drug" and the results cluster into three recognizable families: point-of-sale transaction extracts, where each row is one sale line and a shared invoice number ties the lines of a single customer visit together; medicine and OTC product tables, one row per sku with name, form and strength; and store-level demand sets, built by forecasters as benchmark material for predicting what a counter sells next week.

Every listing rides on a structured metadata record - file inventory with byte sizes, publish stamp, attention counters and a 0-to-1 usability score computed from documentation depth and format cleanliness - so the whole shelf can be triaged before any file is opened. Kaggle curates none of it; quality is the uploader's problem, which is precisely why the score matters. Datadory packages the records and their payloads for delivery as API, files, or straight into your warehouse.

One row per sale line in the transaction view - the shape your sample arrives in. Two illustrative line items drawn straight from the documented column set:

refNum      : 536365
InvoiceDate : 2019-10-15 09:32:00
Product Name: Paracetamol 500mg Tablet
Qty         : 6
Price       : 2.55

refNum      : 536365
InvoiceDate : 2019-10-15 09:32:00
Product Name: Ibuprofen 200mg Tablet
Qty         : 2
Price       : 3.40

Three things to notice. First, refNum repeats - both lines share one invoice number because one customer bought both, which is what makes the table market-basket-ready on arrival. Second, the timestamp sits at the line level, so hour-of-day traffic curves fall out of a simple group-by. Third, price is unit price, not extended - multiply against Qty yourself and you control the margin math.

Six core fields make up the transaction layer observed across typical pharmacy sales uploads, all carried in deliveries with definitions resolved per listing. Five appear below; the remainder is flagged in the footnote and available as additional fields on request.

Geography - defined per listing rather than platform-wide. Most pharmacy uploads are single-pharmacy or single-country extracts - one counter's ledger, or one national chain - while medicine catalogue tables run global. Match the listing to the market before drawing conclusions; a basket study built on one Delhi pharmacy says little about a US drugstore chain.

Temporal - months to a few years of transactions per upload, then silence: these sets hold still once published, which makes them versioned snapshots whose every record states its own age. Treat them accordingly for backtesting, and let delivery cadence - daily, weekly, or hourly - handle re-checks on your side.

Granularity - two row shapes dominate. Transaction-style listings ship line-item rows tied together by invoice number; inventory-style listings ship product-level rows with quantities held or sold. One query, two shapes - which is why the metadata layer is the stable part and the payloads are the variable part.

API, files, or your warehouse. Daily, weekly, or hourly.

• Demand forecasting - store-level sales sets with months to years of history are the classic training substrate for counter-level prediction models; usable out of the box because the timestamp already sits at line level. More on our demand forecasting page.
• Market-basket analysis - refNum groups sale lines into single visits, so co-purchase rules (what rides home with a paracetamol purchase) compute directly without session stitching.
• Price and margin studies - Price per unit across OTC and prescription lines supports cross-listing price comparisons and promotion-effect readouts.
• ML benchmarking - the 0-to-1 usability score ranks candidate training sets before anyone spends evaluation budget; see ML model training.
• Teaching pipelines - kilobyte-to-hundred-megabyte CSVs load in seconds and carry students end-to-end through ingest, model, evaluate.

Data scientists and ML engineers get forecasting and basket-analysis practice material with the triage already done - the usability score separates documented uploads from header-guessing exercises in one sort; workflows continue on our data scientists in drug retail page. Developers and data-product builders get a metadata layer that screens the whole shelf programmatically - size, publish stamp, score - before anything lands in a pipeline; see developers and builders in drug retail. Category managers and pharmacy analysts get comparable transaction shapes across markets for price, assortment and co-purchase questions - with the caveat that each listing speaks for its own counter or country. Investors and quant researchers get retail-demand signals with eyes open: snapshot behavior makes most listings practice tables rather than live signal; see investors and quants in drug retail.

Notes that pair well with this page:

• Drug retail data hub - the pooled industry view this shelf sits inside, next to regulator-grade feeds that carry provenance guarantees.
• openFDA drug enforcement recalls - the compliance ledger versus the commerce ledger: what got pulled from shelves against what sold off them.
• openFDA adverse event reports - institutional pharmacovigilance as the contrast case for community-uploaded retail behavior.
• Persona pages - what data-science, developer and analyst teams each do with a community pharmacy shelf once it arrives structured.