You could use (keyword "<@") at the very least

dev=> (def at> (keyword "@>"))
#'dev/at>
dev=> (def <at (keyword "<@"))
#'dev/<at
dev=> (sql/register-op! at>)
nil
dev=> (sql/register-op! <at)
nil
dev=> (sql/format {:select :* :from :foo :where [:and [at> :a :b] [<at :c :d]]})
["SELECT * FROM foo WHERE (a @> b) AND (c <@ d)"]

Ah nice. I forgot that you can make keywords which are valid but "unreadable".

I do exactly this, but are the warnings on https://clojuredocs.org/clojure.core/keyword still valid?

;; keyword does not validate input strings for ns and name, and may
;; return improper keywords with undefined behavior for non-conformant
;; ns and name.

;; Warning - the following generated keywords are non-conformant and may wreak
;; serious havoc in the near/far future when least expected...

I don't think it's a big deal here, but I see a lot of places where people e.g. take arbitrary JSON as input and decode with keyword keys, and it seems pretty scary if the result is undefined

Should I be a stickler about using string keys, or are keywords actually fine?

The core team did at one point try to tighten up what keywords the reader accepted but it broke quite a bit of code out there — so they reverted that change. I think at this point you are “safe” creating unreadable keywords via keyword as long as you don’t actually try to read them!.

(and, in particular, http://clojuredocs.org is not official documentation so examples and commentary are what random community members think 🙂 )