I had given a ddb tx-log a shot in the past if that's of your interest https://github.com/ordnungswidrig/crux-dynamodb (Most likely a little outdated)

There's also https://github.com/csm/crux-aws

Actually I'm looking for official module that could be safely used in production.

Hey @UJ1339K2B 👋 Not likely from the core team I'm afraid. While DynamoDB may well be acceptable for a tx-log/doc-store (as implemented by @U054UD60U above), the Crux query engine is currently quite chatty - its speed depends on having very low latency to its indices, so we recommend storing these on a fast local disk.

It looks like Casey got pretty far with a KV store implementation using the hitchhiker tree lib (although didn't get it working reliably, apparently) https://github.com/csm/crux-kv-hitchhiker-tree/blob/trunk/src/crux/kv/hitchhiker_tree.clj - I hadn't spotted that before but it's quite cool. A more native (& mutable!) KV implementation might use Dynamo's Global Secondary Indexes but they have a hard limit of 10GB https://docs.amazonaws.cn/en_us/amazondynamodb/latest/developerguide/bp-indexes-general.html#bp-indexes-general-expanding-collections

What about a memory cache backed by a DDB kv Store. Does this make any sense?

I think we'd have to cache the absence of keys, too, otherwise we'd have to go back to the source every time... :thinking_face:

As in, we'd have to know that the cache contained every key from a certain range in order to avoid the run to DDB

I haven't given it much thought, as you can probably tell 🙂

That does sound a little like 'database cracking', thinking about it - an idea we've had on our radar but haven't had the chance to properly investigate as yet

sounds good to me 🙂 easy enough, @U01AVNG2XNF?

@U0522TWDA Happy to. Out of curiosity, what's your particular use case for this? Are you sending quite a few people to http://opencrux.com these days? 🙂

I am doing a research about what best to use to replace our MongoDB and listing pros/cons of the possible solutions. Linking to the most relevant case studies helps highlight the value of Crux.

Sold. 😉 I'll get it done today.

@U0522TWDA There isn't a ToC or anything yet, but all the anchor ids are on <a> tags with an anchor class. The ids are identical to the titles of each section, but you can find them by inspecting the title and scrolling up a bit in the source to find the anchors. ex. https://opencrux.com/solutions/solutions.html#temporal-metadata-management Sorry this took a minute. The Crux website is undergoing a badly-needed revamp as we speak but the legacy SSG+CSS leaves much to be desired.

Awesome, thanks a lot!

It's an open map, depending on what modules you want to start up - best to look at the documentation of the individual modules on https://opencrux.com/reference. If you've questions about specific modules, feel free to give us a shout 🙂

Is there a set of options that the crux-core module accepts?

There's very little to crux-core itself - it's essentially an in-memory database, nearly all of the behaviour is brought in via modules. You might find what you're looking for in https://opencrux.com/reference/configuration.html though?

What are you trying to do?

I'm just getting started with integrating Crux into my app. Pretty new to Clojure. Just wanted to see what options were available and how I would find that info.

I guess for now I'll stick with just using an empty map for my in-memory Crux. Thanks for the pointers.

That's probably the easiest thing to do tbh, yeah, and then you can build up knowledge of more modules as you need them 🙂 good luck!

@UPWHQK562 There's also https://opencrux.com/howto/quickstart.html if you want the shortest path to getting a Crux node up and running with records on disk.

@U01AVNG2XNF Thank you. Looks like that'll be one of my next steps.

Here's an SQLite config from one of my projects, nice for dev and keeps data between restarts

Interesting. That code block doesn't make its way across into Zulip-land. 😕