
Sqlite – Most Deployed Database in the World - gitgud
https://www.sqlite.org/mostdeployed.html
======
simonw
I also like this page of the docs: "SQLite as an application file format":
[https://www.sqlite.org/appfileformat.html](https://www.sqlite.org/appfileformat.html)

~~~
hardwaresofton
Also on my list of favorites:
[https://www.sqlite.org/whentouse.html](https://www.sqlite.org/whentouse.html)

Back when I worked at a large semi conductor company they used GDSII[0] and
Calibre[1] files along with internal formats and I always wondered why they
wouldn't just use SQLite. SQLite is even threadsafe[2].

[0]:
[https://en.wikipedia.org/wiki/GDSII](https://en.wikipedia.org/wiki/GDSII)

[1]:
[https://www.mentor.com/products/ic_nanometer_design/verifica...](https://www.mentor.com/products/ic_nanometer_design/verification-
signoff/)

[2]:
[https://www.sqlite.org/threadsafe.html](https://www.sqlite.org/threadsafe.html)

------
sudeepj
[https://www.sqlite.org/testing.html](https://www.sqlite.org/testing.html)

The testing each release goes through is quite impressive. I bet more time is
spent on testing (or writing tests) than actually developing the features.

~~~
fuddle
"the project has 711 times as much test code and test scripts" than source
code. That's a really impressive feat.

~~~
monocasa
Huh, at that point it'd probably make more sense to formally verify it. For
sel4 last time I checked the ratio was 25/1 proof code/verified code.

~~~
krylon
SQLite is used on many platforms, built using many compilers. All of those
compilers might have bugs themselves (who am I kidding? They _do_ ), something
verification cannot account for.

~~~
monocasa
Sel4 takes the compiler out of the trusted computing base as well as well by
verfying the binary directly.

Additionally, the majority of that test code is closed source, so it isn't
getting run on nearly all the platforms sel4 supports anyway.

~~~
krylon
Thanks, I did not know that.

------
xkcd-sucks
I would contribute towards a Wall St Journal full page ad "SQLite: Most widely
used DB in the world" with little misleading graphs comparing to Oracle and
DB2

~~~
darkpuma
Trying to make Larry Ellison blow a fuse?

~~~
kakwa_
He has reasons to, given that Oracle owns BerkeleyDB which used to dominate
the embedded DB use case in the past, being often replaced by sqlite.

------
baldfat
I love sqlite. It is far to under used. It scales incredibly well and if you
out grow you can easily move it into a different dB system.

~~~
wenc
There is a way that it does not. It is flexibly typed so you can insert a
string into an integer column. This is by design.

This also means you’ll run into trouble when you try to move it to most SQL
databases which are strongly typed.

~~~
solarkraft
> This is by design.

Oh god, why?

------
virtualwhys
> SQLite is likely used more than all other database engines combined.
> Billions and billions of copies of SQLite exist in the wild. SQLite is found
> in:

> Every Firefox, Chrome, and Safari web browser

Where is SQLite in Firefox? It would be wonderful to use SQL in the browser,
on the server, in mobile devices (everywhere!), but alas I suspect SQLite can
be "found" in Firefox as the underlying storage engine on top of which
IndexedDB is built.

Dammit Mozilla, set SQLite free!

~~~
quietbritishjim
I believe that quotation is just saying that Firefox uses SQLite to store some
of its internal state, not that it has an API to interact with general SQLite
databases.

~~~
virtualwhys
> not that it has an API to interact with general SQLite databases

Well, it did, but they removed it, and in fact spearheaded the movement to
deprecate WebSQL circa 2010...when Firefox had significant marketshare. Chrome
and Safari still, 10 years later, ship with WebSQL support, which makes it
pretty clear which side of the fence they're on.

------
qwerty456127
This makes me wonder why there are no alternative implementations of it (i.e.
I felt like I would appreciate a .Net-native implementation many times).

~~~
jasode
A C# native port[0] of Sqlite was attempted in 2009 and eventually abandoned
in 2012. It was a lot of work and the developer didn't get 100% of the
verification tests to pass.

To be fair to the programmer, he said the C-to-C# translation was mostly a
self-learning exercise rather than a serious attempt at creating a production-
quality library.

I think the obvious answer is that there's no market demand for a C# native
version of SQLite. People just use the C# ADO.NET wrapper that calls the
"unsafe" C compiled DLL[1]. Using that method, it's easier to stay up-to-date
with the canonical C source code that has the latest bug fixes and new
features. If you look at high frequency of updates in the release history[2],
you can see that constantly porting the new C code to C# to maintain feature
parity would be a tremendous amount of work.

Also, if you create a C to C# port, it means using the _C Language style API
such as "sqlite3_open()"_ instead of the more natural C# paradigm of ADO.NET
_" new SQLiteConnection(@"Data Source=x")"_. Somebody would than have to write
_another ADO.NET wrapper_ to specifically interface with the C# port of
SQLite.

[0] [https://code.google.com/archive/p/csharp-
sqlite/](https://code.google.com/archive/p/csharp-sqlite/)

[1]
[https://system.data.sqlite.org/index.html/doc/trunk/www/down...](https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki)

[2] [https://www.sqlite.org/changes.html](https://www.sqlite.org/changes.html)

~~~
qwerty456127
> Also, if you create a C to C# port, it means using the C Language style API

Is this really necessary? Is it impossible to just write a .Net-native library
with whatever an API that would just open an SQLite file and run SQL queries
against it? As for me that's all I ever needed of it.

~~~
jasode
_> Is it impossible to just write a .Net-native library with whatever an API_

It's not impossible but the issue is whether it's worth the amount of effort
involved. So yes, you can theoretically write the C# code in any way that
makes a convenient API for the C# coder.

But when attempting real-world implementations, there are varying degrees of
difficulty/maintainability of porting the C code to C#. You want to balance
the _tradeoffs_ of minimizing the C# programming code effort and _maximizing
the leverage of the original C source code_. The effort continuum would look
something like this:

\- easy: unsafe C DLL with C# ADO.NET wrapper (the 'C' source code is mostly
unchanged and is leveraged for highest reuse; this is what we have today)

\- harder: straight C-to-C# port with extra C# code to provide an ADO.NET
wrapper (an automated tool can attempt to transpile most of the C into C#
which is followed up by a human programmer to manually fix/code the parts the
transpiler couldn't; this effort was attempted in 2009 and the incomplete
project was eventually abandoned)

\- hardest: C-to-C# total rewrite where the programmer built in an ADO.NET api
(or whatever API the C# programmer wants to expose). In this way the original
SQLite C source is more of a "specification" rather than an input file to a
transpiler.

The "harder" effort which wasn't even 100% complete was abandoned. It means
the "hardest" implementation, while technically not impossible, is even more
unrealistic for anyone to code and maintain. That last method of C# rewrite
has immense costs and would fall further and further behind the original C
source code in feature parity and bug fixes.

To answer your question on why there are no alternative implementations: it's
because it's a lot of programming work that nobody wants to do.

------
ksec
I wonder why there aren't more DB like bedrock which builds on top of SQLite.

[https://github.com/Expensify/Bedrock](https://github.com/Expensify/Bedrock)

~~~
stickupkid
LXD has a distributed cluster system built upon SQLite[1], that's based on the
raft consensus protocol.

1\. [https://github.com/CanonicalLtd/go-
dqlite/](https://github.com/CanonicalLtd/go-dqlite/)

------
simonebrunozzi
Most = highest number of installations. I bet the winner for largest amount of
data managed could be another one (Oracle? MySQL?)

~~~
fl0wenol
It might still be SQLite in that case. The largest data management systems are
proprietary (i.e. Google's ever-evolving data layer)

------
jayonsoftware
"Every Windows10 machine" , did not know that, where is it located ?

~~~
tantalor
It's built into UWP

[https://docs.microsoft.com/en-us/windows/uwp/data-
access/sql...](https://docs.microsoft.com/en-us/windows/uwp/data-
access/sqlite-databases)

------
mistrial9
also see GeoPackage
[https://en.wikipedia.org/wiki/GeoPackage](https://en.wikipedia.org/wiki/GeoPackage)

------
misterkolaz
Most of android apps use it as well ;)

------
n-gate
Isnt it Microsoft windows registry?

~~~
mkl
No, even if you count that as a database, it isn't the most deployed. Look at
the list in the article. SQLite is on every Android device and Windows 10
device, and many/most personal computers with other operating systems
(including earlier Windows versions). There are more Android devices in use
than Windows ones: [https://www.computerworld.com/article/2919104/windows-
pcs/wh...](https://www.computerworld.com/article/2919104/windows-pcs/where-
will-microsoft-find-1-billion-devices-for-windows-10.html)

------
InGodsName
I don't think Sqlite will maintain this position for long.

Apps are moving to LSM based storage engines.

RocksDB or Badger are the future.

Now, you just need to make embedded DB with Sqlite API using rocksdb/badger
and sell it as direct competitor to Sqlite.

It will be a dropin replacement for Sqlite, written in a safer (hacker hype)
language.

For more Omph, use Rust as a language for this and create libaries using FFI
for python/ruby/node/c#

~~~
pdimitar
> _and sell it as direct competitor to Sqlite_

Pretty sure selling it won't work. For many, a convenient mini-storage is an
afterthought during a product development and it doesn't warrant a cost.

~~~
InGodsName
_Selling_ as in marketing it to same crowd.

