Is the aim to do event sourcing for later data analysis or to actually base your app&#x27;s business logic off of the events?<p>I have some experience with using events to construct the final state for data analysis. (If you didn&#x27;t mean for data analysis, just ignore this comment) The problem with trying to reconstruct data at some final state based on events is that the meaning of the events change over time. For instance, createUser might do one thing in January, then something slightly different in April (e.g. sets a default value to be 10 instead of 5). It becomes a nightmare to try to get the final table to be accurate, and if you try, your reconstruction script ends up with a bunch of if&#x2F;then cases based on the history of the program generating the events.<p>You still probably want to log the events, but it looks like you are hoping to recreate the users table based on your createUsers history, which would run into the problem I mentioned above.<p>If you do log data straight to files, you can always analyze it with something like Splunk or Kibana (and if you use Kibana, you probably just log the events with the ELK stack). Still, it&#x27;s way easier to analyze data with a relational database because of the tools built around SQL, and it&#x27;s already familiar to analysts whereas Splunk&#x27;s proprietary language is something they&#x27;d have to learn.<p>If you end up using SQL, I suggest <a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;redshift&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;redshift&#x2F;</a> for the data warehouse, and <a href="http:&#x2F;&#x2F;DataDuckETL.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;DataDuckETL.com&#x2F;</a> for getting the data into Redshift.