History[04]

SwayDB started in 2017, and had its first release in 2018. Currently, it is under beta release.

Checkpoints[05]

No checkpoints are supported. For its in-memory implementation, no checkpointing or logging is supported. For the persistent version, it can persist its memory segments to disk, but this is used for reducing that level's storage, not for recovery.

Compression[06]

SwayDB supports compressing segments using LZ4 and Snappy, which are open-sourced Java compression tools.

Concurrency Control[07][08]

SwayDB assumes it runs 'under a single process in a single application', as the author clarifies on Reddit. Everything is atomic in SwayDB, including transactions. The only guarantee it has on transactions is atomicity. No concurrency control is needed, and indeed it is not mentioned in docs at all.

Data Model[01]

SwayDB is a key-value store, having Map[K, V] and Set[T] for data storage and providing APIs to create, read, stream, update, delete & expire data.

Foreign Keys

Indexes[09]

SwayDB organizes data in levels of segments, using the Log-Structured Merge Tree data structure. Upper levels write to lower levels in batches when it is full or the user explicitly demanded. Bloom Filters are used in each segment to search quickly whether a key belongs to that segment.

Isolation Levels[01]

Since every operation is atomic and runs on the same memory space, it is serializable.

Logging[10]

Write ahead logging is used for its persistent version databases. Because it is a key-value store, it does not have the notion of pages. The logs are physical logging of write operations.

Query Interface[11][12]

SwayDB is used embedded in applications. The API is in Scala with its custom APIs. A Java wrapper is also implemented for Java APIs.

Stored Procedures

System Architecture

SwayDB is an embedded database.

Views