Comment by samuelstros
17 days ago
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.
Tracking versions is easy. Controlling versions is hard. Knowing what the actual semantic deltas are in binary files (what your doc examples claimed) is hard.
Now you say you're not tackling that problem, so the docs are doubly weird.
Would also imagine less of this is a SQL-shaped problem, per se, so plenty tech is better for tracking and controlling changes than SQL. The shape of the problem seems less theory of querying sets, more branching journal with proof chain, or hash tree.
> Knowing what the actual semantic deltas are in binary files (what your doc examples claimed) is hard.
Hm that is what lix provides?
SQL is just the interface to query the deltas.
Anyhow, lesson learned. The primary use case for lix is embedding. Positioning lix for binary files leading to existing systems. None of those support the embedded use case. Thus, don't position lix for binary files :)