# blacksmithgu/datacore: rewriting the Obsidian index and the query UI together

> Datacore is a work in progress successor to Dataview for Obsidian.md, reworking both the index over your Markdown files and the way you write queries, with React views, editable tables and section level queries. Its own performance target is stated as a range in the README, and there is no benchmark behind it, and the newest release is a 0.1.x line.

**blacksmithgu/datacore** — Work-in-progress successor to Dataview with a focus on UX and speed.

- Repository: https://github.com/blacksmithgu/datacore
- Stars: 2,239 · Forks: 68
- Language: TypeScript
- License: MIT
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/blacksmithgu-datacore

## An index over Markdown files, and a query layer thrown away with it

Datacore is an Obsidian.md plugin that indexes the Markdown files in a vault and renders live updating views over that index, which is the same job Dataview does. The project states the split plainly: it keeps the index concept and the metadata, and it changes the index implementation for speed and replaces the query authoring surface entirely with an interface it describes as WYSIWYG. That second half is what makes it a different tool rather than a faster one. In Dataview you write a query and it produces a table; in Datacore the table is a responsive view you can edit, with a table editor compared to what Notion and Airtable offer, and values inside a row can be changed in place. The feature list also claims that task views render metadata such as due dates with more nuance and offer more ways to manipulate tasks, and that Markdown, image and video embeds now resolve inside every view, with a new view type that is just a list of embeds. Section and block level queries are the other structural change. The index covers all files rather than only notes, attachments, PDFs and images included, and a query can target a section or a block. For a vault where the interesting content lives in PDFs and in images, that is a different reach than a note index.

## Two to ten times, claimed without a benchmark

The headline number in the README is a range: two to ten times better query and rendering performance than Dataview. It is worth being precise about what that is. It is the project's own stated goal, written in the repository description and repeated in the README, and the repository contains no benchmark, no dataset and no measurement script that would let you reproduce it or argue with it. The mechanism claimed alongside it is more informative than the number. The React based views are supposed to support internal state and flickerless updates when the index changes, which is a rendering claim rather than a query one, and the new query API is described as much faster than the Dataview idiom of pages filtered with a where clause, which is a query claim and the more interesting of the two because it is where a vault with tens of thousands of notes actually hurts. Runtime dependencies give a hint about the approach: a queue data structure is a direct dependency, alongside the icon and component libraries. A queue in the runtime is what an index that processes changes incrementally rather than rebuilding looks like, and incremental processing is a reasonable way to try to get faster without changing the query language's expressiveness. None of this is verification, and the honest reading is that the performance case is a design intention documented in prose.

## The new JavaScript API, and why dv.pages().where(...) is the wrong example

If you write Dataview today you almost certainly reach for its JavaScript API, and the README names the exact call the new API is meant to replace: dv.pages().where(...). That single phrase tells you what kind of improvement is claimed. The Dataview idiom is a chain of array-like operations over a materialised result set, which is comfortable to write and allocates as it goes; a different query API implies the index is queried rather than built first and filtered afterwards, which is the difference between a filter cost that scales with your vault and one that scales with the answer. For view authors the other change matters just as much. The views are React components with their own internal state, and they are told to update without flicker when the index changes, so a view is a component that subscribes rather than a block that re-renders. That is a real cost for anyone porting a complex DataviewJS block, because internal state has to be reimplemented in React terms, and there is no compatibility layer described. The repository does contain a dedicated section on differences from Dataview, and it is short, which tells you how much of the migration is left to the reader. The full query documentation is not in the repository at all; it is published as a separate documentation site, so the reference you would compare against Dataview's lives somewhere else entirely.

## Building it: esbuild output, a vault install script, and four scripts to know

The build path is short enough to describe in full, and it is a source install rather than a store install, so it is the only route the README documents. First time setup is an install and a build:

```bash
yarn install
yarn run build
```

That produces the plugin in the build directory, assembled by esbuild, and a small script copies the compiled plugin into a vault you name:

```bash
./scripts/install-built /path/to/your/vault/root
```

The two steps combine into one line if you prefer, and it is the form worth remembering:

```bash
yarn run build && ./scripts/install-built /path/to/your/vault/root
```

What you should see afterwards is a plugin directory inside the vault where Obsidian can load it, which also means you now have a build of master rather than a tagged release, with all the consequences that carries for something self described as a work in progress. Two more scripts matter day to day. Formatting runs through prettier over the source, and tests run through jest:

```bash
yarn run format
yarn run test
```

A detail in the manifest is worth noticing if you are deciding whether to trust the toolchain. The test script is not a direct jest call, it delegates to another script, and the test dependencies are on jest 27 with matching type packages and ts-jest, while the compiler is TypeScript 5.4 and the Obsidian typings are on the 1.6 line. A test stack several major versions behind the compiler is a normal thing to find in a project that has been running for a while, and it is the kind of thing that decides whether a bug fix you contribute can be tested at all.

## A published library, an extracted API report, and two plugin manifests

The manifest describes this as more than a plugin, and the file list supports the claim. The package name is scoped and published, its description calls it a reactive data engine for Obsidian.md, and it declares a main entry point and a types entry point inside a built library directory, with the files array publishing only that directory. So there are two audiences. One loads the plugin in a vault. The other installs the package and writes against its type definitions, which is what you do if you are building a view as an external project. The build script is where that split becomes visible, because it compiles the sources, then compiles them a second time under a separate library configuration, then runs api-extractor in local mode, and only then bundles with esbuild. There is a dedicated api-extractor configuration and a separate TypeScript configuration for that step in the top-level files, and the output is a single rolled up declaration file rather than a tree of them. What the local mode does is rewrite the checked in report, so any change to the public surface shows up as a diff in a file you can read. That is a better answer to the question of what is stable than a version number, and it is the first thing to look at before writing code against the library. On the plugin side there are two manifests in the tree, one for the plugin and one for a beta, alongside a versions file, which is a channel structure the README never describes. So expect to find out what the beta manifest is for by opening it.

## MIT, a 0.1.x line, and a contribution process that asks first

The licence is MIT, stated both in the manifest and in a licence file at the top level, so there is no ambiguity about what you may do with the code or the library. The version line is where the caution belongs. The newest release is 0.1.29, published on 2026-03-23, and the manifest on master still declares 0.1.28, with the two releases before that, 0.1.27 and 0.1.28, published within an hour of each other on 2025-09-15. The last push was on 2026-06-22. A pre one version line with a gap of several months between the 2025 releases and the one in 2026 is a project that ships when it is ready rather than on a schedule, which is defensible for something that replaces a plugin many people depend on daily, and it also means the version number tells you very little about maturity. The README and the project description both call it a work in progress, and the roadmap lives in its own file rather than in the README, so the gap between what is built and what is planned is documented somewhere, just not where you first look. The contribution process adds one more signal. The README asks that anything beyond a bug fix be raised by email or on Discord first, to check that the change is reasonable and feasible, which is a considerate way to avoid wasted work and also a clear statement that the roadmap is not a suggestion box. The dependency set deserves the same reading: a scoped package, an MIT grant, and a public API report means you can vendor the library, but you should expect to track master, not a version.

## Conclusion

Datacore is worth trying in a vault you can afford to experiment in, and not in the one holding a decade of hand written Dataview queries, because the query authoring surface is replaced outright rather than extended, so migration is the work, not installation. The gains people are asked to expect are the project's own claim of two to ten times better query and rendering performance, stated in the README with no benchmark attached, and nothing in the repository lets you check that number yourself. The sharper boundary is the version line: releases sit at 0.1.x, the manifest on master still reads 0.1.28 while 0.1.29 is the newest tag, and the project describes itself as a work in progress with the roadmap in a separate file. Before committing, open ROADMAP.md and datacore.api.md, because the first tells you which parts of the Dataview feature set are not built yet and the second tells you exactly what surface other code is allowed to depend on.

## FAQ

### What is the difference between blacksmithgu/datacore and Dataview?

Both index the Markdown files in an Obsidian vault and render live updating views over that index. Datacore changes the index implementation and replaces the query interface with WYSIWYG table views you can edit directly, and it claims support for every query operation Dataview supports plus extras. Its JavaScript API is React based, replacing the dv.pages().where(...) idiom.

### How do I install Datacore into my vault?

There is no store or package install path documented. You build it from source with yarn install and yarn run build, which assembles the plugin with esbuild into the build directory, then run ./scripts/install-built with the path to your vault root. The two can be combined into one command.

### How much faster is Datacore than Dataview?

The project states two to ten times better query and rendering performance, and the repository contains no benchmark, dataset or measurement script behind that range. The described causes are a reworked index, a new query API, and React views with flickerless updates on index changes.

### Can I query sections, blocks and attachments in Datacore?

Yes. The index covers all files, attachments, PDFs and images included, rather than notes only, and queries can be run at section or block level granularity. Markdown, image and video embeds also resolve inside views, with a dedicated view type that is a list of embeds.

### Can I use Datacore as a library in my own Obsidian plugin?

The package declares a main and a types entry point inside a built library directory and publishes only that directory, and its description calls it a reactive data engine for Obsidian.md. The build runs api-extractor in local mode, which rewrites a checked in API report, so the public surface is tracked in a file you can read before depending on it.

## Sources

- [blacksmithgu/datacore on GitHub](https://github.com/blacksmithgu/datacore)
- [Issues](https://github.com/blacksmithgu/datacore/issues)
- [License: MIT](https://github.com/blacksmithgu/datacore/blob/master/LICENSE)
- [README](https://github.com/blacksmithgu/datacore/blob/master/README.md)
- [Releases](https://github.com/blacksmithgu/datacore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/blacksmithgu-datacore