3 ms·

> Data stored in immudb is cryptographically coherent and verifiable. Unlike blockchains, immudb can handle millions of transactions per second, and can be used

> Data stored in immudb is cryptographically coherent and verifiable. Unlike blockchains, immudb can handle millions of transactions per second, and can be used both as a lightweight service or embedded in your application as a library. immudb runs everywhere, on an IoT device, your notebook, a server, on-premise or in the cloud. Seems pretty useful actually. Can anyone with a relevant background comment on when this would be a bad idea to use?

KarlKemp 5y ago
The data that is at risk of being changed with malicious intent is certainly not insignificant, but still just a fraction of all data. Changing to this adds a new and complicated system, replacing whatever you're currently using, which will have seen far better testing and is known by the people working with it.
staticassertion 5y ago
If you can trust your writers there's likely no need for this. A modern approach tends to have databases owned by a single service, which exposes the model via RPCs. So you generally don't have more than one writer, which means you're pretty much de-facto "zero trust" if that single writer follows a few rules (ie: mutual auth, logging, etc). But in some cases you don't have that same constraint. For example, databases that store logs (Elastic, Splunk, etc) might have many readers and writers, including humans. In that case enforced immutability might be a nice property to have. Attackers who get access to your Splunk/ES cluster certainly will have fun with it.
imglorp 5y ago
There are a few properties to be aware of. Although it might be a KV store, you're probably going to want sensible queries using other than the primary key. Eg time series or secondary keys. So in addition to the KV store, there is probably a need for an external index and query mechanism. Another issue is obtaining consistent hashing, where multiple documents might have the same content but vary by order or by date format. Finally, do you have to go to the beginning and hash everything to get a proof of one transaction, or is there some shortcut aggregation possible? We evaluated AWS QLDB for these things in our application as a financial ledger and were impressed at their progress with a novel data store. They invented some of the tech in house for this product instead of grabbing an off the shelf open product. Lockin would be a downside here. Immudb looks promising because it's not locked to a cloud host. https://aws.amazon.com/qldb/faqs/ https://aws.amazon.com/qldb/faqs/
- mistrial9 5y ago
  > Eg time series or secondary keys not an "all or nothing" question.. for example, a fast-enough "return the most recent in a time series" is not exactly time-series, but solves many use cases
- jaboutboul 5y ago
  note that it does KV and SQL
rattlesnakedave 5y ago
Seems like it would still be vulnerable to rollback attacks. Signed rows would probably get you farther with less novel tech involved if you want immutability.

KarlKemp 5y ago

The data that is at risk of being changed with malicious intent is certainly not insignificant, but still just a fraction of all data. Changing to this adds a new and complicated system, replacing whatever you're currently using, which will have seen far better testing and is known by the people working with it.

staticassertion 5y ago

If you can trust your writers there's likely no need for this. A modern approach tends to have databases owned by a single service, which exposes the model via RPCs. So you generally don't have more than one writer, which means you're pretty much de-facto "zero trust" if that single writer follows a few rules (ie: mutual auth, logging, etc). But in some cases you don't have that same constraint. For example, databases that store logs (Elastic, Splunk, etc) might have many readers and writers, including humans. In that case enforced immutability might be a nice property to have. Attackers who get access to your Splunk/ES cluster certainly will have fun with it.

imglorp 5y ago

There are a few properties to be aware of. Although it might be a KV store, you're probably going to want sensible queries using other than the primary key. Eg time series or secondary keys. So in addition to the KV store, there is probably a need for an external index and query mechanism. Another issue is obtaining consistent hashing, where multiple documents might have the same content but vary by order or by date format. Finally, do you have to go to the beginning and hash everything to get a proof of one transaction, or is there some shortcut aggregation possible? We evaluated AWS QLDB for these things in our application as a financial ledger and were impressed at their progress with a novel data store. They invented some of the tech in house for this product instead of grabbing an off the shelf open product. Lockin would be a downside here. Immudb looks promising because it's not locked to a cloud host. https://aws.amazon.com/qldb/faqs/ https://aws.amazon.com/qldb/faqs/

mistrial9 5y ago
> Eg time series or secondary keys not an "all or nothing" question.. for example, a fast-enough "return the most recent in a time series" is not exactly time-series, but solves many use cases
jaboutboul 5y ago
note that it does KV and SQL

rattlesnakedave 5y ago

Seems like it would still be vulnerable to rollback attacks. Signed rows would probably get you farther with less novel tech involved if you want immutability.