[4khilles]

I did see a full copy of the SQLite amalgamation file in the FDB codebase, but you're probably right that they might be using internal APIs.

I'm still skeptical of the "tremendous performance penalty" you'd suffer from using SQLite. Just because you do fewer things doesn't necessarily mean you're faster at doing them. I've hit ~120,000 inserts/sec on SQLite without weakening any of it's durability guarantees. If you play fast and loose with fsync and WAL, I'm sure you can squeeze out even more performance.

I can also think of use-cases where you don't want the write amplification that comes with RocksDB or the memory constraints of LMDB.

[stingraycharles]

I am not familiar with SplinterDB, but I do have a lot of familiarity with RocksDB. These types of k/v storage layers are designed to handle hundreds of thousands of not millions of operations per sec. Especially the way they handle writes (typically with an LSM) is very different from SQLite, and it shows in terms of throughput of e.g. random writes.

I'd say that these low-level storage engines have more in common with filesystems than SQLite, they're just not in the same ballpark at all.