SingleStore Managed Service

Durability
What is the durability guaranteed by SingleStore DB?

SingleStore provides several options to control the tradeoffs between performance and durability. In its most durable state, SingleStore will not lose any transactions that have been acknowledged.

What happens if the hardware SingleStore Managed Service runs on fails?

SingleStore is built on a cloud-native and highly resilient architecture that features high availability within the cluster. When cloud instances fail, SingleStore transparently handles the failures, replaces instances, and maintains cluster availability to the application.

Does being in-memory mean that SingleStore DB will lose all data upon system failure or restart?

No. Unlike traditional relational database management systems, SingleStore DB uses RAM as the primary storage for data. However, SingleStore DB continuously backs up data to disk with transaction logs and periodic snapshots. These features can be tuned all the way from synchronous durability (every write transaction is recorded on disk before the transaction completes) to purely in-memory durability (maximum sustained throughput on writes).

On restart, SingleStore DB uses the snapshot and log files to recover its state to what it was before shutting down. Because the recovery process is parallelized across CPUs, the bottleneck in this process is the sequential hard drive speed.

If SingleStore DB writes data to disk, how can it be faster than disk-based databases?

Traditional relational database management systems use disk as the primary storage for data and memory as a cache. Managing this caching layer adds bookkeeping overhead and contention thus reducing throughput and concurrency. These constraints result in random read and write I/O, which puts significant pressure on both rotational and solid state disks.

On the other hand, SingleStore DB stores data primarily in memory and backs it up to disk in a compact format. As a result, SingleStore DB uses only sequential I/O and the transaction log size is significantly smaller. This I/O pattern is optimized for both rotational and solid state disks. Furthermore, reads in SingleStore DB can use memory-optimized lock-free skip lists and hash tables that cannot be managed in a buffer pool.

What isolation levels does SingleStore DB provide?

SingleStore DB provides the READ COMMITTED isolation level. This guarantees that no transaction will read any uncommitted data from another transaction. Furthermore, once a change is observed in one transaction, it will be visible to all future transactions.

Unlike the REPEATABLE READ or SNAPSHOT isolation level, READ COMMITTED isolation level does not guarantee that a row will remain the same for every read query in a given transaction. Applications that use SingleStore DB should take this into account.

Even though regular transactions use READ COMMITTED isolation level, backups created using the BACKUP command use SNAPSHOT isolation level.