Extensible-Storage-Engine is a Windows database engine published under MIT

Twenty-five years of service in Windows

The README opens with a claim about longevity rather than about features, and it is an unusual way to start a project description. The Extensible Storage Engine is described as one of those rare codebases having proven to have a more than 25 year serviceable lifetime. It first shipped in Windows NT 3.51, and shortly after that in Exchange 4.0, and it was rewritten twice in the 90s and heavily updated over the two decades after that, and it remains a core Microsoft asset.

The deployment numbers in the README are what make it more than a historical curiosity. It is described as running on hundreds of thousands of machines and millions of disks for the Office 365 mailbox storage backend servers, and on large symmetric multiprocessing systems with terabytes of memory for large Active Directory deployments. Every Windows client computer has several database instances running in low memory modes, and the README states that in over one billion Windows 10 devices, ESE has been in use in the Windows client SKUs since Windows XP.

That is the context for reading the source. This is not a database engine being designed, it is one that has been shaped by a quarter of a century of production requirements, and the code in the repository is the current state of that.

The licence is MIT, with the text in the `LICENSE` file, the primary language is C++, and the default branch is `main`. The repository is not archived, with the last push on 2026-05-22, and there are no GitHub releases.

JET Blue, not the engine people mean

One section of the README exists purely to correct a misconception, and it is worth reading because the name search will bring you here.

The question asked is whether this is the JET database or engine, and the answer is no, with a qualification: it depends, because the question is not quite correct. The README explains that most people do not know JET was an acronym for an API set, not a specific database format or engine, and that just as there is no such thing as the SQL engine, since there are many implementations of the protocol, there is no JET engine or JET database. The acronym stands for Joint Engine Technology.

There are two separate implementations of the JET API, and this one is JET Blue. The other is JET Red, which shipped under Microsoft Access, and that is the one most people picture when they hear JET. The README says Microsoft renamed the project to ESE to try to avoid the confusion, and that the confusion continues to this day.

For an engineer this matters in a practical way. If you are porting code from Access, or searching for the engine behind an Access database, you are looking for the wrong code. The JET API documentation on Microsoft's documentation site describes the API surface that ESE implements, and the README also points to the Wikipedia entry for a more extensive list of ESE database features.

The one caveat the README attaches to both is worth repeating later, because it affects how you read any documentation you find.

An ISAM engine with cursors, wide tables and sparse indexes

The header of the README calls ESE a non-SQL database engine, and the description calls it an embedded, ISAM-based database engine that provides rudimentary table and indexed access.

The access model is the key thing. ESE lets an application store data in and retrieve data from tables using indexed or sequential cursor navigation, and the schema it supports is not the normalised shape most people picture. It handles denormalised schemas including wide tables with numerous sparse columns, multi-valued columns, and sparse and rich indexes.

That combination is not arbitrary. A wide table with many sparse columns is a mailbox, where most rows have most fields empty, and a multi-valued column is a recipient list or a group membership. A sparse index and a rich index are the two ways ESE indexes a column, and the choice between them trades space for speed. This is a storage engine designed for a particular shape of workload, and the API is shaped around that.

Consistency is handled in the same spirit. ESE provides a consistent data state using transacted data update and retrieval, and a crash recovery mechanism so that data consistency is maintained even in the event of a system crash. The transactions are ACID, atomic, consistent, isolated and durable, over data and schema, by way of a write-ahead log and a snapshot isolation model.

Note the phrase over data and schema. Schema changes are transactional in the same engine as the data, which is a different guarantee from the one you get in a system where the schema lives in a separate catalog.

The libraries that grew up around the engine

The README devotes a section to the sub-facilities, and this is arguably the most reusable part of the repository for a C++ developer who is not building a database.

The description names them: a synchronization and locking library, an STL-like data structures library, an OS abstraction layer, a Block/Cache Manager, and then the full blown database engine itself. The description in the repository metadata says the same thing in more detail, and it makes the point that these are strongly layered and thus reusable.

Read as a codebase, that tells you something about the engineering. A database engine that needs its own locking primitive, its own containers and its own cache manager has grown up in an environment where it could not assume the operating system or the standard library would provide one. The OS abstraction layer in particular is the piece that makes the rest of the code testable off Windows.

The cache manager is the other one worth calling out. A block cache for a database that runs on machines with terabytes of memory and on client laptops running in low memory modes is not a convenience, and the fact that it is a separately layered component means it can be used on its own.

For an adopter who is not interested in the engine at all, these four libraries are the realistic integration surface, and the MIT licence makes lifting them into another codebase a straightforward exercise rather than a negotiation.

The published source runs ahead of the shipped product

There is one sentence in the README that anyone integrating against the documentation needs to know, and it is easy to miss.

The version of source posted in the repository will likely be a bit in advance of the version compiled into the latest Windows update, and therefore the JET API documentation may be out of date with it.

That is an unusual admission to make in a README, and it changes how you should use the two references the README gives you. The JET API documentation on the Microsoft documentation site describes the API of the shipped engine, which is the version most people can actually run, and the Wikipedia entry describes the features of ESE. The source in the repository may implement more than either, and it may implement it slightly differently.

The repository layout is small and conventional for a project of this kind. There is a `CMakeLists.txt` at the root, a `BUILDING.md` for the build instructions, a `dev/` directory and a `test/` directory, and the usual set of community files, with `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md` and `SUPPORT.md`.

A continuous commit push is the plan, and the tests are partial

The future plans section is dated, and the dating is the interesting part.

The Continuous Commit Push plan says that as of June 2021 the code was a single snapshot of the source code, and that commits would be pushed from the internal repository as they are made individually, instead of as a periodic monolithic drop. So the intent is that the public repository becomes a mirror of internal development rather than a series of large releases.

The Tests plan says the unit tests were released, that more test code may be released in the future, and that Azure pipelines would be added to run the tests that are already present in the repository. The `dev/` and `test/` directories in the tree are the visible part of that, and the presence of a `test/` directory at the root is the practical signal that there is something to run, alongside the CMake build.

What the README does not describe is the rate at which commits have actually landed since that plan was written, and the last push on 2026-05-22 is the only public data point on the current cadence.

The two things an integrator should therefore check are the commit log, to see whether the continuous push actually happened, and the test suite, to see whether it runs in your environment. A database engine published without a pipeline running its own tests is a different proposition from one published with continuous integration behind it, and the README's own plan is to add that pipeline.

What this codebase is realistically for

It is worth being blunt about the fit, because the popularity of the name could lead somebody to a wrong conclusion.

This is a Windows storage engine. The C++ code assumes Windows, the OS abstraction layer exists to hide the differences, and the deployment story in the README is entirely about Windows workloads, from Office 365 mailbox backends to Active Directory to client laptops. A team on Linux can read the code and, where the OS abstraction layer reaches, port pieces of it, but the engine itself is not a portable database.

It is also not a SQL database, and the README is clear about that in its own heading. If the requirement is a relational store with a query language, this is the wrong shape entirely, and the fact that the engine has been in Windows for a quarter century says nothing about whether it fits a request for SQL.

What it is good for is narrower and more valuable: an embedded, transactional, crash-safe, index-based store with a long production pedigree and no licensing friction, plus a set of internal libraries that are hard to find elsewhere. A team that knows the shape of the workload, has a Windows target, and wants a durable store with a write-ahead log and snapshot isolation will find the source readable and the API documented. A team that wants a general purpose database will find neither the API nor the shape convenient.

The best-supported case is the middle one, where the locking library, the container library or the block cache manager is the actual deliverable, and the engine is the reason those pieces exist.

Editorial conclusion

Extensible-Storage-Engine fits a team that needs the storage engine used by Exchange and Active Directory, or a C++ developer who wants its locking library, container library or block cache manager as a standalone component. Skip it if you want a SQL database, if you are on a platform other than Windows, or if you need a project whose upstream commits land continuously. Verify first which Windows build your copy corresponds to, since the README says the posted source is ahead of the compiled-in version and that the API documentation may therefore lag, and expect to build it with CMake before you can read the code in a debugger.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/Extensible-Storage-Engine on GitHub
4. README