frankmcsherry/blog: a decade of notes on Datalog, columnar layouts and Materialize
Some notes on things I find interesting and important.
At a glance
- What is it?
- Roughly fifty research write-ups in Markdown, reverse chronological, tagged by topic, where Datalog work from 2025 sits next to a decade retrospective and a look at what AI coding tools did to a compiler.
- Who is it for?
- This blog is at its best as an argument in progress rather than a finished position, and the tags are the honest signal of that. Follow the Datalog cluster from Worst-Case Optimal Datalog through the Columnar and Datatoad posts if you want the technical line, or start with the decade review if you want the map.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 38 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 11, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A README that is the whole publication
The repository has three entries: `README.md`, `assets/`, and `posts/`. There is no site generator, no build script and no theme. What you read on the web is a rendering of a Markdown file whose URL is its path under `posts/`, which is why every link in the README points at a blob rather than a route.
That constraint shapes the archive in a good way. Each post is one file, named for its date, with a suffix when two posts share a day: `2026-03-14.md` and `2026-03-14-claude.md`. Nothing about the format is proprietary, so the entire back catalogue is greppable, diffable and readable in an editor, and it would survive the author losing interest in whatever publishes it.
The README opens with a short biography: a researcher and computer scientist who used to work in San Francisco, travelled a bit, and is now in New York starting Materialize.io. Then it makes a promise about the archive that is rarer than it should be. Posts are in reverse chronological order, newest first, and the content of the oldest posts may no longer be correct, mostly for the ones about software the author worked on and its state at some past time. They are retained for posterity, and the README adds, and some humility. That is a better editorial policy than silently deleting posts that aged badly.
Topic tags as the actual index
The table of contents is three columns: topics, date, title. That middle column of topic labels is what makes fifty-odd posts navigable, and reading them in order tells you how the author's attention moved.
Materialize dominates the middle years. There are posts on recursive SQL, operational data with SQL, freshness and operational autonomy, consistency and operational confidence, a guided tour of the product principles, responsiveness and operational agility, capturing change data capture data, and transaction processing in the data plane. Several of these are clearly argument pieces rather than release notes, which is the useful part for a reader outside the company.
Then the topics widen. Differential appears on generalization of linear operators and on Timely and Differential on WASM. Timely gets its own post on asynchronous all reduce. Bluesky gets one post on exploring social trends. E-Graphs gets a post on understanding e-graphs, which is the only one post in the archive on that topic and reads as a background explainer for something adjacent rather than a research direction.
Columnar is the tag that spans the widest period, from a fascinating diversion into compression in 2024 through more serial layout in Rust and a less unsafe serial layout in Rust in the same month, up to columnar worst-case optimal joins in late 2025. Two posts on the same day in August 2024 is itself a signal about how fast that work was moving.
The Datalog cluster of 2025 and 2026
The most recent stretch of the archive is the densest and the most interesting to follow chronologically. It starts with comparing interpreted Datalogs in August 2025, then checking in on Datatoad a month later. A Datalog in Rust post in June 2025 explains the implementation direction, and Binary joins can be worst-case optimal from May 2025 sets up the theory that the later posts build on.
From October 2025 the cluster turns into a running research log with dates close enough together to reconstruct a thought process. Columnar Datatoad on 2025-10-24, an interpreted Datalog check-in on 2025-10-09, accumulating mid-Join on 2025-11-17, columnar worst-case optimal joins on 2025-11-21, worst-case optimal Datalog on 2025-12-03, evaluating Datatoad on 2025-12-14, and (Worst-Case Optimal) Relational Programming on 2025-12-23.
Then 2026 opens with the most abstract title in the archive, The Demand Transform on 2026-01-01, followed by A Toy Vectorized Interpreter on 2026-03-01 and Speeding up timely dataflow by 100x on 2026-03-19.
Read as a sequence, this is a small research program: prove worst-case optimal joins are achievable for binary relations, move that into a columnar layout, evaluate the resulting system against the alternatives, generalize it to relational programming, and then work on the vectorization and the dataflow runtime underneath. Datatoad appears to be the system name, and it is evaluated twice, once in August and once in December 2025.
Two posts where an AI coding tool became the subject
The one place where this blog touches the current moment is a pair of posts published the same day in March 2026. One is titled Improving `columnar` with Claude. The other is Making Field Access Constant-Time in Columnar, tagged with both Columnar and Claude, which suggests the second is the concrete result and the first is the account of getting there.
That pairing is worth noting for a specific reason. Everything else in the archive is the author building systems and writing up the results. These two invert the usual order: the tool is the subject, and the project being improved is a real compiler from the same archive. A constant-time field access change is a compiler-level optimization, which is not the kind of thing an assistant invents out of nothing, so the posts are probably as much about how to direct the work as about the diff.
The naming of the file settles the ambiguity. `2026-03-14.md` is the general account and `2026-03-14-claude.md` is the Claude-specific one, which is the same convention used for the older same-day pairs. If you are interested in whether AI tooling helped or hurt a compiler, those two files are where the answer lives.
Posts built for teaching and for fun
Two clusters exist outside the research line and are easy to miss. Materialize has several seasonal posts: Minesweeping in Materialize from July 2022, Materialize and Advent of Code (50/50) in January 2024, and Advent of Code 2022 in SQL from January 2023. Working out a puzzle in a streaming database is a legitimate way to find out where a query language is awkward, and the archive keeps the results.
Then there is the community-facing series: A Guided Tour of Materialize's Product Principles, Freshness and Operational Autonomy, Consistency and Operational Confidence, and Responsiveness and Operational Agility, all within about three weeks in September and October 2023. Read in that order they build an argument about what a database product should promise, and that argument is more portable to any streaming system than the company-specific parts are.
A decade in review (2015 to 2024), dated 2024-12-23, is the retrospective to read first if you want orientation, and it sits in the archive as a single post rather than as a section, which is a little surprising given the span it covers.
What you cannot tell from the repository
The README is the entire documentation, so several things are simply absent. There are no releases, so there is no changelog and no version history for the writing itself. There is no license field in the repository metadata, which is an odd gap for fifty-odd research write-ups that other people may want to quote, and it means the terms for reuse are not stated anywhere visible.
There is also no tooling. No site config, no build, no link checker, no lint. Each post URL is a blob path, so the archive has none of the conveniences of a publication with a feed or per-post metadata, and the topic tags live only in the README table rather than in any structured file you could query.
The repository language is reported as JavaScript, which is almost certainly an artefact of the web publishing layer rather than of anything in `posts/`. The repository is not archived, last pushed 2026-09-03, with 2122 stars, 176 forks and 8 open issues. For an archive that is essentially one person's writing, a fork count that size usually means people are copying posts into their own sites rather than opening issues.
Editorial conclusion
This blog is at its best as an argument in progress rather than a finished position, and the tags are the honest signal of that. Follow the Datalog cluster from Worst-Case Optimal Datalog through the Columnar and Datatoad posts if you want the technical line, or start with the decade review if you want the map. Two things a reader will not find here are benchmarks you can rerun and any sign of an editorial process beyond one person's judgment about what is worth publishing. The repository is a `posts/` directory and a README, with no releases, no build tooling and no site generator to inspect, and the author says outright that older posts may no longer be correct and are kept for posterity and some humility. Read the newest Datalog posts first, treat the 2020 and 2021 Materialize posts as historical, and check dates before quoting anything.
Frequently asked questions
What topics does the frankmcsherry blog cover?
The README indexes posts by topic label, and the recurring ones are Datalog, Materialize, Columnar, Timely and Differential, with single posts on E-Graphs and Bluesky. The Datalog and Columnar labels dominate the 2025 and 2026 entries, covering worst-case optimal joins, a system called Datatoad, and Rust implementations.
Are the older posts on frankmcsherry/blog still accurate?
The README says so yourself, in the opening paragraph. Posts are newest first, and the content of the oldest ones may no longer be correct, mostly those about software the author worked on and its state at some point in the past. They have been kept for posterity and, as the README puts it, some humility. Check the date before quoting anything.
How is the frankmcsherry blog repository structured and built?
There is no build at all. The repository holds a README, an `assets/` directory and a `posts/` directory, with one Markdown file per post named for its date. Same-day posts get a suffix, such as `2026-03-14-claude.md`. The README is a table of topics, dates and titles that links directly to blob paths, so there is no site generator or theme to inspect.
Where should I start reading frankmcsherry/blog?
For the technical line, work forward through the Datalog cluster from Binary joins can be worst-case optimal in May 2025, through the Columnar Datatoad and worst-case optimal Datalog posts, to The Demand Transform in January 2026. For orientation across the whole archive, A decade in review (2015 to 2024) from December 2024 is the retrospective post.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/frankmcsherry-blog)