# Is 2026 terribly slow because of the new database structure, or is something else going on? **URL:** \ **Category:** Flame Questions\ **Tags:** batch, project\ **Created:** [October 2, 2025, 4:56pm UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589 "2025-10-02T16:56:15Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![philm](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/philm/32/9286_2.png) [@philm](https://forum.logik.tv/u/philm)\ **Post date:** [November 18, 2025, 5:13pm UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/21 "2025-11-18T17:13:55Z")
Thanks @ALan I don’t use cached media. I certainly never orange dot a cache in batch. I use openclips for everything. I’m not seeing the same behaviour at all. If I need to cache something for playback i’m using the per object ‘Cache all versions’ options for open clip on a timeline. ---
**Author:** ![eddiead](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/eddiead/32/3819_2.png) [@eddiead](https://forum.logik.tv/u/eddiead)\ **Post date:** [November 18, 2025, 5:43pm UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/22 "2025-11-18T17:43:51Z")
I installed 2026.2 and migrated my current problematic project via the project manager (converting the project as a copy). Initial launch of Flame and loading Workspace (59sec - premature elation). Did some work in BatchGroup, save project, exit Flame. Launch Flame, loading workspace (13min21sec). Will keep testing, but it seems back to 2025 it is. ---
**Author:** ![hBomb42](https://avatars.discourse-cdn.com/v4/letter/h/bbce88/32.png) [@hBomb42](https://forum.logik.tv/u/hBomb42)\ **Post date:** [November 18, 2025, 5:53pm UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/23 "2025-11-18T17:53:15Z")
Do you have a support case going? This definitely seems worth their time. ---
**Author:** ![ALan](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@ALan](https://forum.logik.tv/u/ALan)\ **Post date:** [November 18, 2025, 7:27pm UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/24 "2025-11-18T19:27:11Z")
Case 25056692 - slow library operations ---
**Author:** ![ALan](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@ALan](https://forum.logik.tv/u/ALan)\ **Post date:** [November 18, 2025, 7:27pm UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/25 "2025-11-18T19:27:45Z")
None of which applies to the discussed issue. > [@philm](#): > > Thanks > > I don’t use cached media. > I certainly never orange dot a cache in batch. > I use openclips for everything. > I’m not seeing the same behaviour at all. > If I need to cache something for playback i’m using the per object ‘Cache all versions’ options for open clip on a timeline. ---
**Author:** ![philm](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/philm/32/9286_2.png) [@philm](https://forum.logik.tv/u/philm)\ **Post date:** [November 18, 2025, 8:36pm UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/26 "2025-11-18T20:36:09Z")
> [@ALan](#): > > None of which applies to the discussed issue. To the contrary: all of which applies to the discussion: the directory slowdowns that you are experiencing are not what I’m experiencing. so there’s that. ---
**Author:** ![aaronneitz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/aaronneitz/32/3874_2.png) [@aaronneitz](https://forum.logik.tv/u/aaronneitz)\ **Post date:** [November 18, 2025, 10:01pm UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/27 "2025-11-18T22:01:29Z")
Trying to parse this thread: is 2026.2 slow from freshly started projects, or projects moved up from earlier versions? ---
**Author:** ![eddiead](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/eddiead/32/3819_2.png) [@eddiead](https://forum.logik.tv/u/eddiead)\ **Post date:** [November 19, 2025, 4:31am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/28 "2025-11-19T04:31:07Z")
I can not confirm this though. Will have to roll the dice on that one. What I experienced in 2026.1 is that at a point in the project (late stages) the slow down is triggered. It is not gradual and there are no specific actions associated with the event. The two projects that I have done thus far are vastly different. One not that complex. 30% comp work with subs for social media versions and SM versioning. Second project is a proper heavy comp job with background environment replacements. Heavier shots have pre-renders as BFX clips to speed things up. My default workflow on both shows are BFX with connected segments for versioning between all edits and this is possibly where the bloat starts. Once again the issue only surfaces very late stage after most of the actual work is at 90% and final polish and finesse starts. I have not tried a BatchGroup approuch yet from a fresh project to test if the timeline BFX workflow is the problem. At this point I’m very hesitant to even try a new project in 2026.x as there is no rollback as a safety net if and when this problem reoccurs. ---
**Author:** ![cnoellert](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/cnoellert/32/559_2.png) [@cnoellert](https://forum.logik.tv/u/cnoellert)\ **Post date:** [November 19, 2025, 4:53am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/29 "2025-11-19T04:53:06Z")
I have a project that I’m working on that has only one sequence in 3kx3k. 16 segments each with a distinct BFX. Each of those BFX contain light color and comp on RGB exr comps from Nuke. There are some alphas for these color moves being created from cryptomattes generated from the original/uncomped CG renders. Everything worked great until it just wasn’t anymore. I hit render after updating a few of the comps 4 frames rendered and then it all came to a crawl. Complete and utter standstill. Canceled and restarted Flame and same issue. Reboot solved it for about an hour or so and then the out of no where unuseable. I never use BFX. Maybe for graphics prep in the timeline but otherwise never. This was just meant to be some quick, session style CC on full cg and a total one off but it has totally bitten me in the ass. Is this related? Sounds like it. Otherwise like @philm said, in my normal workflow I haven’t had a single issue working unmanaged and anti-establishment in 2026.x ---
**Author:** ![eddiead](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/eddiead/32/3819_2.png) [@eddiead](https://forum.logik.tv/u/eddiead)\ **Post date:** [November 19, 2025, 7:35am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/30 "2025-11-19T07:35:52Z")
> [@Slabrie](#): > > have you opened a ticket with out Support team? if so, please share the ticket number so I can follow-up. > > You might also want to upgrade to 2026.1.1 so you you the latest bug fixes (). Also, the 2026.2 Update is available. Case number 25059348 ---
**Author:** ![johnag](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/johnag/32/573_2.png) [@johnag](https://forum.logik.tv/u/johnag)\ **Post date:** [November 19, 2025, 8:00am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/31 "2025-11-19T08:00:53Z")
very very very long shot and probably not related but I had very slow save times until I flicked the PROTECTION MODE switch in Flame General Prefs. Not sure how it came on but when I turned it off my system was snappy again. ![image](https://us1.discourse-cdn.com/flex020/uploads/thedepartmentofexternalservices/original/2X/7/75716d88482e442858b2d395961aa1b3e861cc28.jpeg) ---
**Author:** ![allklier](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/allklier/32/4309_2.png) [@allklier](https://forum.logik.tv/u/allklier)\ **Post date:** [November 19, 2025, 9:32am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/32 "2025-11-19T09:32:34Z")
> [@cnoellert](#): > > Everything worked great until it just wasn’t anymore. I hit render after updating a few of the comps 4 frames rendered and then it all came to a crawl. Complete and utter standstill. Probably unrelated, but this has memories from a year or so ago when I was battling VRAM memory leaks on a fairly basic 20min timeline with just color in TLFX. Started off well, and for no good reason turned into molasses. Eventually I had to render the timeline in short segments and concatenate in Resolve just to make it through. Eventually a memory leak was confirmed and a case created. But I haven’t heard anything since. ---
**Author:** ![eddiead](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/eddiead/32/3819_2.png) [@eddiead](https://forum.logik.tv/u/eddiead)\ **Post date:** [November 19, 2025, 9:35am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/33 "2025-11-19T09:35:29Z")
Initial tests seems very promising. Saving across the board seems much faster. Will keep testing and report back. ---
**Author:** ![allklier](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/allklier/32/4309_2.png) [@allklier](https://forum.logik.tv/u/allklier)\ **Post date:** [November 19, 2025, 10:32am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/34 "2025-11-19T10:32:20Z")
> [@johnag](#): > > very very very long shot and probably not related but I had very slow save times until I flicked the PROTECTION MODE switch in Flame General Prefs. Not sure how it came on but when I turned it off my system was snappy again. I vaguely remember a discussion with @Slabrie either at NAB or in a Logik Live about this option. We should get an explanation what it does. It may lock everything while the auto save is in progress? Wasn’t there something that this matters in multi-user settings, but if you’re single user, it doesn’t make much of a difference and is safe to disable? ---
**Author:** ![eddiead](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/eddiead/32/3819_2.png) [@eddiead](https://forum.logik.tv/u/eddiead)\ **Post date:** [November 19, 2025, 10:42am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/35 "2025-11-19T10:42:39Z")
This has definitely made an improvement for me. The long term repercussions, we’ll have to see. For now it is a solve as a single seat user. ---
**Author:** ![eddiead](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/eddiead/32/3819_2.png) [@eddiead](https://forum.logik.tv/u/eddiead)\ **Post date:** [November 19, 2025, 10:47am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/36 "2025-11-19T10:47:37Z")
A quick search has returned the following: **Protection Mode** in Autodesk Flame (as shown in your screenshot under **General → Autosave** ) is a safeguard feature designed to **prevent accidental overwrites, destructive changes, or unintended modifications** to your project’s media, setups, and metadata. It is mainly intended for long-form, multi-artist, or facility environments where asset integrity is critical. Below is a **detailed, practical explanation** of what Protection Mode does and how it affects everyday Flame workflows. * * * # 🔐 **What “Protection Mode” Does in Autodesk Flame** Protection Mode places Flame into a **restricted-editing state**. When enabled, it changes how Flame handles saves, overwrites, and structural modifications to help protect your work. It does **not** stop you from working—rather, it prevents actions that could accidentally damage existing material. * * * # ✅ **Key Behaviours of Protection Mode** ### **1. Prevents destructive edits to Batch Setups and Sequences** Flame will block or warn you before: - Overwriting an existing Batch setup - Saving a Batch that would overwrite older versions - Overwriting timeline segments or writes without confirmation - Replacing media used in existing composites This reduces the risk of losing a working version. * * * ### **2. Adds confirmation layers for save operations** With Protection Mode **ON** , Flame introduces extra steps before: - Soft Saves - Hard Saves - Writing/Rendering over existing files - Replacing clip versions This prevents accidental overwrites—especially common when switching rapidly between shots or versions. * * * ### **3. Protects shared project assets** In multi-artist environments (shared storage / shared libraries): - Matchboxes, shaders, and setups that are shared are protected - Flame warns before modifying shared or read-only elements - Helps ensure one artist doesn’t accidentally destroy another’s work * * * ### **4. Interacts with Autosave System** While Protection Mode is ON: - Autosave still functions normally - But autosave **will not overwrite protected files or setups** - Autosave may create _new_ incremental versions instead of replacing old ones * * * ### **5. Helps prevent structural database corruption** Protection Mode reduces the risk of: - Corrupting the workspace or project database - Damaging large BatchFX setups during heavy scenes - Mass-updating clip metadata by accident It is especially useful on: - Long-form projects - Complex BFX structures - Shared facility setups - Situations where large slow saves have caused instability * * * # 📌 **Why Flame Has Protection Mode** Because Flame is designed for high-end finishing with **complex node graphs and interlinked media** , a single overwrite or mis-save can: - Break a shot - Break an entire sequence - Corrupt media links - Invalidate days of previous work Protection Mode exists to reduce this risk. * * * # 💡 **Typical Usage Scenarios** ### You should enable Protection Mode if: ✔ You’re working on long-form shows with many interconnected BFX ✔ Multiple artists are sharing the same project or library ✔ You want to prevent accidental overwriting of versions ✔ Large saves slow the project and you want to minimize risk ### You might disable it when: ✖ Doing rapid iteration and saving dozens of versions quickly ✖ You’re the only person working in the project and prefer faster saves ✖ You’re in a “sandbox” session without risk This information needs to be officially confirmed from ADSK side. ---
**Author:** ![eddiead](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/eddiead/32/3819_2.png) [@eddiead](https://forum.logik.tv/u/eddiead)\ **Post date:** [November 19, 2025, 11:00am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/37 "2025-11-19T11:00:35Z")
Here is a more digestible version of the above as a pdf. [Protection Mode in Autodesk Flame.pdf](https://forum.logik.tv/uploads/short-url/yHhXRc3m8nmhmT3B2LWrDDstDzL.pdf) (248.8 KB) As before this information needs to be confirmed by @Slabrie as this is a quick chatGPT search, but from my understanding of this feature the information seems correct. ---
**Author:** ![eddiead](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/eddiead/32/3819_2.png) [@eddiead](https://forum.logik.tv/u/eddiead)\ **Post date:** [November 19, 2025, 11:07am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/38 "2025-11-19T11:07:48Z")
As a side note (off topic), now that 2026.2 is some what workable and behaving with ‘Protection Mode’ off, the new Automatte seems very promising and initial tests are very impressive and is producing even better results in some cases as Sammie-Roto. ---
**Author:** ![allklier](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/allklier/32/4309_2.png) [@allklier](https://forum.logik.tv/u/allklier)\ **Post date:** [November 19, 2025, 11:22am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/39 "2025-11-19T11:22:17Z")
Make sure to watch @Jeff’s learning channel video for some helpful workflow tips on AutoMattw. ---
**Author:** ![eddiead](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.logik.tv/eddiead/32/3819_2.png) [@eddiead](https://forum.logik.tv/u/eddiead)\ **Post date:** [November 19, 2025, 11:29am UTC](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589/40 "2025-11-19T11:29:09Z")
Yip, been through those already. Thanks to @Jeff for the ongoing great work on that front. [Previous page](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589.md?page=1) [Next page](https://forum.logik.tv/t/is-2026-terribly-slow-because-of-the-new-database-structure-or-is-something-else-going-on/13589.md?page=3)