> Object storage is an amazing technology. It provides highly-durable, highly-scalable, highly-available storage at a great cost.<p>I don’t know if this was intended to be intentional funny, but there is a little ambiguity in the expression “great cost”, typically great cost means very expensive.<p>Very cool and useful shim otherwise :)
It looks like writes are buffered in an in-memory write ahead log before being written to object storage, which means that if the writer box dies, then you lose acknowledged writes.<p>I've built something similar for low-cost storage of infrequently accessed data, but it uses our DBMS (MySQL) for the WAL (+ cache of hot reads), so you get proper durability guarantees.<p>The other cool trick to use is to use Bε-trees (a relatively recent innovation from Microsoft Research) for the object storage compaction to minimise the number of write operations needed when flushing the WAL.
I don't see how it's embedded if it relies on nonlocal services... on the contrary it says specifically, "no local state". It appears to be more analogous to a "lakehouse architecture" implementation (similar to, for example, Apache Iceberg), where your app includes a library that knows how to interact with the data in cloud object storage.
This seems to be a key value store built atop object storage. Which is to say, it seems completely redundant. Not sure if there's some feature I'm missing, but all of the six features mentioned on the front page are things you'd have if you used the key value store directly (actually, you get more because then you get multiple writers).<p>I was excited at first and thought this was SQL atop S3 et al. I've jerryrigged a solution to this using SQLite with a customized VFS backend, and would suggest that as an alternative to this particular project. You get the benefit of ACID transactions across multiple tables and a distributed backend.
From the docs <a href="https://slatedb.io/docs/introduction/" rel="nofollow">https://slatedb.io/docs/introduction/</a><p>> NOTE<p>> Snapshot isolation and transactions are planned but not yet implemented.
I've read the introduction and descriptions two times now and I still don't understand what this adds to the proceedings. It appears to be an extremely thin abstraction over object storage solutions rather than an actual DB which the name and their texts imply.
Went thru the document: <a href="https://slatedb.io/docs/introduction/#use-cases" rel="nofollow">https://slatedb.io/docs/introduction/#use-cases</a>
I can not understand why are they targeting the following use cases with this architecture.
* Stream processing
* Serverless functions
* Durable execution
* Workflow orchestration
* Durable caches
* Data lakes
Not a db guy, just asking, what does it mean "embedded" database?<p>I'm confused here, because Google says it's a db bundled with the application, but that's not really what I get from the landing page.<p>What problem does it solve?