As a test, we dropped the compatibility level back down to 100 and everything sped back up. We then changed it to 120, which performed faster than 130, but slower than 100. For now we have put it back at 100.

That particular notice is not relevant to folder listings. The STIntersects function that it talks about is only relevant when doing geography searches. But it's not uncommon for systems to see performance problems when upgrading compatibility levels. If you haven't rebuilt indexes, that's always a good thing to try. Beyond that, Microsoft has a Query Tuning Assistant that can help https://docs.microsoft.com/en-us/sql/relational-databases/performance/upgrade-dbcompat-using-qta?view=sql-server-ver15 .

Blake, for what it's worth we upgraded from SQL 2014 to 2019 a couple of weeks ago, upgrading the compatibility to 2019 as well (150) and haven't had any issues. We have both LF 11 and LF 10.4.5 environments.

Interestingly, my custom lookups databases that connect to external systems had to be set back to 2014 compatibility, but none of the Laserfiche-created DBs are giving us problems.

Hey Blake,

Did you end up finding anything out about this? I've inherited a client from a different service provider who states that after moving their databases from SQL Express to SQL Standard, they have to run their LF databases in 2008 (100) compatibility mode or it's just so slow that it becomes unusable. I know it's unlikely we're looking at the exact same situation, but curious about where we can start troubleshooting. I'll open a case with Support once we get their LSAP situation figured out, so figured I'd start here on Answers.

Thanks!