PLDB: a programming language database stored as plain text files

The knowledge graph is one file per concept

PLDB is described in the README in a way that explains most of its design. It is written in Scroll, and the sentence that matters is that the database is just text files.

The structure follows from that. The repository contains a `concepts` folder, and the documentation states that this is the most important folder because it holds the ScrollSet, a file for each concept. A programming language, a creator, a feature, these are all concepts, and each one is a file you can open, diff and edit in a text editor. The schema for those files lives in `code/measures.parsers`, which contains the Parsers for the ScrollSet.

That layout has consequences for anyone planning to work with the data. A change to a language's attributes is a pull request against a text file, reviewable like any other change, and mergeable without a database migration. The cost is that the project depends on the Scroll toolchain to turn those files into the site and into the exports.

The scale, according to the README, is over 135,000 facts about over 5,000 programming languages. The repository topics name the domain as data, knowledge graph and programming languages.

The exports are the product most people want

The site at pldb.io is one face of the project. The other face is the data, and the README is direct about how to get it: the entire ScrollSet is ready to analyze in popular formats, with full documentation at https://pldb.io/csv.html.

https://pldb.io/pldb.csv
https://pldb.io/pldb.tsv
https://pldb.io/pldb.json

Three formats, flat files, no API key and no query language to learn. That is the part of PLDB that fits into an existing pipeline: you can load the CSV into a spreadsheet, a database or a notebook and ask your own questions.

The npm package is built around the same idea. Its `main` field points at `./pldb.json` and the published `files` list contains only `pldb.json`, so installing the package gives you the dataset rather than a client library. The `bin` entry maps the command name `pldb` to `./cli.js`, and the repository also contains a `Computer.js` file and a `code/` directory of supporting scripts.

The site itself is generated from the same content. Top level files such as `index.scroll`, `concepts.scroll`, `search.scroll`, `add.scroll`, `download.scroll` and `sitemap.scroll` are Scroll templates, with directories for `lists/`, `features/`, `books/`, `blog/`, `pages/` and `creators/`.

Building the site locally needs cloc, npm and the Scroll CLI

The README gives the local build sequence, and it is short.

git clone https://github.com/breck7/pldb
cd pldb
npm i -g cloc
npm install .
npm run test
npm run build
npm run format

The `cloc` step is marked as required only during the first install. `npm install .` is needed on a fresh checkout, when upgrading an old checkout, and periodically when there are new releases of the toolchain, which is an unusual admission to put in a readme but a useful one. The formatting step is described as the thing to run after making changes and before committing.

What the npm scripts actually do is visible in `package.json`. The build first regenerates the parsers file through the project's own CLI, then builds the concepts page, then a feature pages template, then pipes the scroll list output into another build.

  "scripts": {
    "build": "./cli.js buildParsersFile && scroll build concepts.scroll && scroll build code/generateFeaturePages.scroll && scroll list | scroll build",
    "test": "scroll list | scroll test",
    "format": "scroll list | scroll format",
    "open": "open index.html",

So the test suite is also driven by Scroll, and the same `scroll list` output feeds both the test and the format run.

The toolchain is pinned to GitHub commits, not npm versions

This is the sharpest constraint in the project and it appears in the dependency list. Both `scroll` and `scrollsdk` are dev dependencies pointing at GitHub rather than the registry.

    "scroll": "github:breck7/scroll#v180.0.1",
    "scrollsdk": "github:breck7/scrollsdk#v108.0.0",

There is a script for moving between those pins.

    "up": "npm install --save-dev scroll@github:breck7/scroll#v180.0.1 scrollsdk@github:breck7/scrollsdk#v108.0.0",

The tags look like ordinary versions, so the pinning is not to a moving branch, but the packages still come from a GitHub repository rather than the npm registry. Installing them therefore needs git and network access to GitHub, and a corporate npm mirror that only mirrors the registry will not be enough.

The rest of the dependency set is ordinary npm: `dayjs`, `lodash`, `monaco-editor`, `numeral` and `semver` for development, with `ky` and `prettier` as runtime dependencies. The `monaco-editor` entry is worth noting, since it implies the site includes an in-browser code editor view, and `prettier` with a configuration in `package.json` that sets two space indentation, no semicolons and a 120 column print width explains the `npm run format` step.

Provenance is published, not assumed

A database of claims about thousands of languages is only useful if you know where the claims came from. PLDB publishes that. The README points to an acknowledgements page at https://pldb.io/pages/acknowledgements.html for all sources, and the repository contains a `citation.scroll` file, which is how a source is cited on the site itself.

The project also reports on itself. The `cloc` script counts lines of code in the repository using git as the version control source and a custom language definition file, and the results are published at https://pldb.io/pages/about.html. A `books/` directory and a `blog/` directory sit at the top level next to the data, so the site carries long form writing about languages rather than only records.

The README opens with a note on who built it, describing the project as created before AI by a team of humans around the world who came together because of shared interests in questions about what programming is, what programming languages are, how many there are, who created them, what makes them similar and different, and how to make your own. That framing matters for a dataset project: it tells you the coverage is the result of deliberate curation by volunteers rather than a scrape.

No tagged releases, an open licence, and a version number that moves

The repository is not archived and the last push was on 2026-10-22, so work continues at a steady rate. The `package.json` version is 12.0.0, and there are no GitHub releases at all, so the version field is the only version marker, and it moves with the repository rather than with a tag.

On licensing, there is a small inconsistency worth resolving before you build on the data. The README states that PLDB is public domain, and the `files` list publishes only `pldb.json`, so the intent is clear. GitHub itself reports the repository licence as unclassified, which usually means there is no licence file in a recognised form in the root. Public domain means you can copy the data, modify it and redistribute it without attribution requirements, which is a far more permissive position than the licences most open source projects use. This is a reading of the stated terms rather than legal advice, and if your organisation needs certainty, ask the project owner to state the position in a file you can point at.

The realistic upgrade cost is therefore in the toolchain, not the data. The data changes shape as concepts are added, and the exports are regenerated from the same source, so any pipeline you build over the CSV or JSON has to expect column and row changes between snapshots.

Editorial conclusion

Adopt PLDB when you need a structured, downloadable reference on programming languages that you can vendor into your own tooling without a licence negotiation, since the README states the data is public domain. Skip it when you need a maintained API with a stability guarantee, because there are no tagged releases and the site build depends on a toolchain pinned to GitHub commits. Verify first that the CSV or JSON export covers the fields you need before you build a pipeline on top of it.

Frequently asked questions

Official sources

1. breck7/pldb on GitHub
2. Issues
3. Project website
4. README