WeaklyDB

Abstract

WeaklyDB is an experimental distributed database project intended to support systematic investigation of how replicated storage behaves under asynchronous communication, concurrency, and failures. The central concern is to make a distinction between an intended consistency contract, the executions admitted by a particular protocol, and the behavior observed in a running implementation.

The project is motivated in part by Dynamo [1], which demonstrates a design space for highly available key–value storage in which consistency and availability requirements shape replication and conflict handling. WeaklyDB does not claim to reproduce Dynamo's implementation or inherit its guarantees; the paper serves as a foundational reference for the questions investigated here.

Research questions

1. RQ1
   Consistency specification. What histories are permitted by a chosen replication protocol, and which formal consistency properties do those histories satisfy?
2. RQ2
   Ordering and convergence. Under which assumptions do concurrent writes lead to a convergent state, and how do update-order and conflict-resolution choices affect that outcome?
3. RQ3
   Availability and progress. How do message delay, partitions, stale observations, and replica recovery influence safety and liveness?
4. RQ4
   Evidence and reproducibility. How can counterexamples, executions, and experimental observations be recorded and checked independently?

These are proposed lines of investigation, not claims of novelty or completed findings.

System model and assumptions

The precise protocol and fault model are under development. The following is an outline of aspects that should be specified before a system-level guarantee can be asserted.

Research results should distinguish specification, implementation, and experimental observation. An observed convergent execution alone, for example, does not establish convergence for all admissible executions.

Research artifacts

As material becomes available, this page will link to the corresponding versioned artifacts rather than presenting unverified benchmark figures.

• Formal specifications and invariantsNot published
• Protocol and implementation documentationIn preparation
• Test harnesses and execution tracesNot published
• Evaluation methodology and raw resultsNot published

References

Reference [1] motivates the study of available replicated key–value systems; this is not a statement of code lineage, formal equivalence, or adopted implementation details.