SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Single User Performance of SQLite v. SQL Server


Single User Performance of SQLite v. SQL Server

Author
Message
timothyawiseman
timothyawiseman
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2384 Visits: 920
Comments posted to this topic are about the item Single User Performance of SQLite v. SQL Server

---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
ooneill
ooneill
Grasshopper
Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)

Group: General Forum Members
Points: 11 Visits: 5
0.718 secs for 5000 inserts SQL Server (commit once)
0.047 secs for 5000 inserts SQLite (commit once)

"it goes from being substantially slower than SQL Server to slightly faster."

..... for 'slightly' read 15x faster ! For any 'embedded' application sqlite knocks the spots off SQL server - but it it really is an apples and oranges comparison.
iposner
iposner
SSC Veteran
SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)SSC Veteran (297 reputation)

Group: General Forum Members
Points: 297 Visits: 127
The whole basis of this article is undermined because the author picked an unsuitable edition of SQL Server for comparison: SQL Server Compact would be the equivalent product and would have made for a more interesting article.
ddriver
ddriver
SSC Journeyman
SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)

Group: General Forum Members
Points: 97 Visits: 250
This really misses the point. SQLite is an embedded data store in a single C library. SQL server is, well... A server. It has an instillation and configuration process, can be accessed by multiple processes, has granular permissions and a whole bunch of very important stuff.

If you don't need that stuff and you can just use the embedded data store, just use SQLite and get on your way. This is worse than an apples to oranges comparison. More like apples to an apple stand.

SQLite is great for what it does, I have used it many times. But I am not really sure about the utility of comparing it to SQL Server.
charles.byrne
charles.byrne
SSC Journeyman
SSC Journeyman (78 reputation)SSC Journeyman (78 reputation)SSC Journeyman (78 reputation)SSC Journeyman (78 reputation)SSC Journeyman (78 reputation)SSC Journeyman (78 reputation)SSC Journeyman (78 reputation)SSC Journeyman (78 reputation)

Group: General Forum Members
Points: 78 Visits: 172
I use SQL server Access and Oracle, but I have used SQLite and considering the size and function SQLite. It has it's place and again, the footprint is so small. It is great for embedding in smart phone apps, for retaining settings on webservers and client apps for quick prototypes as well. Another benefit is that it can be used on most platforms.

As suggested earlier I would also suggest doing more performance metrics but against SQL CE

Also the newer versions of SQLite (3.7) has Write ahead locking

And there's nothing like being able to drag and drop a few files and your
code runs without having to install SQL server on 150 users desktops
with different OS versions just to read a table.

We still lean heavily on MS Access but there is a lot of code maintenance with ever newer releases since we have different versions in use.

"There is nothing so useless as doing efficiently that which should not be done at all." - Peter Drucker
krefior
krefior
SSC Veteran
SSC Veteran (221 reputation)SSC Veteran (221 reputation)SSC Veteran (221 reputation)SSC Veteran (221 reputation)SSC Veteran (221 reputation)SSC Veteran (221 reputation)SSC Veteran (221 reputation)SSC Veteran (221 reputation)

Group: General Forum Members
Points: 221 Visits: 199
Nice article and thank you for putting together the comparison.

One of the reasons that any embedded solution will be faster is related to the overhead of client/server communications... There is a penalty for every connection to SQL Server. For small record sets and optimized code it's very hard to overcome that penalty. I'm curious if instead of 5000 rows if your query were a million rows (Not that much today) would SQL come back out on top?

Of course another reason that embedded solutions are faster has to do with SQLserver being optimized for Muti-User, To compare to an embedded solution the database should be put into Single-User mode.
Mike Good
Mike Good
SSCommitted
SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)

Group: General Forum Members
Points: 1703 Visits: 1042
Nice article, very interesting.



timothyawiseman
timothyawiseman
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2384 Visits: 920
iposner (7/19/2012)
The whole basis of this article is undermined because the author picked an unsuitable edition of SQL Server for comparison: SQL Server Compact would be the equivalent product and would have made for a more interesting article.


You make an excellent point. I may have to take a look at compact edition.

---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
timothyawiseman
timothyawiseman
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2384 Visits: 920
ddriver (7/19/2012)

If you don't need that stuff and you can just use the embedded data store, just use SQLite and get on your way. This is worse than an apples to oranges comparison. More like apples to an apple stand.

SQLite is great for what it does, I have used it many times. But I am not really sure about the utility of comparing it to SQL Server.


A fair point. The reason I started looking into it is that I had been writing all of my applications against SQL Server until I started getting requests to write applications that would be used by only one at a time for certain niche functions. So, for those I started playing with SQLite, and readily having the option of either I wanted to know the performance implications of the choice.

---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
timothyawiseman
timothyawiseman
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2384 Visits: 920
krefior (7/19/2012)
Nice article and thank you for putting together the comparison.

One of the reasons that any embedded solution will be faster is related to the overhead of client/server communications... There is a penalty for every connection to SQL Server. For small record sets and optimized code it's very hard to overcome that penalty. I'm curious if instead of 5000 rows if your query were a million rows (Not that much today) would SQL come back out on top?


I have not tried a million rows yet, but for half a million the basic trend stayed the same.

---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search