This topic seems to never garner a response from Plex, other than something along the lines as they see supporting a real RDBMS leans towards “Enterprise” use, and that’s not the direction Plex is supposed to be used in. Which is a response that we, as users and supporters of Plex deserve better. After all, we are supposed to be the driving force behind Plex, and they purport to be giving us what they think we want. Regardless of what they claim, SQLite does not scale, and we’re forced to deal with slow, sometimes unaccessable services. From the “waiting 200ms for a busy DB” to corrupted databases that have to be rebuilt, it becomes annoying. And, whenever a user reports one of these problems, Plex loves to point the finger at the users, saying we did something wrong.
While support mySQL/mariadb, postgres, or whatever may not be something all users will want, there are enough of us to warrant making this change. And the response from Plex that supporting a true DBMS would require a complete rewrite of certain parts, is bogus, or the point could be made that it’s bad programming on their part.
This could be solved by using standard SQL, and creating a library that handles the database calls. This is how we’ve done it – we have our database abstraction layer that handles all calls to the database. The library defines methods like ‘ExecQuery’ that executes SQL that returns a result set (i.e. select statements) and ExecNonQuery that executes SQL that does not return a result set (i.e. update, insert, delete, etc). The code doesn’t care which DBMS that is being used, as the library takes care of establishing a connection to the database, etc. It handles any specifics for the various DBMS, etc.
I, not for a second, don’t believe that Plex doesn’t have a library or set of functions defined for communicating with their SQLite database and they just use those calls to communicate. It would be trivial to update this library to support another DBMS. Plex just doesn’t want too. They will come back wth ‘There are not enough users wanting this to warrant this’ when that is not the case. They just don’t want too. Plex has gotten to the point where they no longer listen to their users, but rather, do what they want to do. A perfect example is killing off Plugins. They claimed they were killing them off because the plugin system was a mess, and they were going to bring it back after they cleaned it up, and improved it. But it’s been a few years, and nothing. The hope was, they would kill it off, and slowly people would stop asking for it and just forget about it.
Plex no longer cares what their users want. They are bringing features that they want, features to bring in even more revenue to the company. Someone mentioned the Plex Arcade. I didn’t see many people requesting this, but they spent considerable resources developing it and one day just brought it out. Bad enough that a big portion of the userbase can’t use it because we run our servers on linux/freebsd – that right there should have been a non-starter. A feature that’s only available for users running their servers on Windows and Mac (and yes, I know there are clients availale for Amazon Fire, Android, etc).
Plex, how about this. Since you can bring something like Plex Arcade, even though it 1) was not asked for, 2) can’t be used by a big portion of your users, give us something we’are actually asking for – and have been asking for it seems, for YEARS (almost 10).
And, while this isn’t the right place for this, but while we’re asking for things – give us the ability to run our own authentication server and not have to authenticate using your servers. How hard would it be to release an authentication server that we can run ourselves and not need to use your servers. That way, when there’s a problem with your servers, we don’t loose some of our functionality.
There are enough of us who have the skill to run this ourselves so we’re not dependant upon you. Kinda the spirit of the self-hosting community. This is one of the few services, regardless of what I do, there’s no way to get around having to send requests off my network for a service. We can selfhost almost everything else and/or replace commonly used features with something we have 100% control over.
