I just checked a stripped copy of postgresql-10 built with all options on and it is 7MB. That could be reduced a little by leaving out language support and ssl support etc.
While binary size could certainly be a factor in a good deal of embedded environments, we also need to look at the resource requirements of the binary in question as well.
Sqlite doesn't need too much more memory than what its binary needs whereas with postgresql, you need all sorts of bells and whistles just to get the database system to boot.
Well, sure, sqllite is smaller than postgres, but database system performance is largely dictated by the size of the buffer cache. For something like a configuration database (a great use of sqllite) this does not matter. But for more than a very modest amount of data more memory for buffers will benefit both postgresql and sqllite.
Anyway, not trying to make the case that postgresql is small compared to sqllite, it obviously isn't, just wanted to point out that it's not _that_ big either.
If you look at the build instructions you will see that in the ./configure step you can enable and disable different features. Try ./configure --help to get a list.
It is dynamically linked to openssl, but you can configure out the internal code to support the functionality.
"strip" however meant the unix strip command to remove debug symbols.
To me, what makes it 'lite' is that it doesn't have a client-server architecture that requires a running daemon. It's just a file format and a library designed to interact with it.
I just had a look at the executable of my latest - extremely simple - webapp. A 64 bit elf, statically linked with Musl libc and SQLite, written in Nim.
1.4MB all told, with no optimizations whatsoever. In the year 2018 AD, we count that as light.
I could swear I've seen you say this. Maybe I'm mis-remembering? ISTR it was that for each table source in a query SQLite3 uses just one index (or the table itself) for indexing or scanning to find relevant rows in that table source.
SQLite can use multiple indexes if there are OR terms in the WHERE clause.
SQLite tries to only uses indexes in situations where they help the query run faster. SQLite is not limited in its use of indexes. It is just that the use of multiple indexes for a single FROM-clause term is rarely helpful.
