You updated DaVinci Resolve over the weekend, and on Monday morning the project library is empty. Or the library is populated but every project you double-click throws “unable to open project.” Or Resolve launches and asks whether to upgrade the database — and after saying yes, the upgrade fails partway through and every project on that database is now unreachable. Or the disk holding your project got full during a save, and now the project.db file that held three weeks of color grading, three dozen timelines, and every node graph you’ve built for a client is corrupt. Or you were working on a PostgreSQL database on a shared editing server, and the server rebooted mid-transaction, and now Resolve can’t connect to the database at all.

Gillware recovers corrupted DaVinci Resolve projects — the disk-database project.db file, the PostgreSQL server databases used in facility workflows, and the individual project data (timelines, node graphs, grades, media pool structure, still stores, color management state) inside them. This is one of the spokes under our broader video production data recovery page. For other NLEs, see the sibling pages on Premiere, Final Cut Pro, and Avid Media Composer.

How Resolve stores your work — and why that matters for recovery

DaVinci Resolve doesn’t store projects as individual files. It stores them inside a database. When you open Resolve and see the Project Manager, you’re looking at the contents of the currently-selected database. Every project you create, every timeline in every project, every grade on every clip, every node in the color page — all of it lives as rows inside that database. Delete the database, and everything Resolve knows about your work goes with it.

Resolve supports two database backends. The default for single-editor workstations is the disk database — a SQLite file stored on the local machine (typically at ~/Library/Application Support/Blackmagic Design/DaVinci Resolve/Resolve Disk Database/ on macOS, or the equivalent location on Windows and Linux). This is the setup most freelance editors and colorists use. The second backend is PostgreSQL — a networked database that a facility runs on a server, letting multiple editors and colorists share projects. This is the setup at most professional post houses.

Corruption of either backend has the same effect from the user’s point of view — projects that were there yesterday are gone or won’t open today — but the underlying failure modes, and the recovery techniques, are different. Understanding which backend you’re on determines what happens next.

Why a Resolve database goes corrupt

The patterns we see:

• Major version upgrade fails partway through. Resolve’s major version releases (18 → 19 → 20 and onward) each ship with a database schema migration. If the migration is interrupted — an application crash, a system sleep, a power event — the database is left in a partial state. Projects that were unmigrated at the moment of failure are unreachable in the new version, and in some cases the entire database is unreadable until repaired.
• Disk-full corruption on save. Resolve’s disk database, being a SQLite file, is vulnerable to disk-full events during writes. When Resolve is saving a project and the drive runs out of free space, the SQLite pager can leave the database in an inconsistent state. Opening it after the failure produces “database is malformed” or “not a database” errors.
• Application crash during save. A hard crash during a project save can leave the disk database in an inconsistent state that Resolve can’t recover from on next launch. Colorists doing heavy work on the color page can lose hours or days of grading this way.
• External drive disconnect during autosave. Databases stored on external drives — a common setup for editors who move between machines — can be corrupted by an unplug during a write. The autosave timing means the window for this failure is small on any given day but nonzero over a long project.
• PostgreSQL server crashes. On facility installations running the PostgreSQL backend, an ungraceful server shutdown during a transaction can leave the database in an inconsistent state that requires either PostgreSQL-level repair or point-in-time recovery from backup.
• PostgreSQL upgrade failures. Facility upgrades of the PostgreSQL server (major version bumps on the server side) can leave databases inaccessible until schema migrations are properly re-run.
• Drive failure under the database file. The database file itself is fine, but the drive holding it has developed bad sectors. Reads return corrupted data, and Resolve fails to open a database that would be readable on healthy storage.

The “months of grading lost” scenario

The specific case that turns up repeatedly on colorist forums is the update-and-lose-everything failure: an editor or colorist has been working in a single Resolve build for weeks or months, updates to a new major version, launches Resolve, and finds the project library empty. The database is technically still there, but the new version cannot open it — the schema migration failed, or the database format changed in a way the new version handles poorly.

What people usually do next is exactly what makes recovery harder. Some reinstall the old version of Resolve to try to open the database with the previous release; the older release refuses to open a database that’s already been touched by the new version’s migration. Some try Resolve’s built-in project restore mechanisms, which write over the corrupted database. Some let Resolve create a fresh database “just to see if it works,” and the new empty database overwrites the on-disk location of the old one.

Every one of those attempts reduces recoverability. The best move when a Resolve upgrade wipes the project library is to stop using Resolve on that machine, copy the entire database folder to a separate drive, and open a recovery case. The pre-migration database is almost always salvageable if it hasn’t been further modified.

What recovery looks like for a Resolve database

Disk database recovery starts at the SQLite file level. The project.db file is examined outside of Resolve — its SQLite structure is validated, its internal pages are checked, and any corruption is characterized. SQLite is a mature and forgiving format, and localized damage is usually repairable at the page or record level. The internal tables — projects, timelines, clips, grades, node graphs, media pool references — are extracted directly and reassembled into a working database.

For databases where the file is beyond direct repair, we work with the surrounding structure. Resolve keeps a small backup of the database in the same folder, and although those backups are subject to the same “the corruption was already there” problem that Final Cut backups have, they sometimes contain enough clean state to reconstruct the important projects. Deleted or overwritten previous versions of the project.db file can also be pulled from unallocated space on the storage.

PostgreSQL recovery is a different discipline. The PostgreSQL database directory is examined at the file level (data files, transaction logs, WAL segments), and PostgreSQL’s own recovery tooling is used against isolated copies of the data — never against the live server, which could compound the damage. Point-in-time recovery from WAL logs can often reconstruct the database as it existed minutes before the corruption event.

Where the projects themselves are the target rather than the database as a whole, we can extract individual timelines, node graphs, and media pool references and hand them back as Resolve project exports that can be imported into a fresh database.

Media, drives, and shared editorial storage

Resolve projects reference media that lives elsewhere on the storage. A recovered project file is useful only if the media it references is also present. If the underlying drives holding footage, cache, or optimized media have also failed, the recovery pipeline covers them too. Single-drive failures run on our no-data-no-charge evaluation. Editing arrays — RAID 5, RAID 6, NAS storage, editing SANs — are covered on our video editing RAID and shared storage recovery page. For camera cards and offload drives, see the parent video production data recovery hub.

What not to do with a corrupt Resolve database

• Don’t let Resolve keep running against the broken database. Quit Resolve. Every attempt to interact with a corrupted database can further modify it.
• Don’t downgrade Resolve to try to open the pre-upgrade database. Once a major version migration has touched the database, downgrading rarely reverses the damage cleanly. It sometimes finishes the corruption.
• Don’t let Resolve create a new database in the same location. If the old database can’t be found or opened, Resolve will offer to create a new one. Doing so writes to the same directory and can overwrite the recoverable state.
• Don’t use “database repair” utilities from third parties. SQLite has a legitimate repair path that requires care; generic tools often leave databases worse than they started.
• Don’t reformat or reinstall over the drive holding the database. If the database is missing entirely, deleted-file recovery is often the last remaining option — and it evaporates the moment the drive is written to.
• Don’t restart the PostgreSQL server after a suspected corruption event without imaging first. A restart can trigger recovery routines that write to the data directory and reduce what’s recoverable from the pre-restart state.

Working with Gillware on a Resolve recovery

Gillware handles DaVinci Resolve databases from every current major version, on both the disk and PostgreSQL backends, on macOS, Windows, and Linux. We work with both single-editor freelance setups and facility PostgreSQL installations — the recovery techniques are different, and the same lab handles both.

For colorists and editors against a delivery deadline, we prioritize the queue on request. If a client review, a broadcast delivery, or a color session on the calendar is at risk, tell us when you open the case and we’ll match the schedule where the physics of the recovery allow.

Return to the routing hub: video production data recovery.