No network, no write concurrency, no types to speak of... Where those things aren't needed, sqlite is the de facto standard. It's everywhere.

▲

mickeyp 9 hours ago | parent | next [-]

Perfect summary. I'll add: insane defaults that'll catch you unaware if you're not careful! Like foreign keys being opt-in; sure, it'll create 'em, but it won't enforce them by default!

▲

ogogmad 8 hours ago | parent [-]

Is it possible to fix some of these limitations by building DBMSes on top of SQLite, which might fix the sloppiness around types and foreign keys?

	▲	Polizeiposaune 7 hours ago \| parent [-]
		Using the API with discipline goes a long way. Always send "pragma foreign_keys=on" first thing after opening the db. Some of the types sloppiness can be worked around by declaring tables to be STRICT. You can also add CHECK constraints that a column value is consistent with the underlying representation of the type -- for instance, if you're storing ip addresses in a column of type BLOB, you can add a CHECK that the blob is either 4 or 16 bytes.

▲

BenjiWiebe 7 hours ago | parent | prev [-]

SQLite did add 'STRICT' tables for type enforcement.

Still doesn't have a huge variety of types though.

	▲	mikeocool 6 hours ago \| parent [-]
		The fact that they didn’t make STRICT default is really a shame. I understand maintaining backwards compatibility, but the non-strict behavior is just so insane I have a hard time imagine it doesn’t bite most developers who use SQLite at some point.