Back

So far, i've found PumpkinDB, http://pumpkindb.org. But that's still a separate service. It looks lean and simple though.

I guess I could just go with one of several "integrated KV storage" libs that the #rust community offers too, like https://github.com/tropicbliss/crio .

Putting that behind an EventStorageAdapter would work, and is smth I'd do anyway. But these options requires me to write that adapter with events/aggregates in mind. I'd prefer such a storage that already has all this setup.

@tcoopman I have. And it works, but only so-so.

Indexing on aggregateID is easy and works perfect for fetching.

But (de)serializing is a pain. SQLite has nothing to store (typed) documents. Just STRINGs that are to be (de)serialized in the app. PostgreSQL at least has JSON storage.

So I'm then not using any of the relational features, basically not using most of what SQLite does well.

@berkes that's true, but I haven't found that to be much of an issue. (Haven't extensively used it yet either).
But I'm not sure what you mean about using the relational aspect. Would you use relational features on your event data?

@tcoopman I meant that my event data has no need for relational features (like atomicity, or FK constraints), yet all that is offered by SQLite. Not that it's in the way,but it's all unnecessary complexity that I'd prefer to do without.

@berkes if you want something embedded, then I think sqlite will be the best tool. It might add a (tiny) bit of complexity because of the relational features. But the upside is that it's a tool that has proven itself a lot.

@windrunner @berkes@mastodon.nl yup, in Marten, we’re aiming for accessibility and simplicity, and also using great Postgres JSONB features

@berkes@bitcoinhackers.org you can read more in our docs https://martendb.io/introduction.html