What is the best way to design a database for the change history of text documents?

Question

Database design

Good afternoon.
There is a need to design a service, the key feature of which is planned to implement the version history of a text document. The closest analogue that has this feature is the version history of a document in Google Docs. Accordingly, it is necessary to correctly select the database for this task.
I propose to use a bundle of two databases: PostgreSQL for storing meta-information and data necessary for the site to function, and HBase as a storage for text documents, including their versions.
Will this approach be correct or are there other, generally accepted options for solving this issue? If so, which ones?

Answer 1

alfresco look

Answer 2

You can look at the CQRS + Event Sourcing architecture . Instead of storing the state of an entity, they store the events that happened to it. Having rolled these events in order of priority to the entity, you can always get the state of the entity at any point in time.
It simplifies the work with writing data to the storage, but complicates reading. Therefore, CQRS is usually still used with two stores, one for writing where the sequence of events is stored, the other for reading, where the current state of the entities is stored. WriteModel sends a message to the broker about the event, ReadModel catches this message and updates its state in the database. ReadModel can always be rebuilt from scratch based on existing events. You can use data denormalization and write to the database in such a way as to read the necessary data using the simplest queries.
You can take any databases, although usually they use a standard relational or document-oriented database for ReadModel, and for WriteModel you can take something more specialized, for example, event store, simply because all the relational subd features are not required for this part of the application.
You can see examples of implementing event sourcing https://github.com/prooph/event-sourcing