Which database to run EspoCRM on, and when each fits
If your team already runs MySQL or MariaDB and wants the path the vendor tests most visibly, the bundled MariaDB route is usually enough. If your organization has a standing PostgreSQL estate with people who patch, back up and fail it over, PostgreSQL is a defensible choice, but you take on a manual or custom deployment. The EspoCRM installation script for Ubuntu, Debian and Linux Mint deploys a Docker-based stack with Nginx and MariaDB, along with optional Let's Encrypt certificates and a command.sh utility for backups, restores and upgrades. Choosing MySQL, MariaDB or PostgreSQL outside that script means your team owns the web server, database, PHP settings and the cron or scheduled task that EspoCRM needs for background jobs.
MySQL 8.0 or later and MariaDB 10.6 or later are both supported, and the server configuration page says the default database settings work with no special requirements. Choose MySQL or MariaDB when your DBAs already know its backup tooling, replication and monitoring, when you want the script's supported layout, or when your restore runbooks already cover it. MariaDB is a GPLv2 server maintained with the MariaDB Foundation, and its README describes a high degree of MySQL compatibility. Confirm which MariaDB or MySQL line your distribution and EspoCRM release both support before you pin a version, because the supported list is a minimum, not a guarantee for every point release.
PostgreSQL appears on the supported list only as version 15, so confirm with EspoCRM whether a newer PostgreSQL release is covered before you plan around it. PostgreSQL 15 is listed as supported through November 11, 2027, and PostgreSQL's own documentation covers logical replication for major upgrades and hot standby with synchronous or asynchronous replication. Automatic failover is not built in, so you must add external tooling and test it. Ask your team who will own that tooling, how they will test failover against EspoCRM's background jobs, and whether PgBouncer or an equivalent pooler fits your connection pattern.
MariaDB, MySQL and PostgreSQL side by side for EspoCRM
This table compares the three databases EspoCRM documents for its server, factor by factor, from documented versions and the install script path to licensing, replication, authentication and deployment effort. Read it as a checklist: the rows that matter most are the install script path and your team's existing database skills, because they decide how much custom work you take on.
| Factor | MariaDB or MySQL | PostgreSQL |
|---|---|---|
| Documented EspoCRM support | MySQL 8.0 or later and MariaDB 10.6 or later are supported | PostgreSQL 15 is supported |
| Install script path | The Ubuntu, Debian and Linux Mint script deploys Nginx and MariaDB in Docker | Not covered by the script; choosing it means a manual or custom deployment |
| License | MariaDB Server is GPLv2; MySQL licensing is a separate question to confirm with Oracle | PostgreSQL License, a permissive license similar to BSD or MIT |
| Supported version windows | MariaDB 11.8, 11.4 and 10.11 are maintained LTS lines; confirm the EspoCRM-tested versions before choosing | PostgreSQL 15 is supported to November 11, 2027; 16 to 2028 and 17 to 2029 |
| Replication and failover | Asynchronous, semi-synchronous and parallel replication, plus Galera multi-primary clustering | Hot standbys with synchronous or asynchronous replication; automatic failover needs external tools |
| Authentication methods | Pluggable authentication including ed25519, PAM and GSSAPI; TLS and data-at-rest encryption | Password, SCRAM, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth |
| Effort to deploy | Lowest if you accept the documented default; the script handles backups and upgrades | Higher: you build the stack, backups, replication and failover yourself |
What the EspoCRM install script assumes about your database
The EspoCRM installation script for Ubuntu, Debian and Linux Mint makes the database decision for you. It deploys a Docker-based stack with Nginx and MariaDB, optionally adds Let's Encrypt certificates, and installs a command.sh utility that handles backups, restores and upgrades. If MariaDB inside that stack fits your standards, the script removes most of the setup work. If your organization requires PostgreSQL, the script is not the path. You would build the web server, PHP runtime, database and scheduled jobs yourself, and the script's backup and upgrade tooling would no longer match your layout. Confirm the target operating system is one the script supports before you plan around it, and read the EspoCRM installation by script guide for the exact components it installs.
A PostgreSQL deployment is a manual or custom deployment, and the EspoCRM server configuration documentation lists Apache, Nginx or IIS as the web servers. EspoCRM also requires cron or a scheduled task to run background jobs, which the script sets up for you but a custom build does not. The same documentation says the default database settings work fine with no special requirements, so you should not expect to tune the database to get EspoCRM running. Check that your hosts run PostgreSQL 15 or later, the version the server configuration documentation lists, and that your PHP runtime is within the 8.3 to 8.5 range.
Before choosing, ask your platform team who will own each piece the script normally handles: web server hardening, certificate renewal, scheduled jobs, backup scheduling and restore testing. Ask whether your existing backup tooling can capture the database and the EspoCRM file tree together so a restore returns both to the same point. A custom build also means you own every upgrade step that the command.sh utility would otherwise perform, so ask for a written runbook as part of any implementation quote.
Four factors that should decide the database
EspoCRM supports MySQL, MariaDB and PostgreSQL, so the database choice is mostly an operations decision. The four cards below cover the people, tooling and calendar that will carry the database for the life of the CRM, and each names who on the team has to answer.
Existing database skills and on-call
Start with the people who will be paged at 2 a.m. when the CRM stops responding. Database administrators, platform engineers and the on-call rota should be asked which engine they already run in production and can troubleshoot without vendor help. EspoCRM's install script deploys MariaDB, so a team with MariaDB experience inherits a tested path. A team that runs mainly PostgreSQL should ask whether a manual deployment with PostgreSQL 15 fits its runbooks, and who will own that custom setup after the first install.
Backup and restore tooling in place
Check what your organization already uses to back up and restore databases, and whether it covers the engine you pick. The EspoCRM install script ships a command.sh utility for backups, restores and upgrades, which helps only if your retention and off-host copy rules accept it. On the PostgreSQL side, ask whether your team already uses continuous archiving and point-in-time recovery, since that is the approach the PostgreSQL documentation describes for this need. Test a restore to a clean host before you rely on either path.
High availability requirements and tooling
Decide how much downtime the CRM can tolerate before you compare replication designs. MariaDB offers asynchronous, semi-synchronous and parallel replication, plus Galera synchronous multi-primary clustering. PostgreSQL offers hot standby servers with synchronous or asynchronous streaming replication, but it does not detect a failed primary or promote a standby on its own, so automatic failover needs an external tool. Ask your platform team which failover tool it will run and who tests it. A PgBouncer layer may also be needed for connection pooling, and that adds one more component to operate.
Upgrade planning against support windows
Plan the upgrade calendar before go-live, because each engine ages on its own schedule. PostgreSQL 14 is supported to November 12, 2026, so a deployment starting now on 14 would need a major upgrade soon. PostgreSQL 18 is supported until November 14, 2030. MariaDB publishes long-term releases yearly with community support for 3 years, and rolling releases end sooner. Ask the platform owner which engine version the CRM will run on, who approves major upgrades, and whether a rehearsal on a copy of the data is part of the change process.
How replication, failover and backups differ
The database you pick determines which high availability design you can build around EspoCRM, and the two families work differently. MariaDB offers asynchronous, semi-synchronous and parallel replication with global transaction IDs, which makes it straightforward to position a replica and promote it by transaction position. For multi-primary writes, the MariaDB Server README describes Galera synchronous multi-primary clustering as a separate option. PostgreSQL offers hot standby servers that answer read-only queries, plus synchronous replication, where a commit waits for standbys, and asynchronous replication. The critical difference is that PostgreSQL does not detect a failed primary or promote a standby on its own, so automatic failover depends on external tooling that you must select, deploy and test.
Recovery planning also differs by database. PostgreSQL supports point-in-time recovery through continuous archiving of WAL, which lets you restore to a moment before a bad change, such as a mass record update or a faulty import. Confirm which backup and archiving tool your team will run, where the archives live, and how often a restore is rehearsed. On the MariaDB side, confirm the equivalent binary log retention and backup tooling your DBA already uses. Connection handling matters too: PgBouncer is a connection pooler to evaluate if PostgreSQL connection counts grow under EspoCRM's PHP workers, but test it against the EspoCRM version you run before adopting it.
Treat the HA design as something to verify, not assume. Confirm with the EspoCRM documentation and your own test environment how the application behaves during a failover: whether sessions survive a promotion, whether background jobs run on the primary only, how cron or scheduled tasks reconnect after a switch, and whether read-only standbys can serve any EspoCRM traffic at all. Run a scripted failover drill against a staging copy with realistic data volumes, and record the time to recovery and any lost transactions. Those results, not the database feature list, should decide between a replicated MariaDB design and a PostgreSQL design with external failover tooling.
How database upgrades differ in practice
This sequence takes the database under EspoCRM from its current version to a supported target with a tested backup, a rehearsed restore and a documented rollback path. It treats minor and major upgrades as separate work, because the two engines handle them differently.
Confirm the EspoCRM and database versions
Before touching the database, the team checks the EspoCRM release it runs against the server configuration page, which lists PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15. Whoever owns the EspoCRM instance records the current EspoCRM version, the current engine and its exact minor version, and the target engine version. The step is done when the target pair appears on EspoCRM's supported list. If the target is not on that list, the team picks a different target or waits for an EspoCRM release that supports it.
Back up and rehearse the restore
The database administrator takes a full logical backup and confirms the EspoCRM data directory and uploads are included in the backup set. A restore is then rehearsed on a separate host with the same engine and version, and the team checks that EspoCRM starts and that a sample of records, users and attachments matches the source. The step is complete when a restore has succeeded on a non-production host and the team has written down the restore time it observed. Without this rehearsal, there is no tested fallback for the later steps.
Apply minor updates by replacing executables
For PostgreSQL, a minor update replaces the server executables and restarts the service, since minor releases do not change the internal storage format. The database administrator runs this on a staging copy first, then in production during an agreed change window. For MariaDB, the team moves within the same LTS line, such as 11.8 to a later 11.8 point release, following the MariaDB Foundation's release announcements. The step is done when the server reports the new minor version, EspoCRM loads its login page and a test record can be read and written.
Choose the MariaDB LTS line for major moves
On MariaDB, the team selects a long-term release line before any major move. According to the MariaDB Foundation, 12.3 is an LTS release with a GA date of May 28, 2026, and 11.8, 11.4 and 10.11 remain maintained LTS lines. Community binaries are supported for 3 years after GA, with critical and security fixes for 2 more years. The team confirms that the chosen line is on EspoCRM's supported list and that its own support window covers the planned operating period. The step is complete when the target version and its end-of-support date are written into the change record.
Run the major upgrade with a method chosen in advance
For a major PostgreSQL upgrade, the team picks one method before the change window: pg_dumpall with restore, pg_upgrade, or logical replication. Logical replication works across major versions and, according to PostgreSQL's upgrade documentation, allows a major upgrade with only several seconds of downtime, but it requires its own setup and validation. The MariaDB equivalent is a dump, restore and in-place check against the new LTS line. The step is done when the new major version is serving EspoCRM and the team has compared row counts and key tables against the backup.
Validate EspoCRM after the database change
After the database engine changes, the operator runs EspoCRM's own checks, confirms that scheduled jobs run through cron or the scheduled task, and tests login, a report, a workflow and an attachment download. Any extension that depends on database behavior, such as a paid extension in use, is tested in the same pass. Operators also confirm that backups still run and restore against the new version. The step is complete when the test list is signed off and the backup job has produced a restorable copy from the new engine.
Document the rollback and the next review date
The team records the rollback path, which is restoring the pre-upgrade backup onto the old engine version, along with the time it was rehearsed and the owner who would execute it. It also notes the engine's support end date so the next upgrade is scheduled before support ends. For PostgreSQL, the team uses the versioning policy to track each major version's end date, and for MariaDB, it uses the LTS dates above. The step is done when the runbook is stored with the EspoCRM configuration and a review date is on the team calendar.
Which database fits which team
If your team already operates MySQL or MariaDB, the lowest-friction path is usually to stay on that engine. EspoCRM's server configuration documentation lists MySQL 8.0 or later and MariaDB 10.6 or later as supported, and says the default database settings work with no special requirements. The EspoCRM installation script for Ubuntu, Debian and Linux Mint deploys a Docker-based stack with Nginx and MariaDB, so a team that wants the supported path with the least custom work starts there.
- Install script fit: The script's bundled MariaDB is the configuration the installer assumes, along with its
command.shutility for backups, restores and upgrades. - Existing runbooks: Backup, monitoring and patching procedures your team already trusts carry over directly.
- Replication options: MariaDB offers asynchronous, semi-synchronous and parallel replication with global transaction IDs, plus Galera multi-primary clustering, if you need them.
- Version choice: Check which MariaDB line you will run, since long-term and rolling releases follow different support windows.
- Engine settings: Confirm the InnoDB and character set settings EspoCRM expects against your own standards.
Confirm first whether your MariaDB or MySQL version sits inside the EspoCRM 10.0 support matrix and whether your backup tooling already covers the installer's Docker volumes.
If your team already runs PostgreSQL 15 or later with high availability tooling, PostgreSQL is a reasonable choice for EspoCRM, provided you accept a custom deployment. The installation script does not deploy PostgreSQL, so you build the web tier, PHP runtime and cron job yourself. PostgreSQL 15 is on the supported list, and PostgreSQL 15 is supported until November 11, 2027, while newer majors such as 17 and 18 have later end dates.
- Custom deployment: Plan the web server, PHP 8.3 to 8.5 runtime and scheduled cron jobs for background work by hand.
- Major upgrades: Logical replication lets you move between major versions with only several seconds of downtime, which suits a CRM with business-hours users.
- Replication and failover: Hot standbys serve read-only queries, and synchronous or asynchronous replication is available, but automatic failover needs external tools.
- Backups: Continuous archiving and point-in-time recovery are documented, so confirm your archive tooling covers the EspoCRM database.
- Connection pooling: PgBouncer can manage connections if your PHP workers grow.
Confirm first whether your team can own the EspoCRM upgrade path, since the script's command.sh utility will not handle a PostgreSQL deployment for you.
If the same database server must also serve vector search or Oracle-style stored routines for other applications, MariaDB's feature set deserves a close look. The MariaDB Server README lists a native VECTOR data type with HNSW indexing since MariaDB 11.8, along with an Oracle SQL mode that supports PL/SQL-style stored routines. PostgreSQL's strengths for shared workloads are different, including extension support and the 18 release's asynchronous I/O and OAuth authentication, but those features are not EspoCRM requirements.
- Vector workloads: MariaDB 11.8 and later list native vector storage, which matters only if another system on the same server needs it.
- Oracle migrations: The Oracle SQL mode helps when stored routines are being ported to an open engine.
- Storage engines: MariaDB lists InnoDB, Aria, MyRocks, ColumnStore, Spider and S3, so confirm which engine each workload uses.
- Shared upgrades: A shared server means one upgrade window affects every application, so schedule them together.
- Licensing: MariaDB Server is GPLv2 according to the MariaDB Foundation, which you should confirm against your own policies.
Confirm first which applications share the server, their version needs and whether EspoCRM's installed MariaDB or your existing instance will host the CRM schema.
If your organization has no database standard, the decision should favor the path with the most published support and the fewest custom steps. The EspoCRM installation script provisions MariaDB with Nginx in one pass, which gives a new team a documented baseline. Choosing PostgreSQL is still supported, but it turns the install into a manual project, so the decision should rest on whether your organization will adopt PostgreSQL more broadly.
- Default path: The script-based MariaDB stack is the configuration the installer assumes and is the simplest starting point.
- Strategic standard: If your wider estate already standardizes on PostgreSQL, the extra build work may pay back across other systems.
- Support windows: Compare the PostgreSQL support end dates for your chosen major against MariaDB's long-term and rolling release schedule.
- Skill hiring: Consider which engine your operators can staff and train for over the next several years.
- Exit cost: Moving a CRM database later requires a migration, so choose the engine you expect to keep.
Confirm first whether your organization has an engine standard in another policy, and whether a DeployOpen scope would cover the custom PostgreSQL deployment if you choose it.
Common questions about running EspoCRM on MariaDB or PostgreSQL
Does EspoCRM support PostgreSQL, and how much extra effort is it?
Yes. EspoCRM's server configuration documentation lists PostgreSQL 15 as a supported database, alongside MySQL 8.0 or later and MariaDB 10.6 or later. The extra effort comes from the installation path. The installation script for Ubuntu, Debian and Linux Mint deploys a Docker-based stack with Nginx and MariaDB, so PostgreSQL means a manual or custom deployment. You configure the web server, PHP, the database, cron for background jobs, TLS, backups and upgrades yourself. That work recurs with every EspoCRM release and every PostgreSQL minor and major release, so plan for ongoing ownership, not only the first install.
How long does a manual PostgreSQL deployment of EspoCRM take?
No supplied source gives a duration for a manual EspoCRM deployment on PostgreSQL, so confirm the timeline with the vendor or in a written quote before you plan around one. The drivers are the number of users and environments (test, staging and production), whether you need OIDC or LDAP sign-in, how much custom entity, workflow and integration work is in scope, and whether existing data must be migrated. Hardening, backup testing and documentation also add time, as does any high availability design. One fixed date to keep in mind is that PostgreSQL 15 is supported until November 11, 2027, so the build should include an upgrade path.
What skills does a team need to run EspoCRM on PostgreSQL?
The team needs working knowledge of the stack it will own once the build is done. In practice that means:
- Linux server administration, including service management, TLS certificates and scheduled jobs.
- PHP web hosting on Apache, Nginx or IIS, with the PHP versions EspoCRM supports.
- PostgreSQL administration: roles, authentication, backups, point-in-time recovery and version upgrades.
- Release management for EspoCRM itself, including testing extensions and custom formulas before each upgrade.
If the team already runs PostgreSQL for other systems, the database part is familiar. The EspoCRM-specific parts, such as cron and upgrade steps, still need an owner and a runbook.
Can we move EspoCRM from MariaDB to PostgreSQL later?
The supplied sources do not describe a supported conversion path between MariaDB and PostgreSQL for EspoCRM, so confirm the approach with EspoCRM before you commit. Treat any move as a planned migration: copy the production data into a test instance, rehearse the cutover, check custom fields, formulas and attachments, and keep a tested rollback. Ask for the expected effort in writing, since it depends on data volume, the number of custom entities and how many integrations read the database directly. Moving the other way follows the same pattern, so decide early which database you want to keep for the long term.
Which high availability setup should we choose for EspoCRM's database?
Choose by recovery target and team skill, then confirm that EspoCRM works with that topology. PostgreSQL supports hot standby servers that serve read-only queries, plus synchronous and asynchronous replication. It does not detect a primary failure or notify the standby by itself, so automatic failover needs external tools. MariaDB offers asynchronous, semi-synchronous and parallel replication with global transaction IDs, plus Galera synchronous multi-primary clustering. Whichever you pick, test failover under load, decide how the application reconnects, and confirm with EspoCRM that the chosen design is supported. Connection pooling with PgBouncer is a separate decision you should test as well.
Can our team run EspoCRM on PostgreSQL without outside help?
Often yes, if the team already has Linux, PHP hosting and PostgreSQL skills and can keep a runbook current. The deciding factor is capacity over time, not the first install. The installation script handles the Docker, Nginx and MariaDB path, and its command.sh utility covers backups, restores and upgrades for that stack. Confirm whether an equivalent utility or procedure is available for your custom PostgreSQL build, because it will not exist unless you create it. Ask a skilled internal engineer to rehearse a restore and an upgrade on a copy before you rely on the setup.
What does a DeployOpen scope cover for an EspoCRM database build?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For this decision, a scope could cover the PostgreSQL or MariaDB build, backup and restore design, the chosen high availability approach, upgrade planning and runbooks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and testing are available as retainers. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or certification. Quotes follow from the written scope.
How DeployOpen scopes and delivers an EspoCRM database decision
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the database choice for EspoCRM is worked out against your cloud accounts, data center or air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory existing MySQL, MariaDB and PostgreSQL skills, hosting standards and backup tooling before recommending a database.
- Confirm the EspoCRM version line, PHP version and web server against the server configuration documentation.
- Write down whether the install uses the Docker-based script or a manual deployment, and why, in the written scope.
How we build
- Deploy a test instance on the chosen database and run EspoCRM cron jobs, backups and restores against it.
- Test upgrades and the database migration path in a non-production environment before any cutover is planned.
- Configure replication or standby design only where your recovery objectives require it, and test failover with your own tools.
How we hand over
- Document the database version, connection settings, backup schedule and restore steps for your operations team.
- Record the reasons behind the database decision so future upgrades and audits can trace it to the agreed scope.
- Walk through restore and upgrade runbooks with your administrators and confirm they can run them unaided.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped separately from the project.
- Retainer scope can cover database minor updates, EspoCRM release upgrades and periodic restore tests in your environment.
- Ask any quote to state which items are one-time work and which recur, so you can compare options on total ownership.
