3 comments

[ 5.3 ms ] story [ 14.4 ms ] thread
I wouldn’t call this next-gen SQLite. How can it be when the “QL” of SQLite is “Query Language” and this doesn’t have one? This is an object serialization library.
Point 1 may be a problem if you're embedded. Otherwise, enjoy the fact that the 150,000 lines of c-code are some of the most tested lines of code on the planet.

Point 2 doesn't tackle the reasons why there is a mismatch between in-memory representation and tabular data. Some benefits include the wins obtained from a schema built to utilize "normal form". Object databases have their place, but so do fully normalized database tables.

Point 3 doesn't strike me as useful. I don't find myself reverting rows to previous points in history that often, if I ever have. Tracking versions of rows is useful. I would argue that "reverting" is not, since the reverting would be better tracked by adding a new version as a forward update.

Overall, sure, a new, "light weight", object database that uses data structures* may have a place somewhere. But to replace SQLite? I think not.

*The Java API gives me the same recoil as Java JSON API. Pulling out data key by key feels like pulling teeth tooth by tooth.