MySQL Support

[softworkz 5066]

1 hour ago, shocker said:

To be honest since the request of mySQL there were tons of improvements and changes into the Emby server. Maybe by that time it was a need due to poor performance with large libraries, but nowadays the software is way more faster.

I think we the users need to better to explain why we need mySQL as it might be easier to develop something in addition that changing the entire DB. This seems to be a massive effort and it's not something that it will happen in the near future. 

Right. But even when it's better explained, we need to consider the dimensions of demand. When a change requires massive development time but would provide benefit to a minimal fraction of Emby users only, then it would not be fair to spend the money from all other users for something they wouldn't have any benefit from.

If the majority of Emby users had databases with multi-million media items, then we wouldn't have this discussion and it would have been implemented long ago.

 

1 hour ago, shocker said:

There are lot of things to do on Emby where most of us will benefit and the dev time invested on doing this change just for "a feature" might not worth it.

Exactly. I don't know what 3 is, and 4/5 are more for "professional" use cases but the other points make a lot more sense than a db change.

[adminExitium 355]

1 hour ago, shocker said:

JellyFin implemented meilisearch

That's not exactly right. There are 2 different plugins developed by external devs. There's nothing stopping anyone here from developing something similar for Emby, if they wish so.

What I would instead like from Emby here is some kind of pluggable search provider functionality, which allows users to plugin the search provider of their choice (be it the native SQLite FTS or Meilisearch or Typesense etc.).

[shocker 135]

17 minutes ago, adminExitium said:

That's not exactly right. There are 2 different plugins developed by external devs. There's nothing stopping anyone here from developing something similar for Emby, if they wish so.

What I would instead like from Emby here is some kind of pluggable search provider functionality, which allows users to plugin the search provider of their choice (be it the native SQLite FTS or Meilisearch or Typesense etc.).

You are right but keep in mind that it was implemented into the mobile apps for support as well (this can only be done by the Emby team). I don’t want to discuss this here as it’s not the point. I used this as example of the functionality. 
 

You are perfectly right to have a pluggable search provider, but this is the long term discussion, currently I have just shared a feedback.

[softworkz 5066]

As much as I like and advocate plugin extensibility, I think that our built-search should be working well enough that nobody would ever come to ask   about a plugin for doing the job  

[shocker 135]

8 minutes ago, softworkz said:

As much as I like and advocate plugin extensibility, I think that our built-search should be working well enough that nobody would ever come to ask   about a plugin for doing the job  

Except me

[softworkz 5066]

2 minutes ago, shocker said:

10 minutes ago, softworkz said:

that nobody would ever come to ask   about a plugin for doing the job  

Except me

Then it might not be good enough.. 

 

What I can say on the good side is that we have made some progress recently with regards to large databases in our development loop:

We have received some larger DBs from users for internal testing and we have created a new tool which allows us to replicate library structures on the file system (using stub media files) - so eventually, that's still good news for all those having large library databases, as there's active development and more attention been put on those cases.

[Dibbes 514]

22 hours ago, softworkz said:

Then it might not be good enough.. 

 

What I can say on the good side is that we have made some progress recently with regards to large databases in our development loop:

We have received some larger DBs from users for internal testing and we have created a new tool which allows us to replicate library structures on the file system (using stub media files) - so eventually, that's still good news for all those having large library databases, as there's active development and more attention been put on those cases.

Yes, I'd like access, please! 

[softworkz 5066]

32 minutes ago, Dibbes said:

Yes, I'd like access, please! 

There's nothing special to access. New work gets into the betas like normal.

[Dibbes 514]

15 hours ago, softworkz said:

There's nothing special to access. New work gets into the betas like normal.

Superb! Thank you!

[nunuxx 7]

@softworkzIs there a big difference about performance between 4.8 (stable) and the 4.9 (beta)

[softworkz 5066]

2 hours ago, nunuxx said:

@softworkzIs there a big difference about performance between 4.8 (stable) and the 4.9 (beta)

I haven't been much involved other than a few query optimizations (without even knowing the specific use cases).

@Lukewill have the big picture.

[Luke 42077]

2 hours ago, nunuxx said:

@softworkzIs there a big difference about performance between 4.8 (stable) and the 4.9 (beta)

4.9 should perform better, yes.

[shocker 135]

5 minutes ago, Luke said:

4.9 should perform better, yes.

Way better for sure, I can confirm that is 30-40% faster in general.  

[nunuxx 7]

30/40% is really big

 

@Lukewhen will we have 4.9 into stable?

Or maybe you are on the road to 5.0 ?

I don't see anything about 5.0 ?

Edited September 24, 2025 by nunuxx

[Luke 42077]

33 minutes ago, nunuxx said:

30/40% is really big

 

@Lukewhen will we have 4.9 into stable?

Or maybe you are on the road to 5.0 ?

I don't see anything about 5.0 ?

Shooting for any day now.

[Dibbes 514]

On 9/24/2025 at 7:30 PM, nunuxx said:

30/40% is really big

 

@Lukewhen will we have 4.9 into stable?

Or maybe you are on the road to 5.0 ?

I don't see anything about 5.0 ?

We've been asking this for a long time in the TV Next thread... lol

[Dibbes 514]

On 9/24/2025 at 7:12 PM, shocker said:

Way better for sure, I can confirm that is 30-40% faster in general.  

@Luke@softworkz But honestly, the database improvements over the last 2 or 3 betas have been enormous! Library scan times seem to have halved (is it scanning two or three libraries at once, depending on CPU utilisation?) and the page loading is now a lot more fluid... I like it a lot, thanks for that!