The quality and helpfulness of this mailing list makes me wish for a
SQHeavy...
IME when SQLite is applicable (mostly the one writer limit), it usually
runs circles around to server DBs, provided:
- you have comparable CPU
- you have enough cache memory, or free RAM for OS disk caching, to be in a
comparable memory scenario
- you do not have a virtualisation layer, especially
obviously it will never be perfect . We already know the benefits of
each database , including those of SQLITE . This is not because there is
a benchmark that people are not going to look at all the other features.
But in equal hardware, it gives a small indication of current
performance, as
On 16 Feb 2016, at 6:30am, olivier vidal wrote:
> It would be great if someone could redo these tests with the current versions
> of the databases.
On what hardware ? Should the SQLite test be on a laptop because SQLite will
run on a laptop ? Or should you test both on identical hardware
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
It would be great if someone could redo these tests with the current
versions of the databases.
Jim Callahan a ?crit :
> 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
On 15 Feb 2016, at 9:41pm, James K. Lowden 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.
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
On Mon, Feb 15, 2016 at 9:07 PM, Keith Medcalf wrote:
>
> 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
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. T
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
On Mon, 15 Feb 2016 11:21:06 +0800
wrote:
> I am just curious whether there is a performance comparison between
> SQLite and SQL Server?
Odds are you will never see a such a comparison published. If you read
your SQL Server EULA, you'll see it specifically prohibits publishing
ben
Hi,
I am just curious whether there is a performance comparison between SQLite
and SQL Server? Surely SQL Server will perform better on huge database with
thousands of tables(more than 10GB size). But whether SQLite will perform
better on smaller database such as one database with one table
On 2016/02/15 5:21 AM, admin at shuling.net wrote:
> Hi,
>
> I am just curious whether there is a performance comparison between SQLite
> and SQL Server? Surely SQL Server will perform better on huge database with
> thousands of tables(more than 10GB size). But whether SQLi
admin at shuling.net wrote:
> I am just curious whether there is a performance comparison between SQLite
> and SQL Server?
That depends on the data, and the software, and the hardware.
In other way: you have to measure yourself.
> Surely SQL Server will perform better on huge
the right tool for the
right job. After saying that we *may* end up using SQLite for this area
as well.
Rob
On 15 Feb 2016, at 8:20, R Smith wrote:
> On 2016/02/15 5:21 AM, admin at shuling.net wrote:
>> Hi,
>>
>> I am just curious whether there is a performance comparison between
They're intended for fundamentally different uses. It's like asking what's
more energy efficient for cooking dinner - a wok or an oven.
On Mon, 15 Feb 2016 at 14:21 wrote:
> Hi,
>
> I am just curious whether there is a performance comparison between SQLite
> and SQL Server? Surel
On Feb 15, 2016, at 1:02 AM, Clemens Ladisch wrote:
>
> SQLite uses a much simpler locking scheme that can be faster if there
> aren't concurrent accesses. SQL Server has higher concurrency.
SQLite also doesn?t have the IPC overhead of a client/server DBMS, so if you
don?t need concurrency or
18 matches
Mail list logo
