Sectional times data is one of the least common things a horse racing data provider can offer. Many sources give you a finishing time and a distance. Fewer tell you how the race was run.
This article explains what HRDB holds, how it sits alongside the rest of the database, and how model builders and analytics teams can work with it. It makes no predictions. It is about the data and what you can sensibly do with it.
Why sectional times matter for model builders
A finishing time is a single number. It hides the shape of the race.
Two horses can cross the line in the same time after very different journeys. One may have gone quickly early and faded. The other may have been held up and finished strongly. A final time cannot separate them. Sectional times can.
Sectionals let you describe a run in parts:
- How quickly the early stages were covered.
- How the pace changed through the middle of the race.
- How much was left for the closing stages.
If you train your own models, those parts are candidate features. Whether they help is for you to test. Our job is to make sure the inputs are clean.
What sectional coverage HRDB holds
Here are the verified dates:
- Hong Kong sectional times: from 2008.
- UK sectional times: from 2017.
These sit inside a wider database. HRDB holds 2.2M result records across 226K races and 173K horses, at 85+ racecourses. Hong Kong history runs from 1979. UK and Ireland history runs from 2011.
The point to notice is that sectionals start later than results. If you are building a feature set, plan for that. A horse with a long career will have results going back further than its sectional history. We say this plainly because it affects how you design a backtest, and we would rather you knew before you began.
Where a typical card fits
The data is updated daily, after racing. It is not a live feed, and there are no webhooks. That shapes how you use it.
On one recent day, the UK and Ireland card ran to 30 races and 322 runners across four courses: Curragh, Hexham, Newcastle and Yarmouth. The code types were Flat Turf, Hurdle, Chase and Flat AW. The feature race was the Staffordstown Stud Stakes at the Curragh at 15:00, over 1m on Yielding going, with 11 runners and a prize of €42,000.
We mention the example card for one reason. It shows the daily rhythm. Racecards are available for the day, and results follow once racing is over and the nightly update has passed its checks. A pipeline that pulls once a day, after racing, will match that rhythm.
Note that we are not claiming sectional coverage for any particular meeting on a given card. Sectionals start in 2008 for Hong Kong and 2017 for the UK. Check the records you pull for the fields you need, rather than assuming every race carries them.
Turning sectionals into model features
What you build is your decision. These are common approaches that data teams take with timing data, described without any claim about their performance.
Compare like with like
A raw sectional time means little in isolation. Distance, course, surface and going all change what a given time represents. A fast split on one track may be ordinary on another.
Most teams therefore group runs by course, distance and going before comparing them. That grouping relies on consistent course and race fields. It also relies on enough history in each group, which is another reason to check how many records you actually hold per group.
Separate pace from finish
If you have timings for different parts of a race, you can look at the relationship between them rather than the totals. For example, you can describe how a horse’s early effort compares with its closing effort, and how that compares with the rest of the field in the same race.
This is a feature design question. The data gives you the parts. You decide how to combine them.
Build rolling profiles per horse
Because HRDB uses stable identifiers, you can follow one horse across many runs without guessing which horse is which. A rolling profile of a horse’s previous sectional performances is only possible if every run is attached to the right horse.
The same applies to jockeys and trainers. Trainer dashboards that track how stables run their horses over time need the trainer ID to be dependable.
Backtest with care
When you backtest a model that uses sectionals, only use information that would have been available at the time. A result from a race that finished after your prediction point must never leak into your features.
Because the data is updated daily after racing, the natural unit is the racing day. Build your training windows around days and keep a clean boundary between what was known and what was not.
Why data integrity matters more for sectionals
Timing data is only useful if every row points to the right race and the right horse. A single wrong join can turn a good feature into noise, and you may not notice for weeks.
Every nightly update passes automated integrity gates before it is published:
- No horse is assigned to two races on the same day.
- No duplicate runner rows.
- No missing horse, jockey or trainer IDs.
- Different horses that share a name are kept separate.
Each of these protects a sectional-based workflow in a specific way.
A horse in two races on the same day would put its timings in two places. A duplicate runner row would double-count a run in your rolling averages. A missing ID would leave a gap in a horse’s profile. And two horses sharing a name, if merged, would blend two different careers into one set of sectionals.
These are the failures that quietly damage a feature set. Catching them before publication is cheaper than finding them in your model’s behaviour later.
Handling the coverage boundary in your pipeline
Because sectional history is shorter than results history, your pipeline should treat missing sectionals as a normal case, not an error.
A few practical habits help:
- Keep results-only features and sectional features in separate groups, so you can train with and without the latter.
- Record which runs have sectionals, and report that share in your own validation. We do not publish a coverage percentage, so measure it on the data you pull.
- Keep Hong Kong and UK data apart in your own logic. They live in separate, isolated schemas in HRDB, and their sectional histories start in different years.
- Avoid mixing runs from different eras without checking that the timing method is comparable. If you know of differences, document them for your team.
How to access sectional data
You can take HRDB data as historical datasets in CSV, SQL or JSON, or through the REST API. Bespoke exports and enterprise support are also available.
The public API documentation lists 26 UK and 30 Hong Kong data endpoints. They cover races, racecards, records (results), horses, jockeys, trainers and courses, plus Hong Kong veterinary records.
Authentication is simple. You exchange your API key for a token valid for 24 hours with POST /auth/token. You can check your quota used and remaining with GET /user/usage, and that call does not consume any of your allowance.
Access is provisioned automatically after purchase. Each plan has usage quotas, and add-on packs are available if you need more calls.
A sensible split for many teams is:
- Use a historical dataset to build and train. A one-off load suits a large backfill.
- Use the API for the daily update, pulling new results once racing is complete.
Which of the two suits you depends on your volume. The plans page explains the options, and we do not quote prices in articles.
What sectionals will not do
Sectional times describe what happened. They do not tell you what will happen next.
We do not offer tips, predictions or any claim about outcomes. Your model is yours. What we aim to provide is a source you can trust: documented coverage, stable identifiers, daily updates and integrity checks that run before publication.
Summary
- Sectional times: Hong Kong from 2008, UK from 2017.
- They sit beside 2.2M result records, 226K races and 173K horses.
- Data is updated daily after racing. It is not live.
- Integrity gates protect the joins that sectional features depend on.
- Plan for the coverage boundary and test your features on the records you actually hold.
If you are evaluating sectional data for a model or a production pipeline, start by pulling a sample for the courses and years you care about. Check the fields. Check the IDs. Then decide.
Next step: Explore the datasets
Comments are closed