MySQL Support

[tomlawesome 2]

Hey,

It's really sad to read this thread and browse the numerous threads requesting either MySQL or Postgres over the years. I am new to Emby and came to the forum to find out if it was on the roadmap. I fully understand no one's said 'no' to it, but there are 6-7 year old posts requesting it and it's obvious that it's not going to happen (unless someone pays big money to sponsor it). Someone even did some work on it for free and it's kind of sad to see this labour was not capitalised on/supported from some Emby official resource: https://github.com/Tombert/embypostgres. Unfortunately they stopped without finishing. I understand the argument that it's not what all users want developer time spent on, but a lot can be achieved in 6-7 years and by now a meaningful number have requested it.

I've been trying out Emby premiere over the last few weeks, and it's a great app but I'm put off by the openly hostile dev responses I've seen in some threads (this one in particular) and the refusal to recognise that for some users this is a make or break feature long term. The argument that it's a minority request is weakened by some of the really niche features Emby does have, and the simple fact that years later people are still asking for an external database. I can understand treating it as a back burner project, but it appears there's been no work at all. 

Sadly as a result I have no confidence that two features I would like (OIDC and external DB) will be supported any time soon if ever and I guess I am forced to try Jellyfin instead of picking up an Emby lifetime license.

Who knows maybe JF will be terrible, but I'm sad to have to try it at all because otherwise Emby is excellent.

[rsvg 14]

8 minutes ago, tomlawesome said:

Hey,

It's really sad to read this thread and browse the numerous threads requesting either MySQL or Postgres over the years. I am new to Emby and came to the forum to find out if it was on the roadmap. I fully understand no one's said 'no' to it, but there are 6-7 year old posts requesting it and it's obvious that it's not going to happen (unless someone pays big money to sponsor it). Someone even did some work on it for free and it's kind of sad to see this labour was not capitalised on/supported from some Emby official resource: https://github.com/Tombert/embypostgres. Unfortunately they stopped without finishing. I understand the argument that it's not what all users want developer time spent on, but a lot can be achieved in 6-7 years and by now a meaningful number have requested it.

I've been trying out Emby premiere over the last few weeks, and it's a great app but I'm put off by the openly hostile dev responses I've seen in some threads (this one in particular) and the refusal to recognise that for some users this is a make or break feature long term. The argument that it's a minority request is weakened by some of the really niche features Emby does have, and the simple fact that years later people are still asking for an external database. I can understand treating it as a back burner project, but it appears there's been no work at all. 

Sadly as a result I have no confidence that two features I would like (OIDC and external DB) will be supported any time soon if ever and I guess I am forced to try Jellyfin instead of picking up an Emby lifetime license.

Who knows maybe JF will be terrible, but I'm sad to have to try it at all because otherwise Emby is excellent.

Don't hold your breath. If I even recommend common sense engineering solutions they threaten to ban my account. I've given up on Emby and am excited for a modern solution to present itself. And when I say modern, I mean so advanced that it matches the abilities of Wordpress in having a configurable DB lol.

[Meeko 34]

+1 for mysql support.

 

I have 25 users and increasing, i would like to move the database to another server.

[ebr 14912]

4 hours ago, Soldize said:

I have 25 users and increasing, i would like to move the database to another server.

Why do you believe moving the database remote to the process using it will be an improvement?

[sydlexius 241]

2 hours ago, ebr said:

Why do you believe moving the database remote to the process using it will be an improvement?

Speaking for myself, I have containers for MariaDB and Mongo that are used by yet other containers. This allows me to better orchestrate and backup production data. Further, it's a simple method to run reports without having to worry about concurrency. Personally, I'm fine with Emby, *arr's, and other apps having embedded databases, but I can see why others would want this flexibility.

[rsvg 14]

3 hours ago, ebr said:

Why do you believe moving the database remote to the process using it will be an improvement?

I wouldn't bite on such a ridiculous question. Obviously all things being equal, moving the db to another computer with no prior load would increase performance as long as latency weren't an issue. But I don't think performance is the most important consideration here, it's more about flexibility, modularity, and best practices. Services such as databases should be attached to applications as resources and live in configuration for easy migration.

Edited November 22, 2022 by rsvg

[ebr 14912]

46 minutes ago, rsvg said:

Obviously all things being equal, moving the db to another computer with no prior load would increase performance as long as latency weren't an issue

That's a huge assumption but all of this discussion is already in here.

46 minutes ago, rsvg said:

it's more about flexibility, modularity, and best practices. Services such as databases should be attached to applications as resources and live in configuration for easy migration

If this were an enterprise application, yes, I'd definitely agree.  But 99% of our users are not enterprise application managers.  Again, all that discussion is already in here too so we can just leave it at that.

Thanks.

[rsvg 14]

1 minute ago, ebr said:

If this were an enterprise application, yes, I'd definitely agree.  But 99% of our users are not enterprise application managers.  Again, all that discussion is already in here too so we can just leave it at that.

Thanks.

Well at least we agree that it's not built professionally. 

[softworkz 3335]

34 minutes ago, rsvg said:

I wouldn't bite on such a ridiculous question. Obviously all things being equal, moving the db to another computer with no prior load would increase performance as long as latency weren't an issue.

No, it wouldn't. That's an incorrect assumption - as long as we are talking about operational parameters in the range of typical Emby deployments and "all things being equal" regarding the 2nd machine - (and we're not talking about two single-core machines which a few hundred MB RAM only)

And RAM is actually the keyword here. Even with 100k items in your library, the main database is no more than 150 MB. That means that the whole database can be (and will be) kept In Memory and even in the memory of the same process that is consuming it.

Seriously - this couldn't be better: transferring data between two processes on the same machine is already way more expensive than one would think. And transferring data between two machines on the network is another magnitude more expensive.

So - no. This is not a ridiculous question. And no - you are obviously very wrong.

 

So many are trying to make an appearance as database experts here, and are attempting to give reasons why MySQL support would be so badly needed.
But none of all the "experts" has mentioned the #1 most valid case where I'd instantly say: "Yes. In that case, you will really need an external db".

[rsvg 14]

3 minutes ago, softworkz said:

So many are trying to make an appearance as database experts here, and are attempting to give reasons why MySQL support would be so badly needed.
But none of all the "experts" has mentioned the #1 most valid case where I'd instantly say: "Yes. In that case, you will really need an external db".

I specifically said performance isn't the most important aspect here. I've previously expressed interest in housing it in container orchestration like k8s. That is my number one interest. I don't care if my db isn't in memory. I just care that it's location is configurable. 

With all the time your team spends debating this topic any of my engineers could have implemented it, if you hadn't close sourced it that is.

Edited November 22, 2022 by rsvg

[softworkz 3335]

6 minutes ago, rsvg said:

Well at least we agree that it's not built professionally

I would agree to that when you're able to tell the reasons. Which are from your point of view....?

(the fact that it's SQLite is not a valid reason)

[ebr 14912]

9 minutes ago, rsvg said:

Well at least we agree that it's not built professionally. 

Build professionally and build for professional use are very different things. 

But, you aren't even the one to whom my question was directed so I'm still waiting to hear why @Soldize believes that moving the database to a different machine and architecture would be beneficial to them.

[rsvg 14]

Just now, softworkz said:

I would agree to that when you're able to tell the reasons. Which are from your point of view....?

(the fact that it's SQLite is not a valid reason)

No, the fact that the database type is so ingrained into the source code that it cannot be changed easily. Changing a database or adding it's ability to be configurable shouldn't be such a huge task imo.

I actually don't have a problem with sqlite and run it in my Pi projects all the time. 

[sfatula 185]

Deny. Deny. There is nothing anyone can say. They don't want to do it, plain and simple.

Some of us actually were actual database administrators / designers, long time. You can insult all you wish, but, denying it doesn't change reality. I find your post quite insulting. 
 

And yes, the question WAS ridiculous and a setup for your response no matter what anyone said, it was bait. There have been many reasons given in this thread. Many are certainly not must have, but they need to be taken as a whole. So many advantages. Must have, probably not actually but the app would be so much better for all the reasons given and many more. 

[rsvg 14]

Just now, ebr said:

Build professionally and build for professional use are very different things. 

But, you aren't even the one to whom my question was directed so I'm still waiting to hear why @Soldize believes that moving the database to a different machine and architecture would be beneficial to them.

He already responded that he runs mariadb for other things and would combine them.

[ebr 14912]

Just now, rsvg said:

He already responded that he runs mariadb for other things and would combine them.

Sorry, that was someone else.

[rsvg 14]

Does it matter? Your team has already stated that it won't add the feature because it's not a priority. You debating performance when it should be an optional configuration and could still default to sqlite is just distracting and useless. 

[sfatula 185]

1 minute ago, ebr said:

Sorry, that was someone else.

So, that makes their reason invalid? Let's ignore that one?

[ebr 14912]

Just now, sfatula said:

So, that makes their reason invalid? Let's ignore that one?

No.  But it isn't an answer to the question I asked because that person may have a completely different reason.

[rsvg 14]

You can just ignore him, it seems his job is to misdirect.

[sfatula 185]

1 minute ago, rsvg said:

You can just ignore him, it seems his job is to misdirect.

It does sound like maybe he was interested in knowing why. But, as a whole, I gave up long ago on this thread and am merely monitoring it. It feels like they don't want to just say no, but have. So, pick on posts where maybe the advantage isn't there (or much) and ignore/mock otherwise.  

I'd personally prefer it was just closed and they said we decide not to do this. Plain and clear and obviously it's their software.

[Luke 37064]

1 minute ago, sfatula said:

It does sound like maybe he was interested in knowing why. But, as a whole, I gave up long ago on this thread and am merely monitoring it. It feels like they don't want to just say no, but have. So, pick on posts where maybe the advantage isn't there (or much) and ignore/mock otherwise.  

I'd personally prefer it was just closed and they said we decide not to do this. Plain and clear and obviously it's their software.

There have been a lot of requests that were open for a long time and then got implemented, so never say never.

[sfatula 185]

9 minutes ago, Luke said:

There have been a lot of requests that were open for a long time and then got implemented, so never say never.

I understand but from the Emby responses given, for me personally, feels like it's a hard no. Honestly. Not saying that because I want this. There really is mis-direction and other similar posts throughout this thread. That was my point. It genuinely feels like this was decided long ago. If that was not intended, it has not come across at all. Speaking for just me. 
 

When someone wants to use as a point, things such as two processes on the same machine.... so, my Emby clients doing all the lookups and requests, retrieving the guide, filtering lists, etc, are on same machine as the sqlite database? Don't think so! And to then imply there is an unposted reason that means mysql is absolutely needed but unless someone says it, not going to do it makes zero sense. It all gives a feeling to me of we just don't want to. Which is ok, just say it. 

 

Edited November 22, 2022 by sfatula

[softworkz 3335]

 

20 minutes ago, rsvg said:

22 minutes ago, softworkz said:

I would agree to that when you're able to tell the reasons. Which are from your point of view....?

(the fact that it's SQLite is not a valid reason)

No, the fact that the database type is so ingrained into the source code that it cannot be changed easily. Changing a database or adding it's ability to be configurable shouldn't be such a huge task imo.

I actually don't have a problem with sqlite and run it in my Pi projects all the time. 

You hit the nail! It's an unfortunate truth, but it is a truth that turns this into a very fundamental effort. A significant part of the application logic is at the database level - where it normally shouldn't be. It's an anormal db design with a lot of history and totally unsuitable for outside and generic access. It's not modular, it's not layered, it's an intrinsic part of the application and not following usual conventions.

For all those reasons, you can not have "your engineer" get it done in a few hours (or days).

Despite all the things I mentioned, there's one important aspect that needs to be understood as well: it's done like it's done, but it's extremely optimized for this very purpose of Emby in every little detail. It will be not only tough, but probably even impossible to achieve the same level of performance with an external database (within the constraints of typical Emby use).

It's a huge effort. As simple as that.

[softworkz 3335]

13 minutes ago, sfatula said:

And to then imply there is an unposted reason that means mysql is absolutely needed but unless someone says it, not going to do it

I never said that it would be implemented when somebody would mention it.

14 minutes ago, sfatula said:

not going to do it makes zero sense

Yes, that would really make zero sense