datalevin

Jack Arrington 2026-02-27T13:19:01.119139Z

What's the recommended way of doing pagination with datalevin? Are :limit and :offset performance footguns?

Huahai 2026-03-01T03:54:53.625149Z

results are spilled to disk if it is too large.

Huahai 2026-02-27T18:02:10.900209Z

No. The full results are cached on the first query call, :limit and :offset work off that cached result set.

👍 1
🆒 1
Max 2026-02-27T23:53:58.469419Z

Could that cause memory issues for large result sets?

Samuel Ludwig 2026-02-27T20:52:48.874479Z

(If there's a better/specific channel for asking general datomic-style queries+organization, let me know) In general, are multi-value attributes considered a smell? Like storing a list/JSON in an SQL column, technically supported, but probably indicative that you want another table instead? For example, suppose, among other things, I had a Person entity:

#:person{:name "...", :address "..."}
And I wanted to also store the Cars they own:
#:car{:vin "...", :model "...", :year "..."}
Should I model that relationship as a :car/owner (single-value) attribute, or a :person/cars (multi-value) attribute?

Huahai 2026-02-27T21:30:00.558199Z

In Datalevin, mostly yes. Because Datalevin is optimized for normalized data. The optimizer is very good at finding good join orders. Multi cardinality attributes are not normalized, it will hit slower path in EAV index scan, basically we will be doing Cartesian products while scanning.

Huahai 2026-02-27T21:31:45.492719Z

So, car/owner is preferred in Datalevin

Huahai 2026-02-27T21:34:00.755439Z

But a tiny set of multi values hurts less, the convenience can be worth it sometimes.

✅ 3
Samuel Ludwig 2026-02-27T22:00:53.883219Z

Perfect, thank you