Yes, although with databases as against log files, you also need to be able to somehow append 'deletes' and updates to existing records as well as just adding new records. The advantages of doing so is that it greatly simplifies transactional processing and makes it much more parellelisable - because you never change any existing data, just add new records on top. Blockchains have similar 'immutable' characteristics. The other reason why append only storage is desirable is that it allows you to time travel simply by backtracking through the append-logs and you can then do stuff like reconstructing future states by replaying all of the append events that got you there.
There are a variety of databases and database management systems that try to do this - most of them run into problems with the meta-language needed to describe updates and deletes to, for example, SQL Tables or something similar. This is a hideously tricky and detailed problem because there are all sorts of ways in which an SQL table can be changed many of which have implications for all sorts of other bits of data and you have to capture all of this in your 'update' append log.
On the other hand, if like TerminusDB, you use RDF triples as an underlying language, then the problem is pretty trivial - every update can always be expressed as a set of deleted triples and a set of added triples.
But, wouldn't an append only database demand substantially more storage which would also increase at a faster rate? How is that handled given we won't be able to fit the database on a single disk?
Also, I wanted to understand how databases work and wanted to build one from scratch. Is there any website/tutorial/blog you think could help me out? Thanks a lot!
There are a variety of databases and database management systems that try to do this - most of them run into problems with the meta-language needed to describe updates and deletes to, for example, SQL Tables or something similar. This is a hideously tricky and detailed problem because there are all sorts of ways in which an SQL table can be changed many of which have implications for all sorts of other bits of data and you have to capture all of this in your 'update' append log.
On the other hand, if like TerminusDB, you use RDF triples as an underlying language, then the problem is pretty trivial - every update can always be expressed as a set of deleted triples and a set of added triples.