Database revision vs Event sourcing for tracking changes of entity changes

We are developing a platform where there is the possibility of booking hotels. The booking process can consist of various operations: creation, change of dates, cancellation, confirmation, and so on. We need to have access to the history of booking changes to display this on the front end (for now, only for displaying, who knows what might happen in the future). One of the ways to use this history of changes: Created a booking -> changed the dates -> we show the user the previous dates and current ones. The entity of Booking: { checkInDate: string, checkOutDate: string, amount: number ... +30 fields } Found two approaches: First approach: Versioning the entity at the database level. If our entity is updated, then a copy of the entity is automatically created, but with new fields. In the case of changing the dates of a just created booking, the client will return an array of bookings, each will have all the fields of the booking and an additional field with the status (created, changed dates etc). Pros of this approach: * Faster backend implementation, changes are mostly required at the database level. * One familiar Booking model is used. * Ability to configure rollbacks. * Good performance. Cons: * Difficult to set up auto migration. * The database stores a lot of excess data, which will be returned to the client who does not need them. Second approach: Event-driven architecture There is a described list of possible events that can occur with a booking. An event is created for each operation, which can contain a payload with the data that has changed. In the case of changing the dates of a just created booking, the client will return a booking with an array of events, each of which contains a list of data that has changed. The changed-dates event may contain the previous dates and current ones. Pros: * Only necessary data is stored in the database and returned to the front. * Having a list of described events, the flow becomes transparent, which improves the understanding of the code. * In the event payload, you can add any data, even those not related to the previous booking change. Easier to expand functionality. * Business logic is kept on the backend, the front simply displays the data, business logic does not penetrate the database level. Cons: * Many additional types are added, which need to be used on the front. * More complex backend implementation. Could you suggest which solution is better to choose? Maybe you have a better option?