Lix April 2026 update: - Benchmarking exposed that SQLite gives too little control over Lix's versioned storage model to keep improving incrementally. - Decision: move query execution to DataFusion while keeping SQLite as a possible physical storage backend. - May goal: Release `v0.6` MVP with focus on CRUD with branching and merging on the optimized semantic write path that the file API will use next. --- You can already try out lix v0.6 via NPM: ```js npm i @lix-js/[email protected] ``` The next step is to finalize the physical storage layout. The runtime can be optimized incrementally in follow up releases.

I released @lixCCS v0.6.0-preview.2 on NPM. ``` npm i @lix-js/[email protected] ``` You can try out: - writing & reading files via SQL - branching - merging - entity level state (as precursor to entity level file diffs) The final v0.6 release requires the finalization of the physical storage to avoid breaking changes.

@lixCCS March 2026 update - 500 real commits replayed with no corruption bugs - ~8x faster than Git for file-write-plus-commit - Semantic writes are still too slow. Fixing that in April. --- March was about workload testing. I replayed 500 real commits from a production repo through Lix. No state corruption bugs. That matters more than the benchmark number. Correctness before speed. The unexpected good news: without the semantic layer, Lix completes the same file-write-plus-commit flow in ~5 ms. Git takes ~39 ms. The reason is architectural. Lix applies mutations inside an open SQLite transaction, so commit is just closing it. But the semantic layer is still the bottleneck. One file write can fan out into 10k+ entity rows for paragraphs, tables, images, and other structured units. Right now that is multi-second territory. Anything above 100 ms does not feel instant. So April has a simple goal: make Lix ready for people to try: - 10k entity inserts under 100 ms - Prolly trees so branching is cheap - Workload testing with the semantic layer enabled

Dolt did great research on how to version control millions of rows in a SQL database. They use a tree structure called "Prolly Tree". The benefits compared to regular B-Trees are: - content deduplication across branches and history - fast diffs - B-tree like performance The research comes handy for @lixCCS. Lix version controls files semantically. Take a .docx file as an example. Lix tracks individual paragraphs, tables, etc. instead of treating a .docx file as binary blob. The semantic layer in lix works by parsing a file into 'entities'. Naively, the entities are stored as rows in a SQL database. That is slow and highly storage inefficient. Creating a new branch would need to copy all rows, or require complex-ish copy-on-write logic. Prolly trees solve this. Read more about them at docs.dolthub.com/architectur…

Lix is about 8.4x faster than Git on committing changes in a preliminary benchmark :O My goal this month was to achieve +-10% performance parity with git to get peace of mind a la "yes, lix is fast enough". But this is, even to me, a surprise.

Lix February 2026 Update: - 33x faster writes 🦀 - GitHub stars grew from 70 to over 500 🌟 - Real workload and AX (user) testing is coming up in March --- The Rust rewrite is complete. With it comes full control over query planning which enables critical performance optimizations 🦀. Furthermore, people start to notice lix! :) Lix was trending on HN and Reddit which immediately boosted the GitHub stars from 70 to over 500 🌟. Next month will be real workload and AX user testing. Afterwards, I should be able to confidently tell people "Yes, try out lix".

Updated Lix’s landing page after Hacker News feedback: – The version control system for AI agents + Embeddable version control system for AI agents

Docs for @lixCCS are in the works 🫡