I think this is their design choice, as to avoid having to explicitly support high concurrency, as they have to sacrifice time and functionality for this kind of optimisation. I might give it a try these days and see if any of the libraries work at all.
D4no0
dimitarvp
DuckDB and Clickhouse Local are very popular among data scientists, FYI.
But yeah, don’t be intimidated. Personally I’m always erring on the side of minimum machines and simplest setup so any advice I give should be evaluated within that context.
Good luck! 
1
dimitarvp
w0rd-driven
This may be way out of left field but would TimescaleDB be an option? When you mention analytics I’m reminded of the talk Dave Lucia gave at CodeBEAM Code BEAM America. The docs also include a Livebook notebook to play around with it, which significantly reduces friction for someone like me Intro to Timescale — Timescale v0.1.1. Though looking deeper it is more of a preview state probably and I doubt there are other more mature packages.
0
tcoopman
The question is already solved, but I want to clear one thing up.
CQRS != Event Sourcing
very simplified:
- CQRS is an architectural pattern where you separate the read and write model
- Event Sourcing is a pattern where you use domain events as the single source of truth to make decisions instead of a “regular” database.
CQRS doesn’t require EventSourcing, and strictly speaking neither does Event Sourcing need CQRS, but ES almost always uses CQRS.
2
D4no0
Yes this is true, however the most literature uses them in combination, and this is also true for a lot of libraries, so from the point of perspective of a beginner it is not very clear how to distinguish them correctly.
0
tcoopman
Yeah, for EventSourcing, the logical choice is also to use CQRS. So that’s the reason they’re often bundled together which can be confusing.
1
beamologist
Thank you for the elaboration on the topic and I agree with your conclusion that for the OP’s use case, an ES/CQRS approach is probably not optimal.
It is not at all my intention to stumble on details, but there is however one aspect in your reply that may confuse people. Event sourced systems don’t store commands, just the events and use (“source”) these events to build Read Models through projections, that interpret a specific event and invoke a mutation of a read model. This is why such systems usually have an (internal) Pub/Sub system, because those projections must be able to subscribe to a topic. This is also one of the strong points of EventStoreDB: it offers a wide variety of options to subscribe to streams.
This way, the Event Log becomes the sole and immutable source of truth, while read models can be destroyed and rebuilt at any time, optimized for quick retrieval.
It is a little unfortunate that the terms ‘Command’ and ‘Event’ have slipped into the literature. When I teach or explain ES/CQRS, I replace Command with Hope and Event with Fact. The reason being, that we may only hope that a command gets turned into a fact..Whether or not this happens, depends on the state of your Aggregate at that point in time, perhaps even extended with out-of-bounds, volatile information (1) . If the hope is granted (in other words, the command may execute) the hope is turned into fact and stored in the log.
I am not sure if I fully understand your point 2. I’ll have to look into the implementation details of Commanded for that.
By the way, the sentence marked (1) is the reason why it doesn’t make much sense to store commands 
Once more, thank you for your contribution.
1
tcoopman
There are some good reasons to store commands though. Events don’t capture the intend of what happened, just what happened. So for audit reasons, capturing events is actually very useful.
Also if you want to debug cases, having both commands and events is super useful.
I sometimes use action and decision. But not when I’m teaching event sourcing. Hope sounds rather pessimistic though. It’s true that a command can always fail, but the reality is that most often they don’t fail.
Fact is something I can agree with
If you’re talking about unfortunate terms like command and event, it’s kinda strange that you’re still keeping aggregate which is a lot less clear than command and event 
1
beamologist
I don’t want to end up in some strange polemic back-and-forth,
Unless you also store the reason why a command fails, I still don’t see the point of keeping track of them in a persistence store… (in the end, there is still this thing called “logs”, right?)…
Also, I am not sure if I fully agree with “the reality is that most often they [commands] don’t fail”…it reminds me of the statement “The network is always available.”
It is called an aggregate because it aggregates the list of facts that represent the (volatile) state, quite a technical artifact that is usually not so useful when communicating with business people. For that audience, I tend to use “business process” or “behavior”.
Also, the phrase “Would you want us to built your new system based on hopes, rather than facts?”, usually sticks
2