MySQL and MariaDB requirements for GLPI: what to choose and why it matters
If you are standing up or upgrading a self-hosted GLPI, you must choose a database engine and version before go-live, and GLPI supports only MySQL and MariaDB. The right version depends on the GLPI release you plan to run, so start with the release and choose the database to match. The GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation prerequisites page lists PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. These minimums differ, so confirm the database version against the page for your exact release before you order servers or write an upgrade plan.
Database tuning becomes its own workstream once an instance grows in agents, users, search volume and reporting. Typical triggers are a large inventory fed by GLPI Agent, heavy searches across assets and tickets, and scheduled reports that run during business hours. At that point the InnoDB buffer pool, which keeps table and index data in memory, and the temporary table limits decide how much work stays off disk. The settings Teclib suggests for busy instances cover these areas. Their values depend on your memory, workload and database version, so treat them as starting points that you confirm through load tests before production use.
Choose the engine by the support window you need and by the versions your GLPI release accepts. On the MariaDB side, the 12.3 long-term release reached general availability on May 28, 2026, alongside maintained releases 11.8, 11.4 and 10.11, while the 13.0 rolling release has a community end of life in Q4 2026. On the MySQL side, the 8.4 LTS track offers five years of premier support under Oracle's policy. Keep the web tier and the database on the same low-latency network segment, because every query round trip adds delay to each page. Measure latency between them from your own network, and check the GLPI prerequisites for the versions your release requires.
Database versions per GLPI release and which engine fits
This table compares the database and PHP minimums GLPI documents for versions 10, 11 and 12 with the MariaDB and MySQL branches that are currently listed as maintained. Read each row against the exact GLPI release you plan to install, because the README on the main branch and the installation docs for GLPI 11.0 do not give identical minimums. The main takeaway is that MariaDB 10.11 and MySQL 8.0 are the oldest branches named in the current requirements, so choose a branch that is still within vendor support for your planned upgrade window.
| Release or branch | Documented requirement or support note | What to confirm before install |
|---|---|---|
| GLPI 10.0 | Released April 20, 2022. Confirm its PHP and database minimums in the 10.0 documentation for your exact point release. | Whether your planned release still receives fixes and which database versions its docs list |
| GLPI 11.0 | Installation docs list PHP 8.2 or later, MySQL 8.0 or MariaDB 10.6. Only MySQL and MariaDB are supported. | Whether MariaDB 10.6 is still receiving updates from the Foundation before you commit to it |
| GLPI 12.0 | Released October 7, 2026. The main branch README lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later. | The 12.0.0 release notes and installation docs for the minimums that apply to your tag |
| MariaDB 12.3 (LTS) | Long-term release with a GA date of May 28, 2026, announced by the MariaDB Foundation. | Whether your GLPI release is tested against this branch before you select it |
| MariaDB 11.8 and 11.4 (LTS) | Both are maintained LTS releases. The README lists native VECTOR data type support from 11.8. | Support end dates on the MariaDB Foundation release calendar |
| MariaDB 10.11 (LTS) | Maintained LTS release and the minimum named in the GLPI 12 main branch README. | Remaining support window against your planned GLPI upgrade dates |
| MySQL 8.4 (LTS) | LTS track under the Oracle Lifetime Support Policy, with 5 years of premier and 3 years of extended support. | Current support phase and end dates in the Oracle policy for your chosen point release |
| MySQL 8.0 | Named in GLPI 11 and 12 minimums. Older branch, so check its Oracle support dates before a new build. | Whether GLPI 11 or 12 will be supported on 8.0 for the full period you plan to run it |
InnoDB buffer pool and temporary table settings for busy instances
A single-site GLPI instance with a modest asset count and a small technician team usually spends most of its database time on ticket reads, form saves and the occasional inventory import. In this setting the InnoDB buffer pool is the setting to understand first, because it holds table and index pages in memory and decides how often queries reach disk. Temporary table limits matter less, but they still affect sorts and grouped lists in the ticket views. Start from the defaults of your chosen database version, measure the size of the GLPI schema, and only raise memory allocations after you have confirmed the host has room left for PHP-FPM or Apache and the operating system.
- Buffer pool sizing: Compare the size of the GLPI tables on disk with the memory you can spare for the database, and keep headroom for the web tier.
- Temporary tables: Leave the limits at conservative values unless slow queries show disk-based temporary tables.
- Single host overlap: If the database shares a host with the web server, reserve memory for each process before raising the pool.
- Observed behavior: Watch buffer pool hit rates and read counts over normal working days, not only during a quick test.
- Change control: Make one change at a time and record the before and after values.
Before you change any value, confirm Teclib's current recommendations for your GLPI version in the GLPI documentation and check the database vendor's guidance for your release.
When thousands of agents report inventory, the database receives frequent small writes, large batches of software and hardware records and many concurrent reads from the technician interface. The buffer pool has to hold the hot parts of the inventory tables and their indexes, otherwise inventory processing and ticket searches compete for disk I/O. Temporary tables also become more relevant, because inventory reconciliation, duplicate checks and grouped reports create intermediate result sets. Sizing here depends on how many agents report, how often they run and how large the software catalog grows, so the target is derived from measured data rather than a fixed number.
- Hot working set: Estimate how much of the inventory and software tables are read repeatedly and aim the pool at that working set.
- Inventory windows: Measure buffer pool behavior during the busiest agent reporting period, since that is when pressure peaks.
- Temporary table pressure: Check for temporary tables written to disk during reconciliation jobs and grouped queries.
- Concurrency limits: Align connection counts with the web and worker processes so memory is not divided among too many sessions.
- Index maintenance: Review table growth and index size, because a larger index footprint needs more buffer pool.
Before you change any value, confirm Teclib's current guidance for inventory-heavy instances and the agent reporting architecture you plan to use.
Instances that run long reports, large exports or dashboards against the production database place a different load on InnoDB. Reports scan large portions of tables, which can push useful pages out of the buffer pool, and sorts or aggregations often create temporary tables that grow beyond their in-memory limits. The priority is to protect interactive ticket work from report traffic. Teams often schedule reports, limit their scope or send them to a read replica, and then tune the primary for transactional use. Any change to memory settings should follow measurement of query plans and temporary table usage during realistic report runs.
- Report scope: Limit the date ranges and columns of recurring reports so they touch fewer pages.
- Temporary table ceilings: Measure how often reports spill to disk and adjust the in-memory limits only after confirming available RAM.
- Pool protection: Consider whether heavy scans should run away from the primary, using a replica where the data freshness is acceptable.
- Query plans: Use the slow query log and execution plans to find sorts and joins that drive temporary table use.
- Scheduling: Run long jobs outside ticket peaks and record their runtime to compare changes.
Before you change any value, confirm Teclib's recommendations for reporting workloads in the GLPI documentation and test the change on a copy of production data.
How to set up and verify the database for GLPI
This sequence takes you from confirming the GLPI release and database version through a least-privilege database account, tuned settings and a low-latency network path, ending with a verified installer run and schema update. Each step closes with a check you can record.
Confirm the GLPI release and database branch
Start by fixing the GLPI version you will run, then match it to the PHP and database requirements published for that release. The GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Confirm which set applies to your target release and record the exact database branch. Done means you have a written pairing of GLPI release, PHP version and database branch that your team has signed off.
Install a supported MySQL or MariaDB branch
Install a database branch that is still maintained at the time of deployment, using your operating system packages or the vendor repositories your organization already approves. GLPI supports only MySQL and MariaDB, so do not substitute another engine. For MariaDB, check the lifecycle published by the MariaDB Foundation, including which branches are long-term releases. For MySQL, check whether the branch is on the LTS or Innovation track, since Innovation releases are supported only until the next Innovation release. Done means the server reports the exact version you recorded in step one and the service starts cleanly on boot.
Create the GLPI database and a least-privilege user
Create a dedicated database and an application account that can reach only that database from the web tier address. Grant the account the privileges GLPI needs for its schema and updates, and avoid using the root or administrative account for the application. Store the password in your secrets system rather than in shell history or a shared document. Done means a login from the web server host succeeds with the new account, and a login to another schema is refused.
Set character set, collation and timezone tables
Create the database with a UTF-8 character set and collation consistent with what the GLPI installation docs specify for your release, then load the timezone tables so GLPI can resolve named timezones. Grant the application user the access needed to read those tables as the installer and update procedures expect. Confirm the setting in the GLPI installation docs for your version before you create the schema, because changing it later is harder. Done means a query on the server returns the expected character set and collation, and the timezone lookup returns a value.
Apply InnoDB and temporary table tuning
Set the InnoDB buffer pool, temporary table limits and connection settings in the server configuration file, sized against the memory the database host can spare after the operating system and the web tier. Teclib's guidance for busy instances is the reference point for these values, so check the current GLPI documentation for the settings it recommends before you change them. Restart the service and confirm the values took effect. Done means the running server reports the buffer pool and temporary table values you set, and the host shows no swapping under a normal login and inventory load.
Place the database on a low-latency network path
Put the database server on the same network segment or availability zone as the GLPI web and application tier where your infrastructure allows, and open only the database port between those hosts. GLPI issues many small queries per page, so network round-trip time adds up quickly. Measure latency from the web host to the database with a simple round-trip test and record it. Done means the measured round-trip time is recorded, the firewall rule is limited to the web tier, and your team agrees the path meets its response-time goals.
Verify with the GLPI installer
Run the GLPI installer from the web tier using the new database account, then complete the installation and confirm the application loads and logs in. Check the system status page in GLPI for database connection and character set warnings. Done means the installer finishes without errors, the status page shows no database warnings, and a test login succeeds.
Verify upgrades with db:update
When you move to a new GLPI release, back up the database, files and config directory first, replace the application files, then run php bin/console db:update from the GLPI root. Check the command output for schema changes and errors, and reactivate plugins after the update as the update documentation describes. Done means db:update completes without errors, the status page reports the new version, and a test ticket and asset record can be read and saved.
Keeping web-to-database latency low in practice
Every extra millisecond between the web tier and the database is multiplied by the number of queries a GLPI page issues, and GLPI issues many small ones. A ticket list, an asset form or a dashboard widget is typically assembled from numerous short reads, each waiting on a network round trip before the next can start. A database that answers quickly on the server can still feel slow if the path between the PHP workers and MariaDB or MySQL adds latency to every statement. Co-locating the web tier and the database on the same host or the same network segment, with a short and uncongested path, is the most direct control you have.
Connection handling matters as much as distance. Opening a new connection for each request adds handshake cost, and PHP's default behavior is to close the connection when a request ends. Persistent connections in PHP can reduce that setup cost, but they carry trade-offs: each idle connection holds a server thread and memory, and the database's connection limit must cover every web worker across every front end. Check the GLPI and PHP documentation for your version before enabling persistence, and confirm that your proxy, firewall or load balancer does not silently drop idle sessions, since a dropped connection surfaces as intermittent errors rather than slowness.
Measure before and after each change rather than relying on impressions. Record the round-trip time between the web tier and the database with a simple ICMP or TCP probe, then time a representative GLPI page from the web server's access log and compare it against slow query logging on the database side. Run the same tests at comparable load, because a path that looks fine when idle can queue under concurrent users. Keep the results with your change record so that a later move, such as adding a replica or a new firewall rule, can be checked against a known baseline.
Security and operational considerations for the GLPI database
The database holds every ticket, asset and credential GLPI manages, so its transport, accounts, backups and upgrades need the same planning as the application itself. The cards below cover the controls to settle before go-live and the upgrade behavior to plan for.
Encrypt the connection to the database
GLPI connects to MySQL or MariaDB over the network when the database runs on its own host, so the traffic carries session data and credentials unless TLS is enforced. Confirm that the server certificate is trusted by the GLPI host, that the connection uses TLS rather than falling back to plaintext, and that the database port is reachable only from the web and cron hosts. Test the setting after every server upgrade, since client and server TLS defaults can change.
Use a least-privilege database account
Create a dedicated account for GLPI with rights limited to its own schema, and do not reuse the root or administrative account from the server. Ask your database team whether the installer and the db:update step need elevated rights during install or upgrade, and remove those rights afterward. Keep a separate, tightly held account for replicas and reporting if you add them, so a read-only consumer cannot change tickets or assets.
Back up the database with the GLPI keys
A database backup alone cannot restore a working GLPI instance. The glpi.key and glpicrypt.key files in the config directory are needed to read encrypted values, so store them with the database dump and the files directory under the same retention rules. Test a restore to a separate host and confirm that GLPI starts and decrypts stored credentials. Keep keys out of the web root and restrict their file permissions.
Protect credentials in configuration
GLPI stores database connection details in its configuration file, and that file is readable by anyone with access to the server's filesystem. Restrict read access to the web server user and the administrators who maintain the host, and keep the file out of version control and shared tooling. If you use containers, pass database passwords through secrets or a secrets manager instead of plain environment variables in compose files. Rotate the password after staff changes and record the rotation in your change log.
Patch within the supported database branch
Minor patch releases of MySQL or MariaDB within the branch GLPI supports are a routine security task that should not require a GLPI update. Confirm the current branch requirements for your GLPI release before choosing a version, and plan a patch window that includes a backup and a smoke test of login, search and inventory. Track the end-of-life dates for the branch you run, because a branch that leaves support forces a larger upgrade under time pressure.
Plan db:update around engine upgrades
A minor engine patch usually leaves GLPI's schema untouched, but a major MySQL or MariaDB upgrade changes the server that php bin/console db:update runs against. Take a full backup before the engine change, run the GLPI update in a staging copy first, and confirm that the schema migration completes without errors. Reactivate plugins after the migration, since GLPI 11 suspends them when it detects a new version.
Questions teams ask before tuning GLPI's database
Is MariaDB or MySQL better for running GLPI?
Neither is better in general. GLPI supports both, and the choice should follow your version requirements, your platform standards and the skills your team already has. The GLPI README on the main branch lists MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs list MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Check the requirements for the exact GLPI release you plan to run, because the minimum versions change between releases. MariaDB is community-governed and GPLv2 licensed, and MySQL Community Edition is GPL licensed with an LTS track. Confirm your own licensing position and support contract before deciding, since those terms differ between the two products and between editions.
What drives the cost of a GLPI database review?
The main driver is how much of the database work is new. A review of an existing instance costs less than a design for a new one, and the scope grows with the number of agents, assets, users, plugins and replicas involved. Other factors include how much historical data exists, whether the database runs on dedicated hardware or shared virtual machines, and whether you need evidence for a compliance review. Costs are one-time for the assessment and tuning plan, and may recur if you add a retainer for upgrades or monitoring. Ask any provider for a written scope that lists the instances, the environments, the deliverables and the testing included before you compare figures.
How long does a database tuning pass take?
The duration depends on the scope, the size of the instance and how many changes need testing in a non-production environment. No duration is fixed for every installation, so ask for a timeline in the written scope rather than assuming one. Plan for time to collect baseline metrics before changing anything, time to apply settings and measure the effect, and time for a change window if the buffer pool or temporary table limits need a restart. Also allow time for the work that surrounds tuning, such as checking the GLPI version, verifying backups and confirming the web-to-database network path.
What does the work need from our team?
Expect to provide access and context. Your team should supply the GLPI and database versions, the host sizes, a representative period of metrics, the list of plugins, and the current backup and restore procedure. You will need someone who can approve configuration changes and schedule restarts, and someone who knows the network path between the web servers and the database. Engineers should be available to validate GLPI behavior after each change, especially reports, search and scheduled tasks. Confirm who owns production change approval before work starts.
Can our team tune GLPI's database without outside help?
Yes, if you have database administrators who understand InnoDB memory use, query behavior and safe change control. The GLPI installation docs and the vendor documentation for your chosen database cover the settings, and a careful team can work through them. Outside help is most useful when the instance is large, when the database is shared with other applications, or when you need a documented result for an audit. Whichever path you take, test each change in a copy of production, record the baseline, and keep a rollback plan.
Which settings should we tune first, and what could go wrong?
Start by measuring rather than copying values from a forum post. The usual candidates are the InnoDB buffer pool size and temporary table limits, which Teclib's guidance addresses for busy instances, and the network latency between web and database servers. Common problems include setting memory too high for the host, which can cause swapping, and changing values without a restart plan. Validate the change against GLPI functions such as inventory import, search, reports and scheduled tasks, and keep a tested restore path before you change anything in production.
How do we get an accurate quote for this work?
Send a written description of your GLPI version, database version, number of agents and users, hosting model, plugins and environments, along with the outcome you need, such as a documented baseline or a change plan. DeployOpen does not publish a price list. A quote follows from the written scope, which states the deliverables, testing, exclusions and timelines. Ask for each cost component to be listed separately, including any retainer for later support, so you can compare providers on the same basis.
Limits to confirm in your own environment
The facts on this page describe upstream releases at a point in time, not the matrix that applies to your GLPI release, your engine or your hosting. The cards below list what to verify before you commit to a database version, a tuning profile and a replica or backup design.
Version matrix for your GLPI release
The GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs list MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Confirm the row that matches the exact GLPI version you will run, because the two sources do not share one matrix. Check the minimum for your PHP version as well, since the database floor is only one part of the stack.
Teclib's current tuning guidance
Buffer pool and temporary table values change with instance size and workload, and published guidance can move between releases. Ask Teclib or check the current GLPI documentation for the settings it recommends for busy instances, and record the version you tested against. Treat any value you copy from a forum or older guide as unverified until you have measured it on your own data.
Hosting and storage performance
Database latency depends on where the database runs relative to the web tier, on the storage backing InnoDB, and on whether the disks can sustain the write load from inventory imports and notification queues. Measure round-trip latency from the web server to the database host and the disk latency under load in the environment you will use. A low-latency network path and fast storage matter more than any single configuration key.
License terms for your chosen engine
MariaDB Server is licensed under GPLv2 and MySQL Community Edition is available under the GPL license, but the Enterprise Edition features and Oracle support terms are separate commercial terms. Confirm which edition and features you plan to use, and check the license terms that apply to the packaged version from your distribution or vendor. Your legal or procurement team should own this review.
Backup and replica tooling per branch
Backup tools, replication features and GLPI's own replica settings are not guaranteed to behave the same across MariaDB and MySQL branches or across LTS and rolling releases. Confirm that your backup software, your replica method and the GLPI replica options support the exact branch and version you choose, and test a restore on that version before go-live. Plan a re-test after each minor upgrade.
Release track and support window
MariaDB publishes a yearly long-term release with community support for 3 years after GA, and rolling releases with a shorter life. MySQL splits into an LTS track and an Innovation track, where Innovation releases are supported only until the next one. Choose a track that outlasts your planned GLPI upgrade cycle, and confirm the end-of-life date for the branch you pick with the vendor before you commit.
Where to read the official database requirements
Start with the GLPI installation prerequisites page, because it is the authority for which database engine and version a given GLPI release supports. The installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, and state that only MySQL and MariaDB are supported. Read the page for the exact release line you plan to run, since the README on the main branch shows different minimums (PHP 8.3 or later, MariaDB 10.11 or later or MySQL 8.0 or later) that apply to the development branch. Confirm the target version against the GLPI prerequisites page before you choose a database server.
Use the GLPI README to check the current baseline for the branch you are evaluating, and treat it as the source for development-branch requirements rather than production guidance for a stable release. For the database engine itself, the MariaDB Server release page and the MySQL release notes are authoritative for support windows, patch levels and which releases are long-term. MariaDB publishes its maintained LTS lines on its server releases page, and the MySQL 8.4 reference manual explains the LTS and Innovation tracks in its release documentation. Record the end-of-life date for your chosen engine, because GLPI's minimum version can rise while your database remains supported only for a limited period.
How DeployOpen scopes and delivers GLPI database work
DeployOpen plans, implements, tunes, backs up and documents the MySQL or MariaDB layer under a self-hosted GLPI instance, inside infrastructure you control. The work starts from your GLPI version, your user and agent load, and the latency between your web and database tiers, and it is agreed in writing before any change is made.
How we scope
- Confirm the GLPI release, PHP version and database engine and version against the current requirements before any choice is made.
- Record instance size, expected user and agent load, and where the web and database servers sit on the network.
- Write the scope in an agreed document covering settings to change, what stays out of scope, and the acceptance tests.
How we build
- Install or upgrade the MySQL or MariaDB server with settings for InnoDB buffer pool and temporary tables sized to your host.
- Measure round-trip latency between the GLPI web tier and the database, and correct network or connection issues found in testing.
- Test GLPI search, reporting and inventory import under load, and keep a record of each change and its measured effect.
How we hand over
- Deliver a configuration document listing every database setting, its value, the reason for it and the file where it lives.
- Provide the backup and restore procedure for the database, tested against a restore into a separate environment.
- Walk your platform and database teams through the upgrade steps needed when GLPI or the database engine changes version.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Re-check database settings after GLPI upgrades, engine upgrades or significant growth in agents and assets.
- Confirm with your team how database monitoring and alerting will be owned once the engagement ends.
