MicrosoftDocs/sql-docs, and how the SQL Server documentation is actually built

The upstream of a documentation site most people only see rendered

The repository description says this is the GitHub repository that houses the source for SQL Server technical documentation, and the published result lives at the SQL section of Microsoft Learn.

That distinction is the whole point of the project. Most developers meet SQL Server documentation as a set of rendered web pages, and this repository is where those pages are written. The published site is a build product, and the repository is the editable form of it.

The scope is broader than the database engine. The description names SQL Server itself and tools such as SQL Server Management Studio and SQL Server Data Tools, and the repository layout reflects that with separate top level directories for azure-sql, data-migration, docs, managed-reference and media.

The managed-reference directory is worth singling out, because it is the part that people forget is documentation too. Reference material for the system catalog views, the stored procedures and the functions is generated from the product surface, and it changes with every release, which is why it lives in its own tree rather than among the narrative articles.

The primary language of the repository is recorded as unknown, which is honest for a documentation repository. The content is Markdown with embedded metadata, and the tooling around it is what determines the shape of the files.

The licence is CC-BY-4.0, which is a content licence with an attribution requirement, and the repository carries a separate code licence alongside it.

Two tiers of contribution, and the paperwork difference between them

The contribute section splits submissions into two categories, and the distinction is not about size alone, it is about who is contributing and what the change contains.

Minor corrections or clarifications that you submit for documentation and code examples in this repository are covered by the Terms of Use. That is the low friction path. Fix a typo, clarify a sentence, correct a broken sample, and the change is handled under the existing terms without further paperwork.

Larger submissions work differently. If you submit a pull request with new content or significant changes to documentation or code examples and you are not an employee of Microsoft, the project says they will send a comment in GitHub asking you to submit an online Contribution License Agreement, and that they need the online form completed before the pull request can be accepted.

So there are effectively two tracks. An employee of Microsoft contributing new material and an outside contributor contributing new material are treated differently, and an outside contributor fixing a typo is not asked to sign anything. That is a sensible design for a documentation set, because the volume of typo fixes is enormous and requiring a form for each would be unusable, while the volume of new chapters is small and each one is a statement about what the product is.

Anyone can submit changes, and the project description says so plainly, with a link to a page on how to contribute to SQL Server documentation and a link to the documentation home as the next step.

A dozen redirection files, and what they are for

The most distinctive thing in the top level listing is a family of configuration files, and their names describe the product history that the documentation has to absorb.

There is a base.openpublishing.publish.config.json, which is the publishing configuration, and then a set of redirection files, one per product or product area:.openpublishing.redirection.json,.openpublishing.redirection.azure-data-studio.json,.openpublishing.redirection.azure-sql.json,.openpublishing.redirection.big-data-cluster.json,.openpublishing.redirection.data-migration.json,.openpublishing.redirection.parallel-data-warehouse.json,.openpublishing.redirection.powershell.json,.openpublishing.redirection.ssms.json,.openpublishing.redirection.stretch-database.json and.openpublishing.redirection.visual-studio-code-extensions.json.

Every one of those names is a product that has been renamed, retired, merged or moved.

The redirection files are how a documentation set survives that. When a page moves or a product disappears, the publishing pipeline uses the redirection data to make the old URL resolve to the new one, so that a link in a blog post from 2018 does not become a dead end. That is invisible in the rendered site and entirely visible in the repository, and it is the reason the tree has ten files that do nothing but describe URLs.

There is also a.localization-config file, which is how the same content is served in dozens of languages, and a.code directory, a ThirdPartyNotices file, a SECURITY.md, a CONTRIBUTING.md and both licence files.

Two licences, and what each covers

The repository carries a LICENSE and a LICENSE-CODE, and the description records the licence as CC-BY-4.0.

That combination is the standard arrangement for a documentation set with samples in it, and the two licences cover different things. The content licence covers the prose, the Markdown source, the images in the media directory, and the explanatory text around the examples. CC-BY-4.0 permits reuse including commercially, and requires that the original authors are credited and that changes are indicated. The separate code licence covers the code samples, and it is a different set of terms, which is the one to read before copying a script out of an article into a product.

The ThirdPartyNotices file is the third piece, and it exists because a documentation repository vendors content that is not Microsoft's. Screenshots of other products, sample data, and text or code borrowed under a compatible licence all have to be recorded somewhere, and that file is where the record is.

For a reader who wants to reuse the documentation, the practical sequence is to check the content licence for the prose, the code licence for the samples, and the notices file for anything that is neither. And the Creative Commons attribution requirement is not a formality to ignore: if you republish a substantial portion of the text, you have to name Microsoft as the source.

That is what makes this repository useful to a translator, to a university course, or to a company building an internal mirror, provided the attribution travels with it.

The live branch, and the absence of releases

The default branch is named live, and the repository publishes no GitHub releases. The last push was on 2026-10-14 and the repository is not archived.

A branch called live is not a development branch, it is the branch the site is built from, and the naming is a deliberate statement about the relationship between the repository and the published site. There is no release cycle because there is no artefact: the documentation is published continuously from this tree, and a change that lands is a change that is on the site.

That has consequences for a contributor. A pull request is not a proposal for a future release, it is a change to the live documentation, moderated by the same review process that the product's own documentation goes through. And the cost of a mistake is paid by every reader of the site, which is why the process for larger submissions includes a licence agreement and why the project asks you to read the wiki and the contribution guidance before opening anything.

The two topics on the repository are ms-x-content, which is the internal content system that the publishing pipeline reads, and skilling, which reflects how the content is used, in the sense of learning material for roles rather than only reference material.

There is no test suite to run locally and no build to reproduce, because the build belongs to Microsoft's publishing pipeline rather than to the repository. For a documentation repository that is unusual, and it means the only local check available is a careful read of the diff.

Editorial conclusion

Adopt this repository if you need the SQL Server documentation as source, for a translation, an offline set, a fork in your own documentation system, or a large set of corrections, because it is the upstream of the published site and nothing else reproduces that pipeline. Do not use it as a vendored copy of SQL Server knowledge without reading the licences, because the content is CC-BY-4.0 and the samples carry a separate code licence with its own terms. Before you open a pull request, decide whether your change is a minor correction or new content, since only the first avoids the contribution licence agreement step, and check the redirection files before you move a page, because the publishing pipeline uses them to keep old links alive.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. MicrosoftDocs/sql-docs on GitHub
4. README