Plex Media Server - SQLite - MySql

[bryanpetkus]

I have noticed that when a Plex Server has over 10k content that there is constant issues with the SQLite database. Sometimes it is just lag, but moreover crashes and lockups happen more often. I have tracked down the process cause and it is the database not Plex. When will Plex have an option or switch to MySQL or similar database? This should be a top issue on the developer todo list as it is the main cause of stability issues. I have confirmed the former on over 30 Plex installations. Furthermore once content reaches 30k monthly database related issues are almost certain. Please discuss and provide timeline for DB modernization.

[tom80H]

There’s an actual feature suggestion discussing this topic (and what database servers to use instead).

[REQUEST] Move from SQLite to MySQL or Postgres

I would like to request that the metadata database com.plexapp.plugins.library.db move from SQLite to MySQL or Postgres ( Or any real external db for that matter).  I feel that this would bring additional stability and repair functionality for large collections.  Additional if this database was available as an external shared resource it would allow for additional clustering and high availability functionality.  

[ChuckPa]

I will respectfully disagree with that statement.

1. 133,732 media items

sqlite> select count(*) from metadata_items;
133742
sqlite> 

2. Zero database issues.

I assert:

1. Plex Media Server host computer system (or NAS) not keeping up with demand
2. Abrupt power-off / forced shutdown before clean exit / power interruptions are the greater cause of corrupt databases

EDIT: Addendum

sqlite> select count(*) from metadata_items;
133742
sqlite> 
[chuck@lizum qnap.77]$ sqlite3 *.db .dump > db.sql
[chuck@lizum qnap.78]$ wc -l db.sql
1006567 db.sql
[chuck@lizum qnap.79]$ 

[Volts]

SQLite is objectively among the highest-quality code in the world.

https://sqlite.org/testing.html

30k, 100k, 1M records … those are absolutely trivial database sizes.

Scaling SQLite to 4M QPS on a Single Server (EC2 vs Bare Metal)

He describes some very beefy servers, yes. He also describes SQLite databases with 10B rows and 4M queries/second.

SQLite is well-suited for Plex’s current architecture, too.

If you have 30 systems with problems, I suggest that there is another commonality …

I jest. But maybe you could share the problems that you’re seeing? If it’s blowing up repeatedly, there’s something wrong.

How are you diagnosing database issues, “not Plex”?

[bryanpetkus]

SQLite is not the highest quality code nor is it the best database too use for this application. It’s good, but not great. Without going into the great SQL debate there are real SQL servers that should be used. #bump the SQL server option feature request.

[Volts]

I don’t have any particular affection for SQLite, but I hold it in high regard and it seems appropriate for Plex. It is flexible and lightweight. Code quality is high and maintenance is low. The lack of concurrent user support doesn’t affect Plex.

You stated that you tracked down SQLite as the main cause of stability issues. Such statements should generally be accompanied by evidence.

If you are aware of specific issues it would be useful to share them so that they can be investigated and addressed.

Perhaps there is something wrong with SQLite. Or the way Plex interacts with the database. Maybe SQLite settings can be optimized. Or perhaps Plex’s database structures, indexes, or maintenance processes could be improved. Or a million other things.

If so, sharing could benefit the community.

“You should change technologies” is tiresome and meaningless without details of how it would apply and why it would help.