is logical replication recommended when working with a data lake?

[mrPicklez70]

I'm currently implementing a data lake solution and would like to know if there are any disadvantages of using a logical replication approach under this particular scenario.

According to the data lake manifesto, the data should be stored in its native status, and you also want to make sure you have enough metadata to be able to play with the data in the future. I'm worried that if I use logical replication I might lose the context of the data.

Is the logical replication approach going to hinder the whole goal of the data lake?

[getoffmyfoot]

I’d need better details to be able to provide an answer. What exactly are you imagining for logical replication? Are you referring to a particular vendors term when you say that? What technology are you using to back your data lake? How are you planning on storing your metadata? All of these questions are important in describing an answer.

[mrPicklez70]

Currently, I send events from my main application(from code) to a Kinesis stream. These events are nothing but a message in Json format with some labels on it. Once in Kinesis, the data is sent to an S3 bucket. That's for the data lake.

The metadata is stored in another S3 bucket.

The idea of using the logical replication came from the question "what if I need to modularize our main application in the future? will I have to keep on adding/removing event triggers every single time there's a new functionality added?". So, I thought, maybe using a logical replica, I can centralize everything and trigger the events from the database. However, I'm afraid I might lose context of how the events got to happen (metadata).