# F1DB ships seven artifact formats and a schema you can code against > F1DB is an open source Formula 1 database published as CSV, JSON, Smile, SQL dumps and a SQLite file, and its real value for an engineer is the versioned JSON schema that describes every object, with releases numbered by race round rather than by calendar month. **f1db/f1db** — Open Source Formula 1 Database - Repository: https://github.com/f1db/f1db - Stars: 645 · Forks: 77 - Language: Kotlin - License: CC-BY-4.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/f1db-f1db ## What the database actually covers F1DB is described as the most comprehensive free open source database with all-time Formula 1 racing data and statistics, and the coverage list is organised around reference data first and results second. The reference side covers all drivers, all constructors including chassis, all engine manufacturers including engines, all tyre manufacturers, and all circuits including layouts and SVG assets. The race side covers every season from 1950 to the present, and within each season the entrants and the standings, then for every race the free practice and warming-up results, qualifying and pre-qualifying results, sprint race results, starting grid positions, race results, fastest laps, pit stops, driver of the day results and the standings. The pit stop data and the pre-qualifying era are the entries that tell you this is a historical archive rather than a modern results feed. They also explain why the schema needs to evolve: the shape of a race result changed over sixty years of regulations, and a data model that covers 1950 and 2026 cannot be fixed once. The stated release policy is that new releases will be available as soon as possible after every race, so the data is refreshed on the season calendar rather than on a maintenance schedule. ## Seven artifact formats, and they are not equivalent Release artifacts are offered in seven formats, and choosing between them is the first real decision a consumer faces. CSV and JSON are the plain options. JSON splitted means multiple data files rather than one, which is the practical choice when you are shipping a large dataset to a browser and do not want one multi-megabyte download. Smile is described as a binary variant of the JSON format, so it keeps the same object model in a smaller payload. The SQL family is where the differences get sharp. Starting from v2024.3.0, artifacts are available as .sql dump files for MySQL, PostgreSQL and SQLite that import schema and data directly. There is also a variant with single inserts, described as much smaller .sql dump files with one insert per table, better for performance but not supported by all platforms. And there is a ready-made SQLite database file, which contains the data in relational form so it can be queried directly instead of parsing JSON. The guidance for a system that is neither MySQL, PostgreSQL nor SQLite is practical: the PostgreSQL dump is the best starting point for another system such as H2, and if no dump exists for the target, a feature request can be filed. That last point is a small but telling detail about the project's priorities. The data model is the product, and the dump format is an export. ## The JSON Schema is the contract, not the documentation The main schema file, f1db.schema.json under src/schema/current/single, contains all F1DB object definitions and is described as serving as the main documentation. For the splitted distributions, the schema files under src/schema/current/splitted must be used instead. This is the structural decision that makes F1DB usable in a program rather than in a spreadsheet. A schema gives you the object names, the property names, the required fields and the types, which means a code generator, a validator and a type definition can all be derived from one file, and the JSON and Smile artifacts are both stated to validate against it. The schema moves when the data model moves, and the version is bumped to say so. The notable changes in v2026.0.1 added a new CircuitLayout object, a layouts property on Circuit and a circuitLayoutId property on Race, which bumped the JSON Schema to version v6.4.0. Later, changes in v2026.8.2 added four properties to the Race object, namely sprintRaceLaps, sprintRaceDistance, sprintRaceScheduledLaps and sprintRaceScheduledDistance, bumping the schema to v6.5.0. A consumer therefore has to do two things: check the schema version of the release they downloaded, and read the changelog, which the documentation points to for details about schema changes and version compatibility. ## CalVer where the minor number is the race round F1DB uses a customised CalVer scheme, and the twist is that the minor number is not a month or a sequence but the round of the season: ``` YYYY.RR.MICRO(-MODIFIER) ``` The components are the full year of the season, the round number within the season, a patch number, and an optional text modifier such as dev, alpha, beta or rc. The documentation is candid that this is basically the YYYY.MINOR.MICRO pattern where MINOR stands for the round number. The examples make the release rhythm concrete. 2026.00.0 is the pre-season release before the first race round of the 2026 season, and 2026.00.1 is the first pre-season patch. 2026.01.0 is the final release after the first round, 2026.02.0 the final release after the second round, and 2026.02.1 and 2026.02.2 the first and second patches after it. Round 00 is reserved for pre-season releases. For a consumer this is more useful than it looks. A version number tells you which race the data covers, and the dev modifier tells you the release was cut mid-cycle rather than at a round boundary. The current release list follows the scheme exactly, with v2026.16.1, v2026.17.0 and a v2026.18.0-dev-1, so the seventeenth round has been finalised and the eighteenth is in development. ## Building the distributions from source The repository can build the distribution zips, and the two documented commands are a plain Gradle invocation and a faster variant that skips the tests: ```bash ./gradlew clean build ``` ```bash ./gradlew clean build -x test ``` The second is described as much faster, and it is the one to use when you only want the artifacts. The environment requirements are stated plainly: the build requires Java 25, and running the tests requires an environment with Docker. Those two requirements are the reason to know about the source build at all. A consumer who only wants the data never needs Java 25 or Docker, because the release artifacts are published. A contributor needs both, and the Docker requirement in particular suggests the test suite works against live databases rather than in-memory substitutes, which is the right choice for a project whose subject is SQL dumps. The project layout matches a modern Gradle build, with build.gradle.kts, settings.gradle.kts, a build-logic/ directory for convention plugins, gradle.properties, the wrapper scripts gradlew and gradlew.bat, and a src/ directory holding the schema, the assets and the generator code. ## Circuit SVGs are downloaded, not bundled Circuit artwork is handled separately from the data, and the reason is stated: the SVG files rarely change, so they are not bundled with the standard release artifacts and can be downloaded directly from the repository instead. The assets live under src/assets/circuits, and every circuit layout is provided in four styles: black, black-outline, white and white-outline. The pairing is deliberate for rendering, since a black fill disappears on a dark background and a white fill disappears on a light one, so a site that supports both themes needs the outline variants rather than a single file. The consequence for a consumer is that the dataset and the artwork are two fetches with different cadences. Your data artifact updates after every race, and the circuit SVGs update rarely enough that caching them indefinitely is reasonable. A build that regenerates everything on each release will download more than it needs to. The assets are also useful outside a website. A circuit layout as vector geometry is a reasonable input for a map or a distance calculation, and having four style variants of the same path means the geometry does not have to be re-derived for a dark theme. ## CC-BY-4.0, weekly releases, and where the data comes from The licence is Creative Commons Attribution 4.0, and it is the right licence for a dataset rather than for code. You can use, adapt and redistribute the data commercially, including as part of a product, provided you give appropriate credit and indicate whether changes were made. For a dataset that is the expectation anyway, since attribution is how a data project stays alive. The release cadence follows the calendar. The three most recent releases are v2026.18.0-dev-1 published on 2026-10-12, v2026.17.0 on 2026-10-11 and v2026.16.1 on 2026-10-09, which is the pattern of a patch after a round, a final release after a round, and then a development build for the next one. The repository is not archived and the last push was on 2026-10-19. What the documentation does not say is where the data comes from. There is no stated methodology, no list of source feeds and no description of how results are transcribed or verified, and the only route for correction is the issue tracker, which the README names as the place to track data issues and to create a new issue when something is wrong. That is a fair trade for a volunteer-maintained archive, and it is also the first thing to check if you intend to publish statistics that someone might act on. Corrections happen through issues, so an error stays in the dataset until a maintainer takes it, and your build should tolerate a schema and a row count changing under you. ## Conclusion F1DB fits a developer building a site, a mobile app or a stats page who wants complete Formula 1 history in a form they can query without scraping, and the SQL dumps or the SQLite file will serve a backend while the JSON plus schema will serve a frontend. It does not fit a project that needs live timing or telemetry, since the database is a season-by-season historical snapshot updated after each race. Before building on it, pick the artifact that matches your runtime, read the schema version in the changelog for the release you download, and remember the CC-BY-4.0 attribution requirement when you publish derived work. ## FAQ ### What formats can I download F1DB in? Release artifacts are available as CSV, JSON, JSON splitted across multiple data files, Smile as a binary variant of JSON, SQL dump files for MySQL, PostgreSQL and SQLite, SQL dumps with single inserts per table, and a ready-made SQLite database file. ### How is an F1DB release version number built? It uses a customised CalVer scheme of YYYY.RR.MICRO with an optional modifier such as dev, alpha, beta or rc. The RR component is the round number within the season, and 00 is reserved for pre-season releases. ### How do I know if an F1DB release changes the data model? The JSON Schema version is bumped when the object definitions change, for example to v6.4.0 when the CircuitLayout object and the layouts and circuitLayoutId properties were added, and to v6.5.0 when the sprintRace properties were added to Race. The changelog holds the details about schema changes and version compatibility. ### Can I use F1DB data in a commercial project? F1DB is released under the Creative Commons Attribution 4.0 licence, which permits use, adaptation and redistribution including commercial use, provided you give appropriate credit and indicate whether changes were made. ### What do I need to build F1DB from source? The build requires Java 25, and running the tests requires an environment with Docker. The distribution zips are built with ./gradlew clean build, or faster with ./gradlew clean build -x test. ## Sources - [f1db/f1db on GitHub](https://github.com/f1db/f1db) - [Issues](https://github.com/f1db/f1db/issues) - [License: CC-BY-4.0](https://github.com/f1db/f1db/blob/main/LICENSE) - [README](https://github.com/f1db/f1db/blob/main/README.md) - [Releases](https://github.com/f1db/f1db/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/f1db-f1db