Insert-only: Sorry bad wording. "Focus on inserting events (which boils down to only inserting into tables, never updating existing rows)" A database can of co

Insert-only: Sorry bad wording. "Focus on inserting events (which boils down to only inserting into tables, never updating existing rows)" A database can of course never know that it is "events" you are inserting. -- Aggregates/materialized views: (Contrived example warning) Say that you have a User entity in your system. The Name of the user is only set through two events, UserChangedName or CustomerServiceChangedUserData. The "aggregate" is simply the calculation of the user's name (and other data) from such events. Declaring this should be done using some variant of functional programming; SQL views, reactive programming, etc At least in the DB we use, we can declare a SQL view that fits the bill and does such a transform. So User is a view on the events that affects it. But it can not be materialized if it is too complex (materialized = updated when the insert of events happens, so that one does not need to query all the events every time one reads User). One can do it using triggers, but that is an imperative instead of declarative programming style with all the problems and lack of guarantees. -- Operation allowed etc: Say that there is a limit of 5 name changes. However a TooManyNameChangesReviewedByCustomerSupport can be inserted and then you get 5 more. So user wants to change name. You need to read NameChange events and TooManyNameChangesReviewedByCustomerSupport events, compute whether a change is allowed or not, and only save the event if it is allowed to happen (at which point it becomes the event -- this DB is the source of the event). What you need now is a transaction that allows you to avoid race conditions. Otherwise a parallel thread could be doing the same thing at the same tim, and you end up jumping from 4 to 6 name changes, when 5 should be the limit. SQL DBs focus on providing transactional guarantees for UPDATEs, but not so much on guarantees for "only INSERT this row if these other rows in another table are NOT present/has a count less than --" .. So you end up having to update an aggregate manually in the SQL transaction to avoid races => this is what should be built into the SQL server. (It would just be syntax candy in a sense, saving one from writing code to update the aggregate explicitly, but pretty important syntax candy as it changes the mindset of the developer in an important way)