When a midPoint native repository fits and when the generic repository still does
The native repository fits teams that already run PostgreSQL as their database standard, and the generic repository still suits existing midPoint installs that cannot yet move. The native repository supports only PostgreSQL, so the first deciding condition is your database standard: if PostgreSQL is already the platform your operations team patches, backs up and monitors, the native option matches your existing skills. The second is your appetite for a migration project. Moving an installation means checking that object OIDs are valid UUIDs and following Evolveum's migration guide, which is work you schedule and test rather than a switch you flip. Before deciding, confirm with Evolveum whether the generic repository is still supported on your release line, since that determines how long you can wait.
If your estate runs another database, the generic repository is the practical option for now, and the native repository is not a choice you can make until you change that standard. Do not treat a database migration and a repository migration as one decision. A team moving off another database to PostgreSQL has two changes to plan at once, and the sequencing should be agreed in writing with your implementation partner before work starts. Ask Evolveum for the supported database list for your exact midPoint version, because a version that appears on a roadmap is not the same as one you can deploy today.
Plan the migration around your OID and extension data, not only the database engine. Inventory any objects whose OIDs are not UUIDs, review custom extensions that will land in JSONB columns, and confirm that your backup and restore routine covers the target PostgreSQL version. A test environment restored from a recent production backup is the fastest way to find problems before a change window. Ask your implementer to state what is in scope, what testing is included and what rollback looks like, so the cost and risk of the move are visible before you commit.
How the native and generic repositories differ on the factors that matter
This table sets the native PostgreSQL repository, introduced in midPoint 4.4, against the older generic repository on the factors that affect a migration decision. Where a generic repository detail is not in our supplied research, the cell tells you what to confirm with Evolveum for your release, so check those rows against your own version before you plan. The main takeaway is that the native repository trades database choice for a PostgreSQL-specific design.
| Factor | Native repository | Generic repository |
|---|---|---|
| Database support | PostgreSQL only | Confirm with Evolveum in the docs for your release |
| ORM use | Does not use Hibernate ORM | Confirm with Evolveum in the docs for your release |
| Storage format | Serialized objects stored as JSON by default, extensions in JSONB columns | Confirm with Evolveum in the docs for your release |
| OID requirements | Object OIDs must be valid UUIDs | Confirm with Evolveum in the docs for your release whether UUID OIDs are required |
| Migration path | Evolveum publishes a separate migration guide | Confirm the supported path to the native repository in the migration guide for your version |
| Release availability | Available since midPoint 4.4, developed in 4.3 and 4.4 | Confirm which releases still support it, including 4.10 and 4.8 |
| PostgreSQL version alignment | Uses PostgreSQL features more fully, so plan PostgreSQL version support with your midPoint release | Confirm supported PostgreSQL and other database versions for your release |
| Day-to-day operating effort | One database engine to back up, patch and tune, ideally on a separate database server | Confirm operating and maintenance steps with Evolveum for your release |
What runs in each setup: midPoint nodes, the repository and PostgreSQL
Most of the midPoint runtime looks the same whichever repository you choose: nodes, load balancer, cache and scheduler. The repository choice mainly changes how objects are stored in PostgreSQL, so the database cards below deserve the closest review before an upgrade.
Multi-node midPoint behind a load balancer
Multi-node deployments place midPoint nodes behind a sticky HTTP load balancer, all sharing one central database. Cache invalidation between nodes runs over HTTPS. This layer stays the same under both repositories, so changing the repository does not change how you size or place the nodes. Check that your load balancer keeps sessions on one node and that node-to-node HTTPS works through your firewall rules before you cut over.
Quartz schedules distributed tasks
midPoint uses Quartz for distributed task scheduling across nodes. Scheduled reconciliation and other tasks depend on this coordination, not on the repository you pick. Test that a task runs once across a multi-node cluster and that it fails over cleanly when one node stops. Keep this check in your upgrade plan so a repository migration does not hide a scheduling regression.
PostgreSQL on a separate server
midPoint recommends running PostgreSQL ideally on a separate database server, and the native repository supports only PostgreSQL. Under the generic repository the database sits in the same role. Confirm with Evolveum which PostgreSQL version your midPoint release supports, and plan database capacity, backups and access control as a distinct workstream from the application servers.
Java 21 or 25 by release
The Java runtime depends on the midPoint release rather than the repository. Evolveum recommends Java 25 for 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. Upgrading the repository and upgrading the Java runtime are separate changes, so decide the order and test each one on its own before combining them in production.
PostgreSQL high availability limits
PostgreSQL supports hot standby servers for read-only queries, and both synchronous and asynchronous replication. It does not detect a failed primary or promote a standby on its own, so automatic failover needs external tools. Ask your team who owns that tooling, how fast a failover must complete, and whether a synchronous setup fits your write latency. These limits apply to either repository.
Where the repository choice applies
The repository is the card that changes. The native repository stores serialized objects as JSON and keeps extensions in JSONB columns, and it requires object OIDs to be valid UUIDs. The generic repository does not carry that requirement. Nodes, scheduling, Java and PostgreSQL high availability stay the same. Review the object OID and migration steps first, since they decide whether a move is practical for your data.
How JSONB storage changes what sits in your PostgreSQL database
The most visible change for a database administrator is the shape of the data. The native repository no longer uses Hibernate ORM, and it stores serialized midPoint objects as JSON by default, with extensions kept in JSONB columns. Rows therefore hold whole document-style representations of users, roles, organizations and other objects rather than values spread across many normalized tables. Before you plan storage, open a non-production instance after the migration and look at how the objects land in the tables. Confirm with Evolveum's native PostgreSQL repository documentation which tables and columns your midPoint version creates, and record that layout as the baseline for your backup and monitoring standards.
Because the object payload is one JSON document per object, backup size and restore time are driven by how much identity data you keep and how often objects change, not by a fixed table count. Measure the full database size before and after a migration rehearsal, and run a complete restore into a separate server, then start midPoint against it and confirm that objects and extensions read back correctly. Use restore testing as the acceptance criterion, not just a successful pg_restore exit code. If you rely on point-in-time recovery, confirm with your team how WAL volume changes after the move, since the PostgreSQL continuous archiving documentation describes the archiving mechanics you will need to size.
Reports, SQL views and scripts written against the generic repository tables need review, because the column layout they query is different. Any custom reporting that reads extension values should be rewritten against JSONB paths and tested with representative data. On PostgreSQL 18, the uuidv7() function and virtual generated columns are platform capabilities you may consider for indexing or derived values, but midPoint's own OID rules still require valid UUIDs, so confirm with Evolveum what is supported before you change anything on the midPoint side. Ask your DBA team to agree on which indexes and generated columns are owned by midPoint and which are local additions that must survive an upgrade.
Why object OIDs must be valid UUIDs and how to check yours
The native repository requires every object OID to be a valid UUID, so the first decision is whether your existing midPoint data already meets that rule. OIDs are the identifiers midPoint uses to reference users, roles, resources, tasks and other objects, and anything that stores or looks up those identifiers depends on them. Before you plan a migration, treat OID format as a data quality question with a known answer you can measure, not an assumption to test during cutover.
Inventory OIDs in three places. First, the repository itself: list object types and check whether each OID parses as a UUID. Second, the code and configuration around midPoint: scripts, expressions, custom connectors, reports, and external systems that write oid values into midPoint or keep midPoint OIDs as their own foreign keys. Third, the integrations that rely on stable identifiers, such as provisioning targets that store a midPoint OID in their own records. Anything found in the second and third places has to change along with the data, so record which systems hold references and who owns each one.
Evolveum's native PostgreSQL repository documentation is the place to confirm the exact rules and the handling of any identifiers that do not conform, and Evolveum publishes a separate migration guide for the move itself. Ask the vendor, or test on a copy, what happens to non-conforming OIDs before you commit to a date, because the answer determines whether you need a data clean-up window. Your inventory should end with a list of what must change, what can stay, and a named owner for each external reference.
Which repository path fits your situation
A new midPoint deployment on PostgreSQL is the simplest case for the native repository. There is no existing object store to convert, so the work centers on the database setup and on confirming that every object OID your build process creates is a valid UUID. Platform staff install midPoint on Linux or from Docker images, while a PostgreSQL DBA owns the database server, which midPoint recommends running on a separate server.
- Start on a supported PostgreSQL line. PostgreSQL 14 reaches end of support on November 12, 2026, so choose a later major version for a system meant to run for years.
- Check the OID source. Seeded objects, import scripts and connector configurations must generate UUID OIDs before the first load.
- Match Java to the midPoint line. midPoint recommends Java 25 for 4.11 and later and Java 21 for 4.10 and older.
- Set backups and recovery early. Archiving and point-in-time recovery are DBA tasks that should be tested before go-live.
Confirm with Evolveum which midPoint release line you will run and its support end date before you fix the PostgreSQL version.
If your existing generic repository already runs on PostgreSQL, the database is ready, and the decision is whether the migration effort is worth the gain. The work is a planned conversion of stored objects to the native model, with extensions moving into JSONB columns. Internal platform staff usually lead the project, with a DBA handling backup, restore points and performance checks.
- Inventory OIDs first. Find any objects whose OIDs are not valid UUIDs, because the native repository requires them.
- Follow Evolveum's migration guide. Use the guide for your exact release rather than working from memory of older versions.
- Rehearse on a production copy. Time the conversion on realistic data volumes and record the result before you schedule the change.
- Review custom reports and queries. Any SQL that reads the generic schema directly will need updating.
- Keep a rollback path. Take a verified backup and confirm how you would restore the generic repository if the conversion fails.
Ask Evolveum or a partner to estimate the migration scope for your data volume and extensions, and confirm which midPoint release the migration guide covers.
If your generic repository runs on a database other than PostgreSQL, the native repository is not an option on your current stack. The native repository supports only PostgreSQL, so the first decision is whether to keep the generic repository on its current database or to treat a database change as a separate project. Keeping the current setup means managing the lifecycle of that database and midPoint release line together.
- Confirm the supported databases. Check the documentation for your midPoint release to see which databases the generic repository supports.
- Track end-of-support dates. Record both the midPoint support end date and the end-of-life date of your database version, and plan the earlier one.
- Scope a database move separately. Moving to PostgreSQL is a second project with its own testing, data transfer and cutover, so budget it apart from the midPoint upgrade.
- Avoid mixing change streams. Do not run a midPoint upgrade and a database migration in the same change window.
- Document the current database runbook. Your DBA needs tested backup and restore steps for the existing platform.
Internal platform staff and your current database administrators own this path, and Evolveum can answer release-specific questions. Confirm the supported database list before you commit to any upgrade plan.
A multi-node midPoint estate sits behind a sticky HTTP load balancer and shares one central database. Nodes invalidate caches between each other over HTTPS and use Quartz for distributed task scheduling. Moving to the native repository changes the schema for every node at once, so the cutover is a coordinated change that platform staff, a PostgreSQL DBA and the support provider plan together.
- Plan a coordinated window. Stop or drain all nodes, run the conversion once against the shared database, then bring nodes back in a controlled order.
- Plan database high availability. PostgreSQL offers hot standby servers and synchronous or asynchronous replication, but it does not detect a failed primary. Automatic failover needs external tooling that your team must select, configure and test.
- Add connection pooling. PgBouncer can reduce connection pressure from many midPoint nodes, and its behavior should be tested with midPoint before production.
- Choose a support level. Evolveum offers Product Support with an 8x5 next-business-day or 24x7 SLA, so match the level to your operating hours.
- Write failover runbooks. Test node loss, database failover and restore together, not separately.
Confirm the support level, the failover tooling and the maintenance window with Evolveum and your DBA before the cutover date is set.
What moving to the native repository involves, step by step
This sequence takes a running midPoint deployment from the generic repository to the native PostgreSQL repository in a controlled way, with a tested rollback point at each stage. Each step ends with a check you can confirm before moving on.
Confirm the midPoint release line
Decide which midPoint line you will run after the move. Version 4.8 is the long-term support line, supported until October 17, 2028, while 4.10.5 is the current maintenance release supported until November 26, 2027. Version 4.11 is planned for October 21, 2026. If you are already on 4.8, staying there keeps the longest support window. Done when the target release is written into the change request with its end-of-support date, and your team has agreed whether a later upgrade is planned as a separate project.
Confirm the Java version for that release
Check the Java runtime against the target release. Evolveum recommends Java 25 for midPoint 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. Confirm the exact requirements in the system requirements page before you build the staging environment, because a runtime change is easier to isolate when the database is not changing at the same time. Done when the target JVM is installed on staging and the midPoint startup log reports it without warnings.
Check the PostgreSQL major version
Confirm that the PostgreSQL server you will use is on a supported major version. PostgreSQL 14 is supported until November 12, 2026, so a server on that line will need an upgrade within the migration window or soon after. Keep this check separate from the midPoint work: a PostgreSQL server upgrade has its own backup, test and rollback plan. Done when your database owner has written down the current major version, its end-of-support date and whether a server upgrade is needed before or after the repository move.
Verify object OIDs are valid UUIDs
The native repository requires every object OID to be a valid UUID, so review the object population before any conversion. Run a read-only inventory of users, roles, organizations, resources and other objects, and flag any OID that is not in UUID form. Evolveum's migration guide describes how to handle non-conforming OIDs, and you should follow it rather than editing identifiers by hand. Done when the inventory shows zero non-UUID OIDs or each exception has an approved remediation written in the migration plan.
Migrate in staging with Evolveum's guide
Run the full migration on a copy of production in a staging environment, following Evolveum's guide for moving to the native PostgreSQL repository. Record each command, the time it took in your own environment, any errors and the configuration changes you made, such as connection settings for the native repository. Use the staging run to test connectors, scheduled tasks and the admin interface against migrated data. Done when a complete staging migration finishes, midPoint starts cleanly on the native repository, and a documented set of reconciliation checks passes.
Rehearse the restore from backup
Restore a fresh backup into a separate environment and confirm that midPoint starts from the restored database. This tests whether the backup is usable, not just whether it exists. Include the midPoint configuration files, the PostgreSQL database and any custom files that midPoint depends on in the restore test. Done when the restored environment matches the expected object counts and your team has timed the restore in its own environment so the rollback window is known before cutover.
Take final backups and freeze changes
Before cutover, stop changes to identity data in the source system and take a fresh full backup of the generic repository database and the midPoint configuration. Store the backup in a location that the cutover window does not touch. Keep the source environment intact so you can return to it if verification fails. Done when the backup is confirmed readable, its checksum or equivalent is recorded in the change record, and the change freeze is communicated to the teams that create or modify accounts.
Cut over and verify the production system
Run the production migration using the steps you rehearsed in staging, then start midPoint and check it against the same reconciliation list used in staging. Confirm that provisioning tasks run, connectors reach their targets and the audit and task history look as expected. Keep the rollback procedure ready until the verification list is signed off. Done when the agreed checks pass, the business owner accepts the result in writing and the source database is retained for the period your change policy requires.
Upgrades, backups, monitoring and skills for each repository in production
This table compares how the native PostgreSQL repository and the generic repository differ in day-to-day operation: upgrades, backups, high availability, monitoring, in-house skills and vendor support. Read each row as a checklist of questions to put to Evolveum and to your own team before choosing a repository for production. The main takeaway is that the native repository's operating model rests on PostgreSQL tooling, while the generic repository's details must be confirmed against the Evolveum documentation for your release.
| Area | Native PostgreSQL repository | Generic repository |
|---|---|---|
| Upgrade path | midPoint 4.4 introduced the native repository. PostgreSQL major upgrades can use pg_dumpall and restore, pg_upgrade, or logical replication, and logical replication allows major upgrades with only several seconds of downtime. | Confirm the supported upgrade steps for your database and release in the Evolveum docs. Do not assume the PostgreSQL upgrade options above apply unchanged. |
| Backups and point-in-time recovery | Use PostgreSQL continuous archiving and point-in-time recovery on the database server that holds midPoint data. Backup and restore tests should cover the JSONB extension data as well as object tables. | Confirm the Evolveum-recommended backup method for the generic repository and whether it supports point-in-time recovery with your chosen database. |
| High availability | PostgreSQL offers hot standby, synchronous and asynchronous replication, but it does not detect primary failure. Automatic failover needs external tools that you select, deploy and test. | Confirm which database high availability patterns the generic repository supports and who documents them. The Evolveum docs are the reference for supported topologies. |
| Monitoring | Monitor the PostgreSQL server (replication lag, connections, storage) alongside midPoint nodes, cache invalidation and Quartz task scheduling in multi-node setups. | Confirm which repository-level metrics and logs midPoint exposes for the generic repository and how they differ from the native setup. |
| Skills needed in-house | PostgreSQL administration skills for backups, upgrades, replication and tuning, plus midPoint operations skills. Pooling tools such as PgBouncer may also need an owner. | Confirm the database and midPoint skills the generic repository requires, including any Hibernate-related troubleshooting, in the Evolveum documentation. |
| Migration effort | Moving to the native repository requires valid UUID object OIDs and follows Evolveum's separate migration guide. Plan a test migration and rollback path. | No migration is needed while you remain on the generic repository, but plan the effort if you later move to the native repository. |
| Vendor support | Evolveum Product Support subscriptions cover resolving product bugs with an 8x5 next-business-day or 24x7 SLA. Platform Subscriptions add feature development and roadmap influence. Evolveum publishes no prices on the support page, so request a written quote. | The same Evolveum support subscriptions apply, but confirm in writing that your repository type and release are covered by the SLA you select. |
What buyers ask before moving repositories
Do we have to move to the native repository?
No. The generic repository is the older option, and the supplied facts do not set a removal date for it, so confirm its status against the midPoint release notes for the line you run. Moving is a decision about the database you want to operate and the features you want to use. The native repository supports only PostgreSQL, does not use Hibernate ORM, stores serialized objects as JSON by default and keeps extensions in JSONB columns. If your estate already runs PostgreSQL and you plan to upgrade midPoint anyway, the move is easier to justify. If you run a different database and have no plan to change it, the case for moving is weaker. Check the midPoint documentation for your target version before you commit.
What drives the cost of moving midPoint to the native repository?
The main drivers are the number of objects and extensions, how much custom schema and connector configuration you carry, how many nodes sit behind your load balancer, and how much testing your change process requires. Object OIDs must be valid UUIDs under the native repository, so any non-conforming data needs to be identified and handled before cutover. Cost also depends on whether a database change accompanies the move, since the native repository is PostgreSQL only. Evolveum publishes a separate migration guide, and the effort it implies scales with the points above. Ask for an inventory of objects, custom extensions and connectors before anyone quotes effort.
Who gets paid for what when we migrate midPoint?
Three parties can carry the work, and the split should be written down before work starts. Your internal staff own the business rules, sign-off and production change windows. Evolveum sells subscriptions for support and offers professional services, and its FAQ says it funds development through subscriptions, training and professional services. A partner such as DeployOpen can plan, implement, test, document and support the migration inside your infrastructure under a fixed-scope written agreement. Confirm with each party which of these tasks they cover: schema and data preparation, database setup, the cutover runbook, testing, rollback rehearsal and post-cutover support. Subscriptions and retainers recur, while migration work is typically one-time.
Can our own team migrate midPoint without outside help?
Possibly, if your team already operates midPoint and PostgreSQL and has a tested change process. Your team should be able to explain the current repository configuration, run a full backup and restore, validate UUID-based OIDs and test connectors against a copy of production. Gaps usually appear in extension handling, in multi-node cache and scheduling behavior, and in PostgreSQL operations such as backups, point-in-time recovery and failover, which PostgreSQL does not automate on its own. If any of these are unfamiliar, a fixed-scope engagement can cover the gaps. Make the decision after a rehearsal in a non-production environment, not before.
How long does a midPoint repository migration take?
The supplied facts do not give a duration for a midPoint repository migration, so ask for one rather than assuming it. The timeline depends on data volume, the number of environments that must be rehearsed, the size of the outage window you accept, and how many cycles of testing your connectors need. A written scope should state the environments covered, the migration steps and their order, the test cases, who approves each gate, the cutover window and the post-cutover support period. Ask for the scope to name every deliverable, including the runbook and evidence of a successful rehearsal, so you can judge progress against it.
How do we roll back if the native repository migration fails?
Rollback needs a plan written before cutover, with a verified backup of the generic repository database and a tested restore path. PostgreSQL provides several tools for this, including logical dumps, continuous archiving and point-in-time recovery, which the PostgreSQL documentation describes. Confirm with Evolveum and your own change board which steps can be reversed cleanly after the first write to the new repository, and set a go or no-go point before that write. Rehearse the rollback at least once in a non-production environment and record the result. Ask any provider to show that rollback was tested, not only described.
How DeployOpen scopes a repository migration and supports it afterward
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For midPoint native repository vs generic repository, that means working from a written scope that covers the database, the object OIDs and the evidence the client needs before and after the move.
How we scope
- Inventory the current repository type, midPoint version and object count before agreeing any change in writing.
- Check that existing object OIDs are valid UUIDs, since the native repository requires them.
- Agree in writing whether the PostgreSQL server is shared or dedicated, and who owns it, before work starts.
How we build
- Plan the migration path in the client's own cloud account, data center or air-gapped network, following Evolveum's native repository migration guide.
- Run the migration in a non-production copy first and compare object counts, extensions and task behavior.
- Set up PostgreSQL backups and point-in-time recovery so a failed cutover can be rolled back.
How we hand over
- Document the final database layout, JSONB extension handling, connection settings and rollback steps for the client's operators.
- Walk the client's team through restore tests and the checks they should repeat after each midPoint upgrade.
- Deliver a written record of what changed, what was tested and what remains open at handover.
How we support
- Engagements are fixed-scope, so any follow-on work on upgrades or repository tuning is scoped separately in writing.
- Ongoing support, upgrades and continuous testing are available as a retainer if the client wants continuity after handover.
- Confirm your own support path with Evolveum's subscription tiers, since product bug fixes and feature work sit with the vendor.
