On the other hand if you drive either on a road with a speed limit of 30 miles per hour (and go the speed limit), they both go the same distance in the same time.
In other words, inquiring "which gets from one side of town to the other" the fastest, a Ferrari or an F-150, is not dependent on either the Ferrari or the F-150, but the infrastructure on which they are travelling. A similar question would be "which weighs more, a ton of feathers or a ton of depleted uranium?". So the answer is that both SQL Server and SQLite will "travel" at the "speed limit" imposed by the hardware on which they are run. > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Eric Sink > Sent: Monday, 15 February, 2016 20:52 > To: SQLite mailing list > Subject: Re: [sqlite] Performance comparison between SQLite and SQL > Server? > > Just for fun: > > I know a friend who has a Ferrari. It is faster than my Ford F-150. > > Unless we are racing with both vehicles pulling a 7,000 pound trailer > uphill. Then I would probably win. > > Thousand-mile trip? Take a sports car. > > Moving a couch a thousand miles? Use a pickup truck. > > SQLite is kinda like a sports car. > > SQL Server is kinda like a pickup truck. > > And this car metaphor of mine is kinda like a motorcycle -- if you lean on > it too hard, it'll probably fall over. > > -- > E > > > On Mon, Feb 15, 2016 at 5:24 PM, Michael Falconer < > michael.j.falconer at gmail.com> wrote: > > > Good thread, > > > > which absolutely nails the point 'dev decisions for app cases' make a > > developers world go round. I personally couldn't think of a greater > waste > > of time than a benchmark comparison between client server rdbms's and > > sqlite. Do what benefits your case most. The above from Jim pretty much > > encapsulates my thoughts: > > > > "SQLite is not directly comparable to client/server SQL database engines > > > such as MySQL, Oracle, PostgreSQL, or SQL Server since SQLite is > trying > > to > > > solve a different problem. Client/server SQL database engines strive > to > > > implement a shared repository of enterprise data. ...SQLite strives to > > > provide local data storage for individual applications and devices." > > > > > > > I could bang on about my own preferences and decisions I've made but > they'd > > only be reiterating the points made above. They were based on system > > requirement specs and where local storage was involved it was a > blindingly > > obvious decision to go with sqlite. Rob above made another excellent > point > > often overlooked (usually an afterthought for many dev's): > > > > 4. The support is top notch. I have brought and paid for govt scale > > > databases for governments and to be honest the support for SQLite is > just > > > as good, and to be honest I would say better than Big Red or Big Blue > > (and > > > I used to work for Big Blue). > > > > > > > It is another unique property of a great product. Support is not just > > sqlite specific either (a cop out on many a tech forum) and particularly > on > > this list the topics can be rather broad. There is plenty of good > quality > > feedback and many a good general SQL solution which just adds to the > sqlite > > package as a whole. > > > > > > On 16 February 2016 at 09:42, Jim Callahan > <jim.callahan.orlando at gmail.com > > > > > wrote: > > > > > SQLite would be most comparable to *SQL Server Express LocalDB* > edition > > > which is introduced in this July 2011 blog post > > > > > > > > https://blogs.msdn.microsoft.com/sqlexpress/2011/07/12/introducing- > localdb-an-improved-sql-express/ > > > > > > More uptodate information about *SQL Server Express LocalDB* edition > > > is in this 2016 Microsoft Developer's Network (MSDN) article > > > https://msdn.microsoft.com/en-us/library/hh510202.aspx > > > > > > This page "*Appropriate Uses for SQLite*" (whentouse.html) describes > BOTH > > > "*Situations Where SQLite Works Well*" > > > > > > and > > > > > > "*Situations Where A Client/Server RDBMS May Work Better*" > > > http://sqlite.org/whentouse.html > > > > > > > > > Opening lines of whentouse.html: > > > > > > "SQLite is not directly comparable to client/server SQL database > engines > > > such as MySQL, Oracle, PostgreSQL, or SQL Server since SQLite is > trying > > to > > > solve a different problem. Client/server SQL database engines strive > to > > > implement a shared repository of enterprise data. ...SQLite strives to > > > provide local data storage for individual applications and devices." > > > > > > Even Microsoft has adopted SQLite for some limited tasks (such as > storing > > > state) within every shipping copy of Windows 10. > > > "SQLite is a unique case: it is an open source, externally developed > > > software that is used by core system components, and our flagship apps > > like > > > Cortana and Skype. ...After shipping SQLite as a system component in > > July, > > > we wanted to include it in our SDK for November. With more than 20,000 > > > Windows Apps and more than half of our top apps using SQLite, it made > > sense > > > to just make expose the system SQLite to app developers." > > > http://engineering.microsoft.com/2015/10/29/sqlite-in-windows-10/ > > > > > > > > > There is a historical and unfair (specially compiled version of SQLite > > > against default settings of PostgreSQL) benchmark > > > available on this page, but now that you understand the use cases, > this > > > particular benchmark is not that useful in addition > > > to being out of date and unfair. > > > https://www.sqlite.org/speed.html > > > > > > Jim Callahan > > > Data Scientist > > > https://www.linkedin.com/in/jamesbcallahan > > > Orlando, FL > > > > > > On Mon, Feb 15, 2016 at 4:54 PM, Simon Slavin <slavins at bigfraud.org> > > > wrote: > > > > > > > > > > > On 15 Feb 2016, at 9:41pm, James K. Lowden > <jklowden at schemamania.org> > > > > wrote: > > > > > > > > > SQL Server has none of those restrictions, and probably keeps pace > > with > > > > > SQLite even on its home turf. But the administration of SQL > Server > > is > > > > > nontrivial. For that reason alone, I would never use it in > > situations > > > > > where SQLite would do. > > > > > > > > That's the fella. Major advantage of SQLite: zero admin. Not even > a > > > > background task. > > > > > > > > Second advantage: you know exactly where you data is. Better still, > > it's > > > > simple: one database == one file, and the file has the same name as > the > > > > database. I remember trying to reconstruct a MySQL database from a > > dead > > > > server. One folder with a confusing mass of files in. Your > database > > is > > > > part of some of those files, but the files may be huge even if the > one > > > > database you care about is tiny. That was not a fun time. > > > > > > > > Simon. > > > > _______________________________________________ > > > > sqlite-users mailing list > > > > sqlite-users at mailinglists.sqlite.org > > > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users at mailinglists.sqlite.org > > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > -- > > Regards, > > Michael.j.Falconer. > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
