The key factor that distinguishes an embedded database from those you may be used to is that an embedded database lives entirely in your program. There’s no remote server, no connection pool, no login credentials. Data is stored on the filesystem of the machine that runs the host process. Because of this, embedded databases will have very different properties than traditional databases.
Since access to local storage, especially local memory, is much faster than network access, embedded databases can be accessed synchronously, without blocking. However, this often places limitations on the query capabilities, especially for bulk queries that can return hundreds or thousands of objects. Thus, instead of providing a traditional query language like SQL, many embedded stores provide variations of the key-value lookup data storage paradigm.
In a key-value store, all data has a primary key, which uniquely identifies it, allowing us to store, update, or retrieve that item. In many ways, a key-value store functions quite a bit like Scala’s Map data type, with the constraint that keys must be strings. What’s missing is the notion of a secondary index, which would allow us to retrieve items by values other than the primary key. Instead, it falls on us to design data structures that will serve the needs of our application. However, if we accept this requirement, it’s often possible to write much more efficient, custom designs than what a general-purpose database would provide. And indeed, modern key-value stores like LevelDB[45] and RocksDB[46] are often internal components of relational and other databases; all of the higher-level operations can be implemented as a series of operations on a reliable key-value store.