I know that using
LocalDb is very good and easy for developement, I wonder if it’s good idea to use it in production when I host websites on IIS server?
I’m asking because I wonder if it won’t have any kind of speed issues in production.
This is my connection string that I want to use in production
Server=(LocalDB)\v11.0;Integrated Security=SSPI;MultipleActiveResultSets=true; AttachDBFilename=|DataDirectory|ProjectDB.mdf;
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
LocalDB is absolutely supported in production. From the performance point of view it is identical to SQL Server Express, as they share the same database engine.
Now, for a site running in full IIS I would recommend using service-based instance of SQL Server Express. Since IIS is running as a service it is best to have a service-hosted database as well. That means you should not be using
User Instance=true or
AttachDbFileName=... in your connection string.
“Normal” – hard to say, that’s a relative term.
Permitted – yes. Here is a quote from the Microsoft SQL Server Express blog where LocalDB was introduced:
“…if the simplicity (and limitations) of LocalDB fit the needs of the target application environment, developers can continue using it in production, as LocalDB makes a pretty good embedded database too.“
UPDATE (March 2019)
After using LocalDB in dozens of production sites for two solid years now, I’ll confirm that it works. However, if you need a free multi-user (“shared” in LocalDB terminology) DB, use SQL Server Express instead. LocalDB is not a good multi-user solution. There are MANY obstacles to overcome. I don’t have time now, but if you would like details on those obstacles and respective workarounds, leave a comment, and I’ll document them here or in another question.
UPDATE (April 2021)
Showstopper — the shared (i.e., multi-user) instance feature is broken in SQL Server LocalDB 2017 and 2019. Having one of those versions installed will even prevent accessing a shared instance created in an earlier version. The problem is documented here. The only known “workaround” is to uninstall the broken LocalDB versions, and use LocalDB 2016 or earlier.
UPDATE (September 2021)
There is now a fix for the Showstopper issue mentioned in the preceding update (UPDATE April 2021). Caveat: I have not personally tested this fix.
I don’t think so,
Even though LocalDb and SQLExpress might be the same on performance, LocalDb’s Process shuts down itself if it doesn’t have any request for a while. And usually the next request takes too long to response (or even worse, it times out).
I would recommend you install your own instance of SQLEXPRESS.