title: What are the disadvantages of using Event sourcing and CQRS?
body: <p>Event sourcing and CQRS is great because it gets rids developers being stuck with one pre-modelled database which the developer has to work with for the lifetime of the application unless there is a big data migration project. CQRS and ES also has other benefits like scaling eventstore, audit log etc. that are already all over the internet.</p>
  
  <p><strong>But what are the disadvantages ?</strong></p>
  
  <p>Here are some disadvantages that I can think of after researching and writing small demo apps</p>
  
  <ol>
  <li><strong>Complex:</strong> Some people say ES is complex. But I'd say having a complex application is better than a complex database model on which you can only run very restricted queries using a query language (multiple joins, indexes etc). I mean some programming languages like Scala have very rich collection library that is very flexible to produce some seriously complex aggregations and also there is Apache Spark which makes it easy query distributed collections. But databases will always be restricted to it's query language capabilities and distributing databases are harder then distributed application code <em>(Just deploy another instance on another machine!)</em>.    </li>
  <li><strong>High disk space usage</strong>: Event store might end up using a lot of disk space to store events. But we can schedule a clean up every few weeks and creating snapshot and may be we can store historical events locally on an external HD just incase we need old events in the future ? </li>
  <li><strong>High memory usage</strong>: State of every domain object is stored in memory which might increase RAM usage and we all how expensive RAM is. <strong>BIG PROBLEM!!</strong> because I'm poor! any solution to this ? May be use Sqlite instead of storing state in memory ? Am I making things more complex by introducing multiple Sqlite instances in my application ? </li>
  <li><strong>Longer bootup time</strong>: On failure or software upgrade bootup is slow depending on the number of events. But we can use snapshots to solve this ?</li>
  <li><strong>Eventual consistency</strong>: Problem for some applications. Imagine if Facebook used Event sourcing with CQRS for storing posts and considering how busy facebook's system is and if I posted a post I would see my fb post the next day :)</li>
  <li><strong>Serialized events in Event store</strong>: Event stores store events as serialized objects which means we can't query the content of events in the event store which is discouraged anyway. And we won't be able to add another attribute to the event in the future. Solution would be to store events as JSON objects instead of Serialized events ? But is that a good idea ? Or add more Events to support the change to orignal event object ? </li>
  </ol>
  
  <p>Can someone please comment on the disadvantages I brought up here and correct me if I am wrong and suggest any other I may have missed out ?    </p>