Why a Nextcloud database migration should happen before production users arrive
Moving a pilot Nextcloud from SQLite to PostgreSQL or MariaDB is a database conversion, and it should be completed before people start relying on the instance for daily files, shares and sync. The documented path is the occ db:convert-type command, which copies the Nextcloud tables into a target database you have prepared, and it is planned around a maintenance window in which the instance is taken offline for the copy and the checks that follow. The effort is driven by four things: preparing the target database server, handling the tables that the conversion does not move, testing the converted instance against real workflows, and fitting the whole sequence into an agreed window. Each of these is larger on a production instance with many users, many shares and many enabled apps than on a pilot, so the cheapest time to do the work is while the data set is still small and the user base is still limited. Ask your team or a partner to estimate each stage against your own instance rather than relying on a general figure. The decision that matters most early is the target engine. PostgreSQL and MariaDB are both supported by Nextcloud 35, which recommends MariaDB 11.8 or PostgreSQL 18. Check the current system requirements for the Nextcloud version you intend to run, confirm which database versions are supported for it, and choose a version that will remain within vendor support for the life of the deployment. Your database team should also confirm backup tooling, replication needs and connection handling before the conversion, because changing those later means touching a database that already holds production data. Do not treat the migration as a technical afterthought. Before the window, agree on a rollback point, a verified backup of the SQLite data directory and database file, and a named owner who can approve the switch to the new database or return to SQLite. Users should be told when the instance will be unavailable and what they should do with sync clients during that time. Because the work touches live data and the target platform, it is fixed-scope. DeployOpen agrees the scope, deliverables and timeline in writing before work starts, so the database target, the app tables to be reviewed, the test cases and the window are all defined in advance and can be checked by your team before any change is made.
What converts cleanly from SQLite and what needs a second look
This table maps each part of a pilot Nextcloud installation to its counterpart after conversion to PostgreSQL or MariaDB, and notes what needs attention. Read it before scheduling the maintenance window, because the database conversion moves database content only and leaves the data directory where it is. The main takeaway is that the conversion is the easy part when the target database is ready, while app tables and the data directory need deliberate checks afterward.
| Source capability | Platform equivalent | Migration notes |
|---|---|---|
| SQLite database file | Target PostgreSQL or MariaDB database | The occ db:convert-type command copies database content into the new database. Confirm the target version against the Nextcloud system requirements for your release. |
| User and share data | Same user and share records in the target database | Users, groups, shares and their settings are database rows, so they move with the conversion. Verify sample shares and group memberships after the move. |
| App tables | App-managed tables in the target database | Some app tables are not converted by the command. Check the current list of unconverted tables in the Nextcloud admin manual for your version and plan manual steps for each. |
| Configuration | config.php with new database connection settings | The conversion updates the database connection. Review config.php, caching and any custom settings after the move, and keep a copy of the original file. |
| File storage on disk | Same data directory, unchanged by the conversion | The data directory is not part of the database conversion. Keep it in place, confirm its permissions and free space, and back it up separately before the window opens. |
Which documented tools perform the Nextcloud database conversion
Nextcloud has no single button for moving off SQLite. The work is split between a command in the server tooling, the database setup that the target engine needs before that command runs, and, for new installs, a packaged deployment that already includes PostgreSQL. Each tool covers a different part of the move, so knowing what each one leaves to you determines how much planning the pilot needs.
The occ db:convert-type command
This is the command-line tool in Nextcloud's server administration utility (occ) that moves the Nextcloud database from SQLite to a target database. It copies the core tables, so it is the step that most directly performs the conversion. It does not create the target database, its user, or its permissions for you, and it does not handle app tables that the conversion skips. Read the command's own help output and the upgrade notes for your exact version before planning the window.
Target database setup in the install docs
The system requirements and installation documentation list the supported database engines and versions for your Nextcloud release. For this move, the target must exist and accept connections from the Nextcloud host before conversion starts. Confirm the engine version against the requirements for your release, since Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18. You create the database, the dedicated user and the grants yourself, following the documented steps for the engine you chose.
Nextcloud All-in-One deployment
Nextcloud All-in-One is the official installation method and bundles PostgreSQL, Redis and APCu caching, so the database is provisioned as part of the stack. It is a fresh installation path, so it suits a new production build rather than an in-place conversion of an existing pilot. If your pilot runs on SQLite outside this stack, you still need to migrate its data into the bundled database or plan a reinstall with a data restore. Confirm which components your chosen edition includes before you design around them.
Staging copy before any production run
Every tool above changes database state, so the pilot should be converted first in a staging copy built from a current backup of its data directory and database. Run the conversion there, then test logins, file access, sharing, and the apps your pilot uses against the converted instance. Record the duration and any errors so the production maintenance window is based on observed results rather than assumptions. Keep the original SQLite installation untouched until the converted copy has passed your checks.
Responsibilities the tools leave open
No documented tool converts every app's data, so you must inventory the apps enabled on the pilot and check which of their tables are skipped or need separate handling. The occ command, the installer and the packaged stack each assume you handle backups, credentials, network access between the server and database, and post-conversion checks. Ask your implementation partner or Nextcloud's documentation to confirm exactly which tables are excluded for your release before scheduling the outage.
Choosing PostgreSQL or MariaDB as the Nextcloud production database
The first decision in this conversion is which database engine your production Nextcloud will run on. For Nextcloud 35, the system requirements recommend MariaDB 11.8 or PostgreSQL 18. Supported options include MariaDB 10.11 through 12.3, PostgreSQL 14 through 18, and MySQL 8.4 or 9.7. Oracle Database is available only with an enterprise subscription. Both recommended engines are reasonable choices for production, so the decision should rest on what your team can operate for years, not on which name appears first in the documentation. PostgreSQL is released under the PostgreSQL License, a permissive open source license similar to the BSD and MIT licenses. That matters if your legal or procurement review treats license terms as a gate. PostgreSQL ships a new major version about once a year, issues minor releases at least once every three months, and supports each major version for five years after its initial release. The current supported line, per the PostgreSQL versioning policy, is version 18, with a final release date of November 14, 2030. Version 17 is supported until November 8, 2029, version 16 until November 9, 2028, version 15 until November 11, 2027, and version 14 until November 12, 2026. Versions 13 and earlier are unsupported. Check these dates against your planned go-live, because a database that reaches end of life within months of launch creates an upgrade project you did not budget for. The choice depends on three things your team already has or must build. The first is existing database operations skill: who will tune, patch, monitor and restore the engine after the pilot ends. The second is backup tooling, since Nextcloud's own upgrade guidance expects a backup before every upgrade and your database backup method must match your storage and retention rules. The third is your high availability plan. PostgreSQL supports hot standby servers and both synchronous and asynchronous replication, but it does not detect a failed primary or promote a standby on its own, so automatic failover requires external tooling that someone must own. Before committing, confirm the target database version against the Nextcloud version you will run, using the Nextcloud 35 system requirements for that release. If you plan to run a different Nextcloud release, recheck the supported database list for that version, because recommended and supported versions change between releases. Ask your engineers to name the database operator, the backup and restore owner, and the standby or failover approach before the conversion window is scheduled. Those answers determine whether the database choice is sound for your organization.
How the Nextcloud database migration runs from inventory to decommission
The sequence moves a pilot Nextcloud off its SQLite file and onto a production PostgreSQL or MariaDB database in a controlled way, with a verified backup, a rehearsal, and a parallel period before the old file is removed. Each step produces a record that the next step depends on.
Inventory the pilot installation
The platform team records the Nextcloud version, the enabled apps, the size of the data directory and database file, the configuration in config.php, and any custom settings such as external storage, caching or background job setup. This inventory decides the target database version, the PHP and web server versions to check, and which third-party apps need a compatibility review. It is done when the team has a written inventory signed off by the application owner and the target versions are confirmed against the Nextcloud 35 system requirements for the release in use.
Provision and harden the target database
The database team or the partner builds the PostgreSQL or MariaDB instance on infrastructure the client controls, with a supported version from the Nextcloud system requirements, dedicated database and role for Nextcloud, network access limited to the Nextcloud servers, TLS for client connections, and backup and restore set up before any data arrives. Choosing between the two engines is a decision made earlier, based on the skills and tooling the operations team already runs. The step closes when a test connection succeeds from each Nextcloud application server and a restore test of the empty instance has been recorded.
Take and verify a full backup
The team puts Nextcloud into maintenance mode and takes a consistent backup of the SQLite file, the data directory, and the config directory. The backup is copied off the server and checked by restoring it to a separate host and confirming that files are readable and the file count and sizes match the source. Nextcloud's upgrade guidance expects a backup before any significant change, and this one is the rollback point for the whole project. The step is complete when the restore check is written down and the backup location and retention are agreed with the owner.
Rehearse the conversion on a staging copy
The team restores the backup to a staging environment with the same Nextcloud version, apps and configuration, then runs occ db:convert-type against the target database. They check the log output, record how long the conversion takes on that data set, and note any app tables that are skipped or need separate handling. Problems found here, such as an app with its own schema or a configuration value that points at the old database, are fixed in the runbook rather than during the live window. The rehearsal is done when a repeatable runbook exists and the staging result is accepted by the owner.
Run the conversion in the maintenance window
During the agreed maintenance window, the team enables maintenance mode, takes a final backup of the SQLite file, runs occ db:convert-type with the target connection details, updates config.php to point to the new database, and restarts the application services and background workers. The operator follows the runbook step by step and records each command and its output. The step closes when Nextcloud starts cleanly on the new database and the status command reports the expected database type and version.
Verify users, shares and app tables
The team checks that user accounts, groups, quotas, file metadata, shares, link shares, calendars, contacts and the tables for enabled apps have arrived intact. They compare row counts and sample records against the SQLite backup, test a login through each configured authentication backend, open a set of shared files from a second account, and confirm that background jobs run. Any app whose tables were not converted is checked against its own documentation and handled as a separate task. The step is done when a signed verification checklist lists every check and its result.
Run a parallel test period
For an agreed period, selected pilot users work on the new installation while the team watches logs, performance, failed jobs and support requests. Changes made during this period are recorded so the team knows exactly what differs from the converted data. The team also keeps the SQLite backup and the final conversion backup available so that a rollback path remains open. The period ends when the application owner accepts the results and no open defects block production use.
Decommission the SQLite file
Once the parallel period is accepted, the team archives the old SQLite file according to the retention policy, removes it from the live server, updates the monitoring and backup jobs so they no longer reference it, and records the final state in the operations documentation. The archived copy and the post-conversion backups are kept under the agreed retention period. The step is complete when the backup jobs run successfully against the PostgreSQL or MariaDB database and the decommission record is signed by the owner.
Planning the maintenance window and rollback point for the conversion
The maintenance window is the period in which the instance is in maintenance mode, the conversion runs, and the team checks the result before users return. Set it in three steps. First, put the instance into maintenance mode so that no user writes change data during the conversion. Second, run the conversion against a backup that has been verified, meaning the team has confirmed it is complete and readable, not just that the job finished. Third, test logins, file access and the functions of each enabled app before lifting maintenance mode. Agree in advance who signs off each check and who can decide to roll back if one fails.
The rollback point is the verified backup taken immediately before conversion. Anything written after the conversion starts lives only in the new database, so restoring the SQLite backup discards those changes. Decide before the window opens how long the new database will stay live, what users will be told about edits made during that period, and whether files uploaded in the window must be copied back by hand. Confirm with your own backup tooling that the backup covers both the database and the data directory, because a database restore without matching files will not return the instance to a consistent state.
Run the full sequence on a staging copy built from a recent production backup, using the same Nextcloud version, PHP version, database target and enabled apps. Time each step, including the backup, the conversion, the post-conversion checks and any repair steps. Use the slowest realistic result to set the window length. A pilot dataset is usually too small to predict production timing, because conversion work grows with the number of database rows and files. Ask your database administrator to confirm that the target server has the capacity and connection limits the staging run requires before the production window is booked.
Nextcloud's upgrade documentation requires a backup before every upgrade and advises disabling third-party apps until their compatibility is confirmed. A database conversion is not an upgrade, but the same discipline applies: take the backup, verify it, and treat the change as a change to a production system. Disable third-party and custom apps for the window, or confirm each one against the target configuration in staging. Record which apps were turned off so they can be re-enabled one at a time afterwards. Re-enabling them in a single batch makes it hard to identify which app caused a fault.
What drives the cost and duration of a SQLite to PostgreSQL conversion
This table lists the factors that change the effort of converting a pilot Nextcloud from SQLite to PostgreSQL or MariaDB, why each one matters and what to request in a written quote. Conversion, testing and the runbook are one-time work, while database operations, backups and patching recur after go-live. Read each row as a question to answer before asking for a quote, because the answers set the scope.
| Driver | Why it matters | What to ask for in a quote |
|---|---|---|
| Number of users and data volume | Conversion and test runs take longer as the database grows in rows and file metadata. Larger instances also need more time for verification after the switch. | Current user count, file count and database size from the pilot, plus expected growth over the next year. |
| Installed apps and their table handling | Apps add their own tables. The conversion command does not convert every app table, so affected apps need manual checks, a rebuild or a vendor fix. | A list of enabled apps with versions, which apps create custom tables and the planned handling for each one. |
| Target database and whether it is built from scratch | Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18. A new server needs installation, tuning and a version check. PostgreSQL 14 is supported until November 12, 2026. | Chosen database and version, whether a new server is built or an existing one is reused, and who installs and tunes it. |
| Backup and restore tooling | A tested backup is the rollback path for the conversion. Restore testing and point-in-time recovery add setup and verification work. | Backup method for files and database, a restore test with recorded results and the retention period agreed with you. |
| High availability or replication | PostgreSQL supports standby servers, but it does not detect a primary failure or fail over on its own. Replication and failover tooling add build, monitoring and test effort. | Whether standby servers, synchronous or asynchronous replication and automatic failover are in scope, with the tools named. |
| Identity and SSO integration | If users sign in through LDAP, OpenID Connect or SAML, those connections must keep working on the new database. Each connection adds test cases. | Identity backend in use, whether its configuration moves unchanged and the test accounts used for sign-in checks. |
| Testing scope and number of environments | The conversion should be rehearsed on a copy before production. Each extra environment and test pass adds work for the team. | Number of environments, rehearsal runs planned, test cases covered and who signs off each stage. |
| Maintenance window agreed with the business | The window sets how much downtime is acceptable and how many rehearsals fit before go-live. A shorter window usually needs more preparation. | Required window length, time zone, business owner for sign-off and the fallback plan if the conversion overruns. |
What usually goes wrong when Nextcloud moves off SQLite
Most failures in this migration come from treating the conversion as a single command. The risks below cover preparation, the target database, the cutover and the checks after it. Each card gives the prevention step to complete before the maintenance window opens.
Back up database and data together
The database and the data directory make up one instance, so a backup of only one is not a usable restore point. Before converting, take a database dump and a copy of the data and config directories in the same window, then confirm the dump restores into a scratch database. Record the Nextcloud version beside the backup so the restore target is clear. Keep the backup until the converted instance has been checked in use.
Skip the staging rehearsal
The conversion is easiest to judge on a copy of the pilot that matches its apps, data volume and PHP setup. Run occ db:convert-type against that copy, then log in, sync a test account, share a file and open calendars and contacts to confirm normal use. Keep the timings and any warnings from the rehearsal, since they are the best evidence for planning the production window. A rehearsal that only confirms the command ran misses problems that appear in daily use.
Assume every app table converts
Some app tables are not converted by the command, so a successful run does not prove that every app is intact. Before converting, list enabled apps with occ app:list and identify those that store data in the database. After conversion, check those apps against their own documentation and test their main functions, such as shares, calendars or contacts. Review the server log for database errors from each app.
Leave the target database unready
The target has to be reachable from the Nextcloud server and sized for the instance before conversion starts. Create the database and a dedicated user with the privileges Nextcloud needs, then confirm the network path and firewall rules from the web and cron hosts. Check that the chosen version is supported, since Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18. Ask the database team to confirm memory, storage and connection limits for the expected user count, and to schedule backups for the new server from the start.
Forget to update connection settings
After conversion, the instance must point at the new database. Confirm that the database type, host, port, name, user and password in the configuration file match the target, and that the file is readable only by administrators. Check the cron job and any scripts that call occ, since they read the same configuration. Test that the instance loads and that background jobs run against the new database.
Underestimate the window on a larger pilot
The conversion copies every table, so its duration grows with the amount of data in the pilot. A quick run with a few test accounts does not predict the time needed for production data. Use the timings from the rehearsal on a copy with comparable data, then add time for the backup before and the checks after. Agree the window with users in advance and decide before the start who can call a rollback, since that decision sets how long the instance may stay offline.
Questions buyers ask before moving Nextcloud off SQLite
How much does it cost to move Nextcloud from SQLite to PostgreSQL or MariaDB?
The cost is driven mostly by the work around the conversion command. The main drivers are the size of the pilot data, the number of installed apps and custom settings to check, the database server you provision and back up, the maintenance window your users accept, and how much testing you require before cutover. Some costs are one-time, such as the target setup, the rehearsal and the cutover. Others recur, such as database backups, patching and the Nextcloud upgrades that follow. A written quote should list each task as its own line, state who performs it and name the environment it covers. DeployOpen does not publish prices, so ask for a fixed-scope quote built from the agreed scope.
How long does a Nextcloud database conversion take?
No fixed duration applies to every instance, because the runtime depends on data volume, the number of users and files, server performance and the window you agree to. Confirm the expected runtime for your target version in the Nextcloud admin manual, then rehearse the conversion on a copy of the pilot data before you schedule production work. The plan should include time to create and check the target database, run the conversion, verify logins, file access and app behavior, and keep a rollback path. Ask any proposal to break the duration into these stages so you can see where the time goes and which stage carries the most risk.
Can our internal team convert Nextcloud to PostgreSQL or MariaDB without a partner?
Yes, a team with Linux, database and PHP administration skills can perform the conversion with the documented occ command, but the command is only one step. Your staff must provision the target database at a supported engine version, supply the PHP extensions and network access, plan the maintenance window, take and test backups, and check the app tables that the conversion does not move. They also need someone who can read the Nextcloud logs and decide whether to roll back. A partner is most useful when the team lacks these skills or cannot carry the outage risk alone. Confirm the current conversion steps and limits in the admin manual for your version.
Can SQLite stay in place while we pilot Nextcloud?
SQLite can serve a small, short pilot, but the pilot needs a clear end date and a decision point before wider rollout. Record which users, apps and workloads the pilot covers, and note what would change if the number of users or files grew. Nextcloud's system requirements list the supported database engines for each release, so do not assume that a database chosen for testing will carry into production without review. Plan the conversion before the instance grows, because a larger instance means a longer conversion and a longer window. Confirm the current database guidance in the system requirements for your target version.
Should we choose PostgreSQL or MariaDB for Nextcloud 35?
Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18, and both are on its supported list. Choose based on what your organization already operates, which team will back up, patch and restore the engine, and which engine your monitoring, backup and high availability tools support. PostgreSQL is released under the PostgreSQL License, a liberal open source license similar to the BSD or MIT licenses. It supports hot standby servers and both synchronous and asynchronous replication, but it does not include automatic failover, so that capability needs external tools. Confirm the supported versions for your target release in the system requirements before you decide.
How long should we expect Nextcloud support to continue after the migration?
Support depends on the Nextcloud major version you run and on whether you buy an Enterprise maintenance tier. Nextcloud publishes a major version every four months and supports each for one year with monthly maintenance releases. Nextcloud 35 was released on 16 September 2026 with end of life in September 2027, Nextcloud 34 is supported until June 2027 and Nextcloud 33 until February 2027. Nextcloud's pricing page lists one year of maintenance for Standard and a lifecycle of five years or more for Premium. For the database, PostgreSQL 14 is supported until November 12, 2026 and PostgreSQL 18 until November 14, 2030. Confirm current maintenance timelines with Nextcloud and in the admin manual before you set a support plan.
What happens to Nextcloud apps and app tables during the database conversion?
The conversion moves the core database, but app tables that the command does not convert need a checked path before cutover. Inventory every installed app, note which ones create their own tables, and confirm each app's compatibility with the target version before you convert. Nextcloud's upgrade guidance advises disabling third-party apps until they are confirmed compatible, which is a sound default for this work. Ask any proposal to list each app, explain how its data will be verified after conversion and name the person who decides whether an app is removed or reconfigured. Confirm the current list of unconverted tables in the admin manual for your version.
How DeployOpen scopes and delivers the Nextcloud database migration
DeployOpen starts Move Nextcloud from SQLite to PostgreSQL or MariaDB with a written scope that names the source installation, target database, Nextcloud version and maintenance window. We then build the target database, run the conversion with occ db:convert-type on a rehearsal copy, and hand over a documented result your team can operate. Engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- The written scope lists the source Nextcloud version, the PHP and web server stack, and the target database engine.
- It names which app tables the conversion skips and how each one is handled after the switch.
- The scope agrees the maintenance window, the rollback point and who approves the cutover.
How we build
- Provision the PostgreSQL or MariaDB target with supported versions for your Nextcloud release, checked against its system requirements.
- Run occ db:convert-type against a copy of the pilot, then compare user data, file counts and logins.
- Take a full backup of files and database before the production run, and confirm a restore works.
How we hand over
- Deliver a runbook with exact occ commands, maintenance window steps and the rollback procedure tested in rehearsal.
- Document each app table the conversion did not move, with its reason and the follow-up it needs.
- Walk administrators through database settings in config.php, cron jobs and the post-conversion checks.
How we support
- Track PostgreSQL or MariaDB support windows after handover, and schedule database upgrades before end of life.
- Ongoing support, upgrades and testing are available as a retainer, scoped separately from the migration.
- Plan each later Nextcloud major upgrade one version at a time, with backups and third-party app checks first.
