electric-sql / vaxine

Rich-CRDT database based on AntidoteDB.

Vaxine

Welcome to the Vaxine source code repository. Vaxine is a rich-CRDT database system based on AntidoteDB. It's used as the core replication layer for ElectricSQL.

About Antidote

AntidoteDB is a planet scale, highly available, transactional database. Antidote implements the Cure protocol of transactional causal+ consistency based on CRDTs.

More information:

• Antidote website
• Documentation

Antidote is the reference platform of the SyncFree and the LightKone european projects.

Contributing

See the Community Guidelines including the Guide to Contributing and Contributor License Agreement.

Support

We have an open community Discord. If you’re interested in the project, please come and say hello and let us know if you have any questions or need any help or support getting things running.

vaxine's Issues

Relationships with referential integrity

N.b.: requires design / spec.

We want to be able to provide relationships with referential integrity. This can be implemented using the touch + add-wins semantics outlined in the IPA paper. In addition, it may be necessary to use a escrow-transfers mechanism for some exclusive access.

In addition, we need to design/specify:

• how relationships will be configured for one-one, one-many, many-one and many-many using the Vat library and how this should map to underlying types
• what operations we provide on the relationship and whether we support cascading deletes

Secondary indexes

At the moment, we are a KV store with primary indexes. We want users to be able to efficiently query on multiple fiuelds. This presents a challenge to have consistent secondary indexes -- related to materialisation cost etc.

Access control

Strong consistency

The idea is to merge the best of the strong consistency implementations on the current feature branches.

TBC: to what degree is this required with the rich-CRDT approach?

Checkpointing

Finish / merge the refactoring and log compaction work.

TODO: flesh out this description / spec.

ginkgo ETS cache

refactor AntidoteDB/antidote#463

• flatten git commits
• align with existing code by cleaning up spaces/function names/reformatting & linting
• add some documentation and background info
• ensure existing tests pass
• document remaining issues after this point

Inter DC communication

Large objects

Currently, querying the contents of large objects (maps, sets) copies the whole object (e.g.: the whole set) to the client to read one of the members.

We need a strategy to resolve this, as discussed in the Paris workshop.