[necubi]

I'm not very familiar with foundationdb, but I'm confident they're not using sqlite as the storage layer. That would come with a tremendous performance penalty. The docs say that "The SSD storage engine stores the data in a B-tree based on SQLite" which makes me think that they're just using the storage layer from SQLite (i.e., the part of it that corresponds to splinterdb/rocksdb).

[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.

[fooster]

Your confidence is misplaced. The storage layer is SQLite.

[leetrout]

They are leaving sqlite

In the upcoming FoundationDB 7.0 release, the B-tree storage engine will be replaced with a brand new Redwood engine.

https://apple.github.io/foundationdb/architecture.html#stora...