> Data stored in immudb is cryptographically coherent and verifiable, just like blockchains, but without all the complexity. 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.<p>> Companies use immudb to protect credit card transactions and to secure processes by storing digital certificates and checksums.<p>This explanation is available on their github repo [1]. It has been a common refrain on Hacker News that you don't need a blockchain and instead can just use a database, but this product may actually fill the gap where tamper resistance is desired.<p>[1] <a href="https://github.com/codenotary/immudb" rel="nofollow">https://github.com/codenotary/immudb</a>
> immudb is the first database which allows you to do queries across time.<p>I don't think it is<p>e.g. Datomic already had this for a long time, no?
There seems to be a growth in the number of time traveling immutable-first databases available. We have OpenCrux, Datomic, TerminusDB, Noms, Dolt, and now Immudb. Three using datalog for query and two forcing SQL (not sure about Noms).<p>What sort of use cases are most common? GitHub repository says:<p>> Companies use immudb to protect credit card transactions and to secure processes by storing digital certificates and checksums.<p>But I am not sure how people are building that into their architecture to be honest.
Reminds me a lot of Fluree[0], an immutable, cryptographically verifiable, temporal database, but with RDF as a query language, which I think is very nice. SQL is nice because it's familiar but it's honestly not that hard to improve on.<p>[0]<a href="https://flur.ee/" rel="nofollow">https://flur.ee/</a>
So is this something I would want to use for a basic CRUD application, and reap the benefits of time travel and immutability?<p>Or are there downsides that would relegate it to specific use cases? A what would those use cases be?
I love what you’ve done. I think you may have an issue with the TimeTravel trademark however. Snowflake uses it in your exact market segment (not to mention where else it may be used in a similar context). Good stuff though, I’ll be checking it out.
I would like to have such a database based on git. Where every change is a git commit. This should then work with things like github where you can connect to your database via github api. The db git repositories could be either private or even public. You can then deploy a serverless webpage to gh-pages and use a serverless gh-gitdb as storage.<p>serverless := you don't have to operate the infrastructure yourself
Seems like a database that stores content hashes. Very cool but what makes it better than simply adding a table to my database (or a DB specifically for this) and running `insert into content_hashes...`?<p>The above approach also allows me to choose any database because I can model this data however I want.
How is this any different than taking every mutation, signing it using whatever signing mechanism you'd like and adding a column, in addition to the ones you'd like with the hash.<p>Then, if anything changes you know it's been mutated because the computed signature has changed.
If this is deployed in a situation where record volumes are large, example: recording credit card transactions, there is going to have to be a process to "retire" old records (and perhaps, move them to external archives). The alternative is endlessly growing storage, and the resulting performance degradation.<p>At a first glance, I don't see anything like that in there.
The team will host a release party on Monday, May 31st at 6pm CET (18:00) - 10:00 AM PDT.<p>If you have questions about immudb, you are welcome to join us!<p><a href="https://www.codenotary.com/blog/immudb-release-1-0-release-party" rel="nofollow">https://www.codenotary.com/blog/immudb-release-1-0-release-p...</a>
> This new functionality allows travel back in time through the data change history, and even compares these values in the same query!<p>So we can actually treat our databases like immutable infrastructure and actually roll back changes now without the hulking cludge that is snapshots/restores and database migrations? That's game-changing.
this is hugely interesting, i have to look into this, but...
for dev/test environments, can i have a "unverified" version, where clients reget/reset the state?
GDPR requires to erease user date if users withdraw their consent or their data are no longer required for purpose which you originally collected or processed it for.<p>Therefore, you must carefully check that no personal data is stored in immutable databases.
not exactly immutable is it? their docs say you can do UPSERT for example. the key is that once you update something, the clients can check using crypto that something was changed. you can't do this in regular databases.
There, I did it for you in PostgreSQL:
ALTER TABLE table_name SET (autovacuum_enabled = false);<p>Snark aside, it‘s still not 100% clear what‘s the upside of using a completely different database, just for that use case.