Comment by samuelstros

Does the following make more sense to you in respect to SQL?

Lix uses SQL databases as storage and query engine. Aka you get a filesystem on top of your SQL database that is version controlled.

Or, the analogy to git: Git uses the computers filesystem as storage layer. Lix uses SQL database (with the nice benefit of making everything queryable via SQL).

> Lix doesn't reinvent databases — durability, ACID, and corruption recovery are handled by battle-tested SQL databases.

>> This seems like a left turn from the value prop and why the value prop matters?

Better wording might be "Lix uses a SQL database as storage layer"?

The SQL part is crucial for two reasons. First, the hard part like data loss guarantees, transactions, etc. are taking care of by the database. We don't have to build custom stuff. Which secondly, reduces the risk for adapters that data loss can occur with lix.

> As for how it works, both in the docs and in the comment I'm replying to, it's unclear how any of this interacts with the native version control embedded in M365 apps or why this tool can be trusted as effective at tracking M365 content changes.

It doesn't interact with version control in M365.

I'll update the positioning. Lix is a library to embed version control in whatever developers are building. Right now, lis is mostly interesting for startups that build AI-first solutions. They run into the problem "how do customers verify the changes AI agents make?".

The angle of universal version control, and using docx or Excel as an example, triggers the wrong comparisons. By no means is Lix competing with Sharepoint or existing version control solutions for MS Office.