The documentation for MariaDB products is

• written in standard American English,

• using Markdown format,

• stored in Git.

It is maintained by a team of technical writers from MariaDB plc and the MariaDB Foundation.

Until June 2025, the documentation used to be in the MariaDB KnowledgeBase (KB). With a few exceptions, mostly concerning outdated modules and functionality, all pages were migrated to a new platform, GitBook.

The documentation for MariaDB products is

• written in standard American English,

• using Markdown format,

• stored in Git.

While the documentation is mainly maintained by the documentation team at MariaDB plc, we are happy to get contributions. Being stored in Git, it allows anyone to contribute to the documentation. You need a GitHub account, a basic knowledge of Markdown, and some expertise in what you’re writing about. You also have to agree to our contributor agreement.

Contributing is as simple as this:

• Access this repository, log in with your GitHub account.

• Find the page in the documentation that you want to edit, correct, or amend.

• Make a pull request, edit, and submit.

The MariaDB documentation team will review your edits, smooth out any rough edges (language and style), and incorporate your contribution into the documentation. Don’t be afraid to submit imperfect contributions, as long as they’re factually correct.

Before you start making larger contributions, make yourself familiar with the basics of technical writing (a 1-minute read). This is about using proper tone and content, language and grammar, as well as formatting, punctuation, and organization.

The source format of pages is Markdown. How to format text is on this GitBook page. A Markdown cheat sheet with a 10-minute tutorial and a Markdown "playground" can be found here.

Read our style guide, too. (It's short!)

Style Guide

We adhere to the Google developer documentation style guide. Here are some links to particularly important resources from that style guide:

• Word list – an alphabetically ordered list that allows you to quickly find words to use, or not to use, and recommendations of words and terms to use.

• Accessibility – write inclusive documentation for a global audience.

• Timeless documentation – avoid words and terms like currently, existing, in the future, now, or soon.

• Capitalization – when to use the Shift key, and how to format headings and titles. We use upper case for headings, which is about the only deviation from the Google style guide.

• Abbreviations – how to use acronyms and initialisms.

• Punctuation – how to properly use colons, commas, dashes, etc.

• Formatting and organization – how to write dates and times, headings and titles, when to use lists or rather tables.

• Cross-references – how to properly write links.

• Code samples – how to write and format code blocks.

• Example domain names, IP numbers, and person names – and how to use filenames and trademarks.

Additional Information

Version-specific information: We refer to software versions (like "MariaDB 10.6") only for products (like MariaDB Server or MaxScale) or features (like replication or authentication) that follow the N-1 rule, where N is the last version still under maintenance. (At the time of writing, that's MariaDB 10.6 for the Server.) In other words, we'd mention MariaDB 10.5, but not versions older than that. This is the principle, from which we will deviate if there's a valid reason to do so.

Bug Reports

If you find issues in the documentation, please report them:

1. Report only one issue per request. If you find multiple issues, report them one by one. Only report documentation issues, not software issues or software help requests.

2. Provide the URL of the page that has an issue, for example https://mariadb.com/docs/general-resources/about/readme/reporting-documentation-bugs. ℹ️ When reporting via the rating system, the URL of the page you're on will be automatically be included in your response, so there's no need to include the URL.

3. Indicate the nature of the issue:

   1. Typo, for example "known bucks should be known bugs".

   2. Wrong information. Provide details of what's wrong. Ideally, point out what the right information should be.

   3. Missing information. Provide details of what's missing.

   4. Unclear information. Provide details of what's unclear. Ideally, provide a clarification.

Reporting Channels

Use one of the following channels to report documentation issues. Please don't report software issues via those channels — instructions for doing that are on this page.

Rating system in the right sidebar

This is a super quick way to provide feedback or report issues in the documentation. However, it's one-way communication — we can't provide feedback to you, since we don't know who you are. 😇 ℹ️ Don't paste the URL of the page you're reporting from, since it will automatically be included.

MariaDB Community Slack

Join the #documentation channel in MariaDB Community Slack. This allows for more detailed feedback or reports, and naturally provides two-way communication.

_{This page is licensed: CC BY-SA / Gnu FDL}