Should a new MISP deployment run on MISP on PostgreSQL?
For a new MISP deployment, PostgreSQL support is relevant and arrived in MISP 2.5.47, released on 17 September 2026. A team installing MISP now that has not yet chosen a database should compare PostgreSQL with MySQL or MariaDB before the first install, because the database is set during deployment and changing it later is a project in its own right. The decision matters most for organizations that already run PostgreSQL as a standard platform, want one database engine to back up, patch and monitor, or have staff who already operate PostgreSQL well. Teams that already run MySQL or MariaDB elsewhere face a narrower question: whether a second database engine is worth operating. This section and the rest of the page address that choice for new installs.
MISP 2.5 is the recommended version for new deployments, and MISP 2.4 is end of life with security fixes only. The project strongly advises against installing new 2.4 instances, so any new build should start on the 2.5 line whichever database you choose. Redis is a separate dependency, and it stays unchanged. MISP still uses Redis alongside the database, so Redis placement, memory sizing, persistence and access controls must be planned in the same way for a PostgreSQL build as for a MySQL or MariaDB build. Confirm the Redis requirements for your chosen 2.5 release in the MISP installation documentation before you size the host or write the deployment plan.
Choose a PostgreSQL major version that will still be supported for the expected life of the instance. PostgreSQL 14 is supported until November 12, 2026, and PostgreSQL 13 and earlier are no longer supported, so a version that is already near the end of its window should not be the starting point for a new system. Confirm which PostgreSQL versions the MISP 2.5 release notes and installer support before you commit to one. Also ask who will operate the database, how backups and point-in-time recovery will be tested, and whether your existing PostgreSQL tooling for monitoring and patching covers the MISP database without special handling.
Existing MySQL or MariaDB instances are not migrated by this change, so an organization already running MISP on those engines should treat its database as settled unless it plans a separate rebuild. The rest of this page covers what the PostgreSQL option means for new installs, how to weigh it against the database your team already runs, and the operational work that follows from the choice, including backups, upgrades and connection handling. Sibling pages on workflows, feeds, taxonomies and event streaming cover configuration choices that apply regardless of the database you select.
Database options for a new MISP install and when each fits
This table compares MySQL or MariaDB with PostgreSQL for a new MISP deployment across stack support, operator skills, and the PostgreSQL features that affect recovery and access. Read it as a checklist for your team's existing skills and recovery requirements. Existing MySQL or MariaDB instances stay on their current database, so the choice applies mainly to new installs.
| Factor | MySQL or MariaDB | PostgreSQL |
|---|---|---|
| Supported status in the MISP stack | The database MISP is built on, alongside Redis | Added with the database migration system in MISP 2.5.47 |
| Fit for teams with existing skills | Strongest fit where your team already runs these backups, replication and upgrades | Strongest fit where your team already operates PostgreSQL in production |
| Existing MISP instances | Stay on MySQL or MariaDB, as existing instances are not migrated to PostgreSQL | Applies to new installs; plan any move from another database as a separate project |
| Replication | Confirm the replication setup your MISP version supports and test failover | Hot standbys with synchronous or asynchronous replication; automatic failover needs external tools |
| Point-in-time recovery | Depends on your backup and binary log procedure; confirm it and test restores | Continuous archiving supports point-in-time recovery; test restores before go-live |
| Authentication methods | Confirm the account and TLS options available for your database version | Password, GSSAPI, LDAP, certificate, PAM and OAuth methods; MD5 passwords are deprecated in favor of SCRAM |
| Version support and upgrades | Confirm supported versions in the release notes for your MISP version | Versions 14 to 18 are listed as supported; confirm which versions your MISP release accepts |
What MISP on PostgreSQL changes in MISP 2.5.47 and later
MISP 2.5.47, released on 17 September 2026, introduced a new database migration system with PostgreSQL support. MISP 2.5.50 followed on 9 October 2026. For most teams, the practical effect is that PostgreSQL becomes an option for new deployments, while an instance already running on MySQL or MariaDB stays on that engine. The release does not migrate existing MySQL or MariaDB instances to PostgreSQL, so an upgrade to these versions should not be treated as a database change.
For an existing estate, the working assumption is that the current database remains in place. Plan upgrades within the MySQL or MariaDB configuration you already run, and keep your backup and restore procedures for that engine unchanged. Do not expect the MISP upgrade process to move events, attributes, sharing groups or feed data into PostgreSQL. If your roadmap includes PostgreSQL, treat it as a separate project with its own change window, rollback plan and validation steps.
Before any move, confirm several points with the MISP project in writing. Ask whether a supported migration path is planned, what it would cover and whether it would be documented for production instances. Ask which MISP 2.5 releases are validated on PostgreSQL, and whether the core platform, misp-modules, plugins such as OidcAuth, and PyMISP-based scripts have been tested against it. Also check whether any custom SQL, reporting queries or third-party connectors in your estate contain database-specific syntax that would need rework.
For a new deployment, the database choice carries a lifecycle question. PostgreSQL 14 is supported until 12 November 2026, 15 until 11 November 2027, 16 until 9 November 2028, 17 until 8 November 2029 and 18 until 14 November 2030, according to the PostgreSQL versioning policy. Choose a major version whose support window covers your planned MISP life, and confirm which PostgreSQL versions the project supports for the MISP release you intend to install. Minor PostgreSQL updates are applied separately from MISP upgrades.
Criteria for choosing a database for a new MISP deployment
Each card names one question to settle before you choose a database engine for a new MISP instance. Together they cover team capability, the PostgreSQL support calendar, recovery obligations, appetite for a newer code path and any existing estate the instance must join.
Existing database skills and tooling
Start with the people who will patch, tune and restore the database after go-live. Check whether your operations team already runs PostgreSQL in production, and whether they have monitoring, connection pooling and upgrade runbooks for it. Confirm which tools they use for schema changes and access control, and whether those tools already cover a second engine. An instance that only one engineer can maintain carries more risk than the engine choice itself, so count the skilled hours your team can spare after the build.
PostgreSQL version support window
PostgreSQL 14 is supported until November 12, 2026, 17 until November 8, 2029, and 18 until November 14, 2030. Choose a major version that will still receive minor releases for the planned life of the instance, and check the upgrade path before you commit. The PostgreSQL project releases minor updates at least every three months, and major upgrades can use pg_upgrade or logical replication. Confirm with the MISP project which PostgreSQL major versions your target MISP release supports.
Backup and recovery standards
Compare the recovery methods your organization already accepts with what PostgreSQL offers: logical dumps, base backups with WAL archiving for point-in-time recovery, or both. Confirm the recovery point and recovery time targets in your own policy, since the database holds the events, attributes and sharing configuration your analysts rely on. Check that your backup tooling can restore into a test environment, and that restores are rehearsed on the same schedule as backups. Record who holds access to the archive.
Appetite for a less common database
PostgreSQL support arrived in MISP 2.5.47, so the MySQL or MariaDB path has a longer history in the MISP stack. Ask whether your team accepts a newer code path and what testing your own environment will need before production use. Check which MISP features, plugins and modules you depend on, and confirm each one works on the PostgreSQL option in your target release. Plan for troubleshooting that relies on your own testing as much as on published examples.
Joining an existing MySQL or MariaDB estate
If the new instance must sit alongside existing MySQL or MariaDB servers, the database standard may settle the question before features do. Confirm whether that estate, its monitoring, backup jobs and on-call rota already cover the engine, and whether PostgreSQL would need separate hardware and runbooks. Check whether internal policy or a sharing partner requires a particular engine. Existing MySQL or MariaDB MISP instances are not migrated to PostgreSQL by this work, so this criterion applies to new installs.
Setting up MISP on PostgreSQL step by step
This sequence takes a new MISP instance from choosing an installation path to a tested backup, with a check at each step so the team confirms the database layer before loading any data. It applies to fresh deployments on MISP 2.5.47 or later, where PostgreSQL support was introduced.
Choose the installation path and confirm the version
The platform team selects one installation path from those the project lists: the installer on Ubuntu 24.04, Docker images, Ansible roles, or Puppet or RPM packages. Record the chosen path in your change record and confirm the release is MISP 2.5.47 or later, since that release introduced the new migration system and PostgreSQL support. These steps cover new installs only, so existing MySQL or MariaDB instances stay on their current database. Check: once the instance is running, the administration pages report version 2.5.47 or later. Exact commands must come from the MISP installation documentation for the chosen method.
Provision a supported PostgreSQL major version
The database team provisions a PostgreSQL major version that is still within its support window. The PostgreSQL versioning policy lists versions 14 through 18 as supported, and version 14 is scheduled to reach end of support on November 12, 2026, so choose the newest version that your MISP release and operating system packages accept, and confirm that against the MISP documentation. Plan the future upgrade path now, since major upgrades use dump and restore, pg_upgrade or logical replication. Create a dedicated database and role for MISP with only the privileges the installer requires. Check: a client session reports a supported major version, and the MISP role can connect to its own database.
Set password authentication to SCRAM
The database team sets the authentication method for the MISP role and its connection path to SCRAM-SHA-256, and removes any MD5 entries from the host-based authentication file. PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM, and the client authentication documentation describes the other available methods if your organization uses LDAP, certificates or another approach. Enable TLS on the connection when the database and MISP run on separate hosts. Check: the stored password type for the MISP role shows SCRAM, a login with the wrong password fails, and a login with the correct password succeeds.
Point MISP at PostgreSQL before first start
The platform engineer sets the database connection values in MISP's configuration so the application connects to the new PostgreSQL server. Set the host, port, database name, user and password to match the values created in the earlier step. Keep the password in your secrets store and reference it from configuration, so it never appears in plain text in shared files or version control. Check: the diagnostics page in the MISP administration interface reports a working database connection, and the application log shows no connection errors after startup. The exact configuration keys come from the installation documentation for the chosen method.
Run migrations and confirm the schema
The platform engineer runs the database migrations using the command in the installation documentation for the chosen method. The migration system built into MISP 2.5.47 and later applies schema changes in order and records each one, so the team can see exactly what ran. Review the output for errors, and re-run migrations only after the cause of any error is fixed. Check: the migration status output lists every migration as applied, the schema matches what the release documentation describes, and the default administrator account can log in to the web interface.
Verify Redis connectivity and background jobs
The platform engineer confirms that MISP can reach its Redis service from both the web application host and the worker processes, using the connection settings in the installation documentation. MISP uses Redis alongside the database, so a service that responds to the web process but not to the workers will show up as failed or stalled background work. Confirm that the worker processes start and that a test job queued from the administration interface completes. Check: a Redis ping from each host returns a successful reply, and the test job finishes without errors in the logs.
Test backup and restore before go-live
The database team configures backups for the MISP database, then restores a copy to a separate server and starts MISP against it. Where recovery objectives require point-in-time recovery, use continuous archiving as described in the PostgreSQL documentation, and confirm the archive settings before relying on them. Record how long the restore took and the exact steps used, so the runbook matches what was done. Check: the restored database opens, MISP starts against it, and a sample event created before the backup is present and unchanged. Go-live should wait until this check passes.
Which PostgreSQL operations features MISP teams must plan for
Before a MISP team chooses PostgreSQL, it should plan five operations features: replication, failover, continuous archiving, connection pooling and major version upgrades. MISP added PostgreSQL support in release 2.5.47, so the team should confirm for its chosen MISP version which of these setups the platform supports, and how. Build the design around what PostgreSQL provides, then check each element against the MISP release notes and documentation.
PostgreSQL supports hot standby servers that answer read-only queries, and it offers two replication modes. With synchronous replication, a commit waits for one or more standbys to confirm it, which limits data loss on failure but adds write latency and makes the primary sensitive to standby availability. With asynchronous replication, the primary does not wait, so the standby may lag and recent events could be lost during a failover. Decide which trade-off your sharing workflows can accept, and confirm whether MISP sends any reads to a standby or whether all traffic goes to the primary.
PostgreSQL does not detect a primary failure or notify a standby on its own, so automatic failover depends on external tools. Your team must choose the cluster manager, define how it decides the primary is down, and prevent a former primary from accepting writes after promotion. Also decide how MISP finds the new primary, for example through a virtual address or a connection endpoint that the failover tool updates. Test the whole sequence in a non-production environment, because MISP may hold connections or caches that need a clean restart.
Continuous archiving and point-in-time recovery depend on a base backup plus archived write-ahead log segments, which allow restoration to a chosen moment before an error or intrusion. Your team should schedule base backups, define archive retention, and record how long a restore takes. MISP keeps data outside PostgreSQL, including attachments and Redis state, so a restore plan must cover those stores together. Run a restore to a separate host on a regular schedule and confirm that the MISP instance comes up and its events are intact.
Connection pooling with PgBouncer reduces the number of direct connections PostgreSQL must handle, but the pool mode affects which session features survive. Confirm with MISP for your version whether it relies on session-level state that conflicts with transaction pooling. For upgrades, a minor release replaces executables and needs a restart, while a major release needs one of three paths: pg_dumpall and restore, pg_upgrade, or logical replication, which the PostgreSQL documentation describes as requiring only several seconds of downtime. PostgreSQL 14 is supported until November 12, 2026, so plan the target major version and confirm MISP support for it before scheduling.
Security and operational considerations for the database layer
The database layer holds every MISP event, attribute, sharing group and user record, so its controls shape how far shared threat intelligence can travel. The cards below cover credentials, transport security, authentication, network placement, backups and logging. Treat them as one set, because each control protects the same data wherever it lives, including copies made for recovery.
Database credential handling
Give MISP its own PostgreSQL role with rights limited to the MISP database, and keep its password out of configuration files committed to version control. Store the secret in a vault or the host's secret manager, and rotate it on a schedule your team can run reliably. Separate the migration account from the application account, so routine MISP operation does not need schema-change rights. Confirm that the MISP configuration file is readable only by the web service user and that administrators sign in with named accounts instead of shared database logins.
TLS and certificate client access
Require TLS for every connection from MISP and administrators to PostgreSQL, and configure the server to reject plaintext connections for the MISP role in pg_hba.conf. Where your policy calls for it, use client certificates so the database identifies the MISP host through its certificate, in addition to the password. Plan certificate issuance, renewal and revocation before go-live, because an expired certificate stops the application. Confirm the certificate authority, key storage and verification mode supported by your MISP build and PostgreSQL driver.
Use SCRAM password authentication
Set password_encryption to scram-sha-256 and use the scram-sha-256 method in pg_hba.conf for the MISP role. PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM, so new clusters should not carry MD5 authentication forward. Roles created in earlier installs may still hold MD5-hashed passwords, so reset those passwords after the change and check the stored hash type in the role catalog. Verify that your MISP and driver versions support the SCRAM handshake before you enforce it.
Network isolation for the data tier
MISP, its Redis instance and PostgreSQL should sit on separate network segments with explicit rules between them. Allow PostgreSQL only from the MISP application hosts and administrative jump hosts, and allow Redis only from the MISP web and worker hosts. Bind each service to the specific interface it needs, and keep the database port out of any segment that carries user traffic. Review these rules after every change to hosts or load balancers, because one broad rule can expose the whole data tier.
Backups under sharing controls
Threat intelligence is often shared under TLP and distribution rules, so database backups and archived WAL segments must carry the same sharing controls as the events they contain. Encrypt backups at rest and in transit, keep decryption keys in custody separate from the backup store, and limit restore rights to named roles. Point-in-time recovery depends on archive storage you control, so confirm who can read archived segments. Test restores in an isolated environment and verify that restored copies keep the original access restrictions.
Audit logging of admin changes
Record who changed MISP administrative settings, sharing groups, users, feeds and roles, and who ran schema or database maintenance. Combine MISP's own audit records with PostgreSQL logging for role changes, DDL statements and failed logins, then forward both to a central log system with restricted access. Confirm which MISP actions produce audit entries in your release, since coverage varies by feature and version. Align log retention with your sharing and incident records, and check that the logs do not expose event content.
Limits to confirm before you commit to PostgreSQL
Start by confirming that the features you depend on work on PostgreSQL in the MISP version you plan to run. That means your core workflows, the misp-modules expansion, import and export modules, plugins such as OidcAuth for single sign-on, and every synchronization path to partner instances or trusted communities. The public release notes and the facts available to this page do not list every limit, so a feature that is not called out as unsupported is not thereby confirmed. Ask the project and your partner for written confirmation covering your exact release, and test each feature on a non-production instance built on PostgreSQL before you rely on it. Record the results against the feature list you wrote during planning.
Next, confirm the upgrade path. MISP 2.4 is end of life, and the project strongly advises against installing new 2.4 instances, so an existing 2.4 deployment will need to move to 2.5 before any database decision applies. Check the current upgrade documentation for whether it covers a move from MySQL or MariaDB to PostgreSQL on your path, starting from 2.4 or an earlier 2.5 release. MISP 2.5.47 introduced a new database migration system with PostgreSQL support, and that mechanism is the part to examine closely. If the documentation does not cover your path, treat the existing database as the source for a planned data transfer, and rehearse that transfer on a copy of production with a documented rollback.
Then inventory anything that reads the MISP database directly. SIEM connectors, exporters, reporting queries, dashboards and custom scripts that issue SQL against MISP tables may assume MySQL or MariaDB behavior, including syntax, data types, collation and the database driver they use. Consumers that work through the API, such as restSearch or the bundled PyMISP library, raise a separate question, and you should still confirm each endpoint and export format they call. For each consumer, record its owner, how it connects, whether it uses a read-only account, and what breaks when the connection settings change. Consumers you cannot find in the inventory are the most likely source of failure after cutover.
Finally, confirm the PostgreSQL major version that your support contract or internal policy requires. Your partner, your database administrators and the MISP project may each have a supported range, and those ranges may not match. PostgreSQL 14 is listed as supported until November 12, 2026, while 15 runs to November 11, 2027, 16 to November 9, 2028, 17 to November 8, 2029 and 18 to November 14, 2030. Ask which PostgreSQL versions the MISP release you choose is tested against, and whether that set includes the major version your policy requires. Minor updates do not change the storage format, but a later major upgrade needs its own procedure, so plan its effort and downtime before you commit.
Questions teams ask before choosing MISP on PostgreSQL
What drives the cost of a new MISP install on PostgreSQL?
Platform scope drives most of the cost, and the database engine is only one part of it. Scope includes the number of MISP instances, whether you need high availability, how many sharing communities and synchronization links you connect, which modules and integrations you enable, and how single sign-on is set up. The PostgreSQL work adds standards decisions, backup and point-in-time recovery design, and any replication or connection pooling you require. Most of the cost is one-time for design, build and handover. Upgrades, patching, restore testing and support recur. DeployOpen plans and quotes from a written scope agreed before work starts, so ask for costs by component, the assumptions behind each line, and which items are optional.
How long does a MISP PostgreSQL deployment take to complete?
The duration depends on the agreed scope, so a responsible timeline can only be given once that scope is written. The main variables are the number of environments (for example, a test and a production pair, illustrative), whether high availability is included, how much configuration of feeds, taxonomies and sharing groups is needed, and how quickly your team approves designs. Access requests, identity provider decisions, certificate issuance and security reviews often set the pace more than the build itself. Ask for a plan that lists each phase, its entry and exit criteria, and the client tasks each phase depends on. Also confirm which MISP release the plan targets, since PostgreSQL support arrived in 2.5.47 and the release line is still moving.
What does our team need to provide during the engagement?
Your team provides access, approvals and decisions. Access includes named administrator accounts for the cloud accounts, hypervisors or data center networks where MISP will run, plus DNS, certificate and identity provider details if single sign-on is in scope. Change windows are needed for cutover, restarts and backup verification. The decisions that most often need a named owner are the PostgreSQL major version, the replication mode (synchronous or asynchronous), backup retention, naming and schema ownership, connection pooling, TLS settings, and the password authentication method. PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM, so confirm your standard before the build starts. Name one person who can approve designs without waiting for a committee.
Can our internal team install MISP on PostgreSQL without a partner?
Yes, if your team has Linux administration skills, PostgreSQL operations experience and enough MISP knowledge to validate the configuration. The project lists an installer for Ubuntu 24.04 along with Docker images, Ansible roles, Puppet and RPM packages, so the first install is rarely the hard part. The harder work is operational: tested backups and point-in-time recovery, failover (PostgreSQL does not detect a failed primary or notify a standby, so external tools are needed), major version upgrades, and hardening. Ask whether you have on-call coverage, a restore process you have actually tested, and the time to maintain the system after go-live. A partner can add an independent design review, a runbook and a handover, which is useful if the internal team is small.
Can an existing MySQL or MariaDB MISP instance move to PostgreSQL?
Not through an in-place change. The PostgreSQL support added in MISP 2.5.47 applies to new installs, and the topic's researched position is that existing MySQL or MariaDB instances are not migrated to PostgreSQL by that release. Do not assume a migration tool exists. Confirm the current position with the MISP project and check the release notes before planning. The realistic options are to keep the existing database engine, or to build a new PostgreSQL instance and move the content you need, such as events, attributes, sharing groups, feeds, users and API keys, through an export and import process that you validate. Each option has trade-offs for correlations, synchronization links, audit history and integrations. Ask for a written assessment that lists exactly what moves and what is rebuilt.
How do PostgreSQL upgrades affect a MISP instance over time?
Minor PostgreSQL releases do not change the internal storage format, so they replace executables and require a restart. Major upgrades are different. The documented methods are dump and restore with pg_dumpall, pg_upgrade, or logical replication, and logical replication works across major versions with only several seconds of downtime. PostgreSQL 18 pg_upgrade keeps planner statistics and adds parallel jobs and a swap option. Support timing matters for planning. PostgreSQL 14 is supported until November 12, 2026, and PostgreSQL 18 is supported until November 14, 2030. Also check that your MISP release supports the PostgreSQL major version you choose, and test the upgrade on a copy of production before scheduling it.
Does DeployOpen support MISP after go-live, and how is it priced?
DeployOpen offers ongoing support, upgrades and continuous testing as retainers, separate from the fixed-scope build. A retainer covers the work agreed in writing for your environment, such as patching, upgrade planning, backup testing and incident help. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for the quote to separate the one-time build from recurring retainer items, list what each item includes and excludes, and state how changes after signing are handled. Confirm response expectations in writing before you sign. DeployOpen prepares systems, controls and evidence for compliance assessments, but auditors and certification bodies issue any audit report or certification.
How DeployOpen scopes and delivers a MISP PostgreSQL deployment
DeployOpen plans and builds MISP on PostgreSQL inside infrastructure you control, starting from a written scope. The work covers installation on MISP 2.5, database configuration, identity integration, testing and the runbooks your team needs after handover.
How we scope
- Confirm the instance is new, because existing MySQL or MariaDB installations fall outside this path.
- Record the MISP version target, with MISP 2.5.47 or later as the minimum for PostgreSQL support.
- Agree deliverables and acceptance criteria in writing before work starts; quotes follow from that scope.
How we build
- Build on Ubuntu 24.04 with the provided installer, or agree an alternative packaging method in scope.
- Configure PostgreSQL client authentication, including SCRAM password handling, and restrict database access to MISP hosts.
- Connect single sign-on through the OidcAuth plugin and map identity provider roles to MISP roles in a test environment first.
How we hand over
- Test MISP end to end on PostgreSQL, including synchronization, feeds, exports and API calls, before cutover.
- Document the database layout, backup and point-in-time recovery steps, and the restore test results.
- Deliver runbooks for upgrades, covering the PostgreSQL minor and major upgrade paths your team will follow.
How we support
- Plan failover with external tooling, since PostgreSQL does not detect primary failure or notify standbys on its own.
- Track PostgreSQL support end dates, from version 14 in November 2026 to version 18 in November 2030.
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, based on the written scope.
