If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/MariaDB/server shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 35+ active contributors
• Distributed ownership (top contributor 13% of recent commits)
• GPL-2.0 licensed
• CI configured
• Tests present
• ⚠ GPL-2.0 is copyleft — check downstream compatibility

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live MariaDB/server repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/MariaDB/server.

What it runs against: a local clone of MariaDB/server — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in MariaDB/server | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of MariaDB/server. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/MariaDB/server.git
#   cd server
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of MariaDB/server and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "MariaDB/server(\\.git)?\\b" \\
  && ok "origin remote is MariaDB/server" \\
  || miss "origin remote is not MariaDB/server (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-2.0" \\
  || miss "license drift — was GPL-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "VERSION" \\
  && ok "VERSION" \\
  || miss "missing critical file: VERSION"
test -f "CODING_STANDARDS.md" \\
  && ok "CODING_STANDARDS.md" \\
  || miss "missing critical file: CODING_STANDARDS.md"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/MariaDB/server"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

MariaDB Server is a community-developed SQL database server forked from MySQL, maintained primarily in C++ (46.7M LOC) with additional C code (28.9M LOC). It provides a drop-in MySQL replacement with additional storage engines (InnoDB, MyISAM, Aria, TokuDB), Galera replication, window functions, and JSON support. The core problem it solves is providing an open-source, feature-rich relational database with better performance and GPL v2 licensing compared to Oracle's MySQL. Monolithic server repository: sql/ contains the query engine and optimizer, storage/ holds pluggable storage engines (innodb/, myisam/, aria/), include/ has public headers, support-files/ contains systemd/init scripts. Build system uses CMake (BUILD-CMAKE, CMakeLists.txt templates) alongside legacy autotools. Test suite distributed across mysql-test/, unittest/, and embedded regression test suites.

Database administrators, DevOps engineers, and open-source contributors who deploy or maintain production SQL databases and need MySQL compatibility with MariaDB-specific features (Galera clustering, Aria storage engine). Developers building applications that require GPL-compatible open-source database infrastructure.

Highly mature and production-ready. The codebase spans multiple decades (forked from MySQL in 2009), has extensive CI/CD via GitHub Actions (workflows/ directory) and AppVeyor, and contains 46K+ C++ test files. Active development evident in compilation scripts for debug, valgrind, ASAN, and UBSAN builds. Used in enterprise deployments worldwide with coordinated security disclosure policy.

Low risk for stable branches, moderate risk for bleeding-edge features. The monolithic C/C++ codebase (75M+ LOC combined) requires careful testing for regression; the BUILD/ directory contains 30+ platform-specific compilation targets, suggesting complex cross-platform maintenance burden. No single visible bottleneck maintainer in file structure, but MariaDB Foundation/Corporation coordination is centralized.

Active development on 11.x and 10.x LTS branches. Recent work visible in: GitHub Actions workflows for Windows ARM64 support (.github/workflows/windows-arm64.yml), label automation for PR triage (label_recent_prs.yaml), and continuous compilation/test targets for debug, ASAN, and Valgrind builds. WSREP (Galera) variants receive regular updates (compile-*-wsrep targets).

Clone and build: git clone https://github.com/MariaDB/server.git && cd server && cmake -DCMAKE_BUILD_TYPE=Debug . && make. For detailed instructions, see: https://mariadb.org/get-involved/getting-started-for-developers/get-code-build-test/. Alternatively, use prebuilt scripts in BUILD/ directory: cd BUILD && ./compile-pentium64-debug-max for a full debug build.

Daily commands: Start the built server: ./sql/mysqld --datadir=/tmp/mariadb-data (data directory must exist). Connect via client: ./client/mysql -u root. For test suite: cd mysql-test && ./mtr --suite=main to run main regression tests. Debug builds with gdb: gdb ./sql/mysqld.

• CMakeLists.txt — Primary build configuration for the entire MariaDB server; all contributors must understand the build system architecture and how to add new components.
• VERSION — Defines the current MariaDB version; critical for release management and version-specific compilation flags.
• CODING_STANDARDS.md — Establishes code style and contribution guidelines that all developers must follow to maintain consistency across the codebase.
• README.md — High-level overview of MariaDB project goals, history, and community structure; foundational context for understanding project direction.
• CONTRIBUTING.md — Outlines the contribution process, issue tracking, and pull request workflow essential for all potential contributors.
• BUILD-CMAKE — Comprehensive CMake build documentation providing step-by-step compilation instructions for multiple platforms and configurations.
• client/CMakeLists.txt — Defines client tool build targets (mysql, mysqladmin, mysqldump, etc.); entry point for understanding client-side architecture.

Add a New Client Tool

1. Create new C/C++ source file in client/ directory following naming convention (e.g., client/mynewtool.cc) (client/mynewtool.cc)
2. Add build target to client/CMakeLists.txt using add_executable() macro and link against libmysqlclient (client/CMakeLists.txt)
3. Use connection_pool.h for connection management and follow mysql.cc patterns for argument parsing and output formatting (client/connection_pool.h)
4. Update BUILD/compile-* scripts if tool requires special compilation flags for specific architectures (BUILD/compile-pentium64-max)
5. Document usage in Docs/ and update INSTALL-BINARY if installation instructions change (Docs/INSTALL-BINARY)

Add Support for a New Platform/Architecture

1. Create new compilation script in BUILD/ directory following naming pattern BUILD/compile-{platform}-{profile} (BUILD/compile-solaris-amd64-forte)
2. Add platform-specific conditional logic to CMakeLists.txt for compiler detection and feature flags (CMakeLists.txt)
3. Create cmake/ helper module for platform detection if needed (e.g., cmake/3rdparty_info.cmake pattern) (cmake/3rdparty_info.cmake)
4. Add CI/CD workflow in .github/workflows/ for automated testing on the new platform (e.g., .github/workflows/windows-arm64.yml pattern) (.github/workflows/windows-arm64.yml)
5. Document platform-specific build requirements in BUILD-CMAKE and update BUILD/util.sh if platform-specific utilities needed (BUILD-CMAKE)

Add a New Build Configuration or Optimization Profile

1. Create new compile script in BUILD/ with desired configuration name (e.g., BUILD/compile-pentium64-custom-profile) (BUILD/compile-pentium64-max)
2. Define CMake variables and compiler flags in the script using cmake_configure.sh patterns (BUILD/cmake_configure.sh)
3. Reference the script in BUILD/util.sh for automated discovery and in CI/CD workflows if needed (BUILD/util.sh)
4. Test across multiple platforms using existing BUILD/compile-* scripts as reference for completeness (BUILD/compile-amd64-debug-max)
5. Document profile rationale and expected performance characteristics in Docs/optimizer_costs.txt or similar (Docs/optimizer_costs.txt)

• CMake — Cross-platform build generation supporting Windows, Linux, Solaris, macOS; enables single source configuration for 15+ architecture targets
• C/C++ — Performance-critical database engine requires compiled language; native I/O, memory management, and CPU-specific optimizations essential
• Shell scripts (BUILD/compile-*) — Encapsulate platform-specific compiler flags, optimization profiles, and build variants without duplicating CMake logic
• GitHub Actions + GitLab CI + AppVeyor — Multi-platform CI coverage: GitHub for Linux/macOS, AppVeyor for Windows, GitLab for enterprise integration
• Binary log (mysqlbinlog.cc) — Core replication mechanism enabling Galera clustering and WSREP; binary-safe serialization of SQL transactions

• Multiple platform-specific compile scripts instead of unified CMake-only approach

  • Why: Each architecture (Pentium, PowerPC, SPARC, ARM64) has unique optimization flags and feature support; encapsulation simplifies CI/CD and manual builds
  • Consequence: Maintenance overhead: 25+ compile scripts must be updated when adding new optimization profiles; mitigated by BUILD/util.sh template abstraction

• Client tools in separate CMakeLists.txt rather than monolithic root configuration

  • Why: Allows building only client tools without server engine; useful for embedded/remote deployments and faster iteration
  • Consequence: Clients have separate version management; must ensure client/server protocol compatibility manually

• Community-driven MySQL fork rather than upstream contribution

  • Why: Independent feature velocity: MariaDB can implement Galera, column storage, JSON, temporal tables faster than Oracle MySQL process
  • Consequence: Binary incompatibility with MySQL 5.7+; users must choose one ecosystem; potential divergence in SQL standard compliance

• No monolithic test suite in file list; tests distributed across CI workflows

  • Why: CI-first testing: platform-specific tests run on actual hardware in AppVeyor/GitHub Actions rather than checked into repo
  • Consequence: Difficult to run full test matrix locally; reliance on CI infrastructure for validation

• Not a cluster-aware distributed SQL engine by default (Galera WSREP is optional add-on in BUILD/compile-*-wsrep)
• Not a real-time database (designed for transactional consistency, not sub-millisecond latency guarantees)
• Not an in-memory database (data persists to disk; memory-only operation not primary design target)
• Not a NoSQL system (purely SQL/relational; key-value or document interfaces are external layers)
• Does not provide automatic schema versioning or migration tools (server role is storage + execution

Compilation complexity: 30+ platform-specific build scripts in BUILD/ (compile-pentium64-max, compile-amd64-wsrep, etc.) each with different feature flags; choose the right one for your target platform. Storage engine plugins: Dynamically loaded; missing shared libraries silently disable features (check error log in mysql-test/var/log/ after test runs). InnoDB file format: By default uses Barracuda; old Antique format may be auto-converted and cannot be reverted. Replication gotcha: Binary log format varies (ROW vs STATEMENT); DDL replication can fail on replicas if table structures differ. Test suite expectations: mysql-test suite expects Unix-like paths and may fail on Windows without WSL; use BUILD/compile-* scripts designed for your OS.

• Pluggable Storage Engine Architecture — MariaDB's primary differentiator — understanding the handler interface (include/handler.h) and how storage engines implement it (storage/innodb/, storage/aria/) is essential for any core engine change
• Cost-Based Query Optimizer — SQL queries are optimized via cost estimation before execution; changes to sql/optimizer/ affect join order, index selection, and execution plans across all workloads
• Binary Logging and Replication — MariaDB replicates via binlog (ROW vs STATEMENT formats); understanding sql/binlog.cc and WSREP integration is critical for distributed deployments and Galera clustering
• InnoDB MVCC and Locking — InnoDB's multi-version concurrency control (MVCC) in storage/innodb/ enables concurrent reads/writes; understanding transaction isolation levels and lock resolution is vital for correctness
• Statement vs Row-Based Replication Trade-offs — MariaDB supports both STATEMENT and ROW binlog formats with different performance and consistency implications; key decision point for production deployments visible in sql/binlog.cc logic
• Memory-Mapped I/O and Buffer Pool — InnoDB and Aria use memory-mapped buffers (storage/innodb/buf0buf.cc) to cache pages; understanding page eviction, dirty page flushing, and buffer pool sizing is essential for performance tuning
• Yacc-based SQL Parsing Pipeline — SQL text → Yacc lexer/parser (sql/sql_yacc.yy) → AST → Optimizer → Executor; modifying the parser requires understanding token definitions and grammar conflicts documented in the .yy file comments

• mysql/mysql-server — Original upstream MySQL project; MariaDB's direct ancestor and compatibility target — track for missing features and bug fixes to backport
• percona/percona-server — Alternative MySQL fork emphasizing performance patches and visibility tools; similar architecture enables cross-learning on optimization techniques
• codership/galera — Galera replication engine used by MariaDB's Galera Cluster; MariaDB integrates via WSREP patches (BUILD/compile-*-wsrep targets)
• MariaDB/mariadb-docker — Official Docker images and deployment configs for MariaDB — reference for containerization and production deployment patterns
• MariaDB/mariadb-benchmarks — Performance benchmarking suite for MariaDB; essential for validating changes don't regress query performance

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions workflow for ARM64 Linux builds (complement windows-arm64.yml)

The repo has .github/workflows/windows-arm64.yml for Windows ARM64 CI, but there's no corresponding Linux ARM64 build workflow. Given MariaDB's emphasis on multi-platform support and the presence of ARM64 compilation scripts in BUILD/, adding a Linux ARM64 GitHub Actions workflow would catch ARM64-specific regressions early and complement the existing Windows ARM64 CI.

• [ ] Create .github/workflows/linux-arm64.yml following the pattern of windows-arm64.yml
• [ ] Reference existing BUILD/compile-amd64-* scripts as templates for ARM64 equivalents
• [ ] Integrate with the existing CMakeLists.txt configuration system
• [ ] Test on qemu-based ARM64 runners or native ARM64 GitHub Actions runners
• [ ] Document the new workflow in CONTRIBUTING.md

Add integration tests for WSREP (Galera Cluster) functionality

Multiple BUILD/ scripts reference WSREP compilation (compile-*-wsrep), indicating this is a core feature, but there's no visible dedicated test suite in the file structure. Adding comprehensive WSREP integration tests would validate cluster synchronization, node failover, and split-brain scenarios—critical for production MariaDB deployments.

• [ ] Create mysql-test/suite/wsrep/ directory for WSREP-specific test cases
• [ ] Add tests for basic replication, node addition/removal, and quorum scenarios
• [ ] Reference existing mysql-test structure and testing framework used in the repo
• [ ] Document WSREP test setup requirements in CONTRIBUTING.md
• [ ] Integrate tests into CI pipelines (reference .gitlab-ci.yml and GitHub workflows)

Add clang-format pre-commit hook and CI check enforcement

The repo contains .clang-format configuration file but there's no automated enforcement. Given the code quality emphasis in CODING_STANDARDS.md, adding a GitHub Actions workflow to validate code formatting on PRs (and a pre-commit hook documentation) would prevent formatting inconsistencies from merging and reduce review friction.

• [ ] Create .github/workflows/code-format-check.yml to run clang-format validation
• [ ] Add clang-format check step that fails the build if formatting violations exist
• [ ] Create .githooks/pre-commit script for local contributor use
• [ ] Document setup instructions in CONTRIBUTING.md (git config core.hooksPath)
• [ ] Test against sample BUILD/ scripts and core source files to ensure .clang-format rules are appropriate

• Add unit tests for newly added storage engine handler methods in unittest/sql/ — many handler.cc functions lack isolated unit test coverage. Start by creating unittest/sql/handler_udf_test.cc following existing unittest/sql/ patterns.
• Improve CMake documentation in BUILD-CMAKE or add examples for common compilation flags (e.g., -DWITH_WSREP=ON, -DCMAKE_BUILD_TYPE=AddressSanitizer) since the file is minimal; cross-reference with BUILD/cmake_configure.sh to document available toggles.
• Audit and add missing #include guards or #pragma once directives in include/ header files — review include/*.h for consistency with .clang-format standards and add missing guards following include/sql_common.h pattern.

MariaDB server demonstrates a mature security posture with documented security policies and CI/CD integration. However, there are moderate concerns regarding external dependency management, supply chain security in build processes, and the centralization of security reporting on external infrastructure. The codebase lacks visible input validation documentation and dependency version pinning mechanisms. Recommendations focus on improving supply chain security, implementing SCA tooling, and enhancing security documentation within the repository itself. No critical vulnerabilities were identified in the visible file structure.

• Medium · Security Policy Redirect to External URL — SECURITY.md. The SECURITY.md file directs users to report vulnerabilities to an external URL (mariadb.org) rather than providing direct contact information or a documented process. This creates a dependency on external infrastructure and could potentially be exploited if the external site is compromised or becomes unavailable. Fix: Include direct security contact information (e.g., security@mariadb.org) and PGP key fingerprints in the SECURITY.md file itself. Maintain the external link as a secondary reference but provide self-contained critical information.
• Low · Multiple Compilation Scripts Without Version Pinning — BUILD/ directory (multiple compile-* scripts). The BUILD/ directory contains numerous compilation scripts (compile-*) that likely invoke build tools and dependencies without apparent version pinning or checksum verification. This could lead to supply chain attacks if dependencies are compromised or unexpectedly updated. Fix: Implement dependency version pinning in build scripts. Use lock files (like CMake's FetchContent_Declare with specific commit hashes) and verify checksums of downloaded dependencies.
• Low · No Visible Input Validation Framework Documentation — client/ directory and codebase structure. While the file structure shows client libraries and handlers, there is no visible documentation on input validation standards or SQL injection prevention mechanisms in the provided structure. Fix: Document input validation and parameterized query usage patterns. Create a SECURITY_CODING_STANDARDS.md file outlining SQL injection prevention practices specific to the codebase.
• Low · Limited Visibility into Dependency Management — .gitmodules, CMakeLists.txt. The .gitmodules file suggests external dependencies are tracked, but no package manager lock files (composer.lock, package-lock.json, etc.) are visible in the provided structure. This makes it difficult to assess dependency security status. Fix: Implement Software Composition Analysis (SCA) tooling in CI/CD pipelines. Generate and maintain SBOM (Software Bill of Materials) for all releases. Use dependency scanning tools like Dependabot or Snyk.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.