Does the separation of storage and compute mean Ladybug will no longer be an embedded database?

No. We’ll continue to maintain the CLI and language bindings that allow people to embed the database. Many next generation embedded databases allow accessing object storage. KuzuDB did too. We’ll go further in allowing people to create tables directly on object storage without having to ingest first.

Can these two use cases survive in one code base?

For now we think it’s best to move forward with one fork and reevaluate in a few months.

Is there a commercial entity behind this fork?

Yes, we will have Ladybug Memory (soon to be incorporated and likely venture backed) supporting the effort.

I tried pip install lbug and got an error

We did a global replace of kuzu with lbug. Both 4 letter words. No need to reformat code! Packages, namespaces and language bindings can be discussed on github issues and we can rename as appropriate for each use case.

Would ladybug be community driven? And what process is set up for it?

Initially, we’ll organize around the github project above - using open discussion, issues and PR based review process. We’ll make periodic releases. Roughly once a month. Over time maintainers and code reviewers will emerge from the community. People with extensive contributions and demonstrated expertise could end up maintaining subsystems and get appropriate review/commit access. Non-technical governance: GraphGeeks as an important vendor independent communication channel. Future possibility of joining a foundation: too early to comment. Let’s form a loosely knit community around the code. Governance mechanisms will emerge out of contributions and leadership.