On-prem supports fulltext: https://docs.datomic.com/on-prem/schema/schema.html#operational-schema-attributes

It’s very limited and you cannot remove it later. If you want flexible and powerful fulltext search over large text corpuses I suggest feeding the datomic transaction log into a secondary elasticsearch service and using that for fulltext searches.

If you just have tiny text fields and just want some kind of low-headache fuzzy matching, it’s probably fine.

Awesome, thanks!

@U09R86PA4 perhaps it would be good if https://docs.datomic.com/on-prem/schema/schema-change.html#schema-alteration listed :db/fulltext in the "You can never alter ..." list? Not sure how to propagate that suggestions to the Datomic team...

Hi @U0522TWDA it's already there: You can never alter _:db/valueType_, _:db/fulltext_, _:db/tupleAttrs_, _:db/tupleTypes_, or _:db/tupleType_.

Ah, thank you, I'm blind today :)

A “current” (unfiltered) db is always fastest, because it only ever has to retrieve the current index. It only merges against that index and the memlog.

Potentially an as-of >= last-indexed-t will do the same and be the same complexity, but I donno.

anything older is going to have to look at the history or mid-history indexes to reconstruct the value at that moment in time.

whether this is slower-enough in practice depends on object cache, valcache, datasize, selectivity of queries, etc

but you’re merging across 3-4 indexes instead of just 2

Interesting, thanks for responding. By "anything older is going to ...", do you mean both an as-of and an unfiltered db would go down this path?

an unfiltered db is by definition a “now” db, so only looks at the “now” index--the one that only has assertions valid at the moment it was indexed.

By “anything older” I mean anything that needs to look at datoms older than the last-indexed T