Fork me on GitHub

I'm having an internal debate whether to use PostgreSQL (which is my fave database of all time - well, except the one I wrote back when I were a kid, ran on BBC Basic and provided you were storing records (as in vinyl), with a name, duration and rating - and do not dare to deviate from norms), or use Elasticsearch.....


Funnily enough, I wrote my own database, back in the day, for managing my record collection too!


But it was UCSD Pascal on a SAGE IV.


It turned out very useful when I was burgled: I was able to give the insurance company an itemized list of every CD stolen, date purchased, price paid, shop bought from. So they treated it as a per-item claim -- and opened an account at HMV London for me with ten thousand pounds credit 🙂

😲 24

I hope you spent it all before HMV disappeared!


Yeah, in two visits. About 8k the first time and 2k the second. They treated me like royalty 🙂


I had about 2,000 CDs. The burglars took about half the collection 😞


That's a lot of music


Do you still have that, or is all streaming now?


I left most of the CDs behind in England -- brought only a few hundred over, twenty years ago -- but I've re-purchased a lot of it on iTunes since. I have over 60GB of music now I think...


iTunes says I have 960 albums by 455 artists. 8,752 tracks.


That's a lot of music


The use cases are the same, storing data, in both cases JSON (with additional fields)


Chalk and cheese.


yeah, I get they both have good purposes, but here is what I'm thinking....


I'm very used to postgres, the libraries (thanks sean!) are great and blend lovely with Clojure. The thing that the user only wants to do is lookup data using an id - there isn't yet and I say yet any need for full text searching.


I presently use Elasticsearch, but now I have a requirement from the users to add notes to the data


and for that, having a little table with a simple straight-forward join to the parent is suuupar simple with PG (or any db)


We use both MySQL and Elastic Search at work. MySQL for structured, relational data. ES for less structured, searchable with complex, scored queries.


We don't do much text searching but we do geo searches, age range searches, etc.


I presently use the Postgis extension in PG to do geospatial stuff (works great)


The ability for pg to index on json data (and store it efficiently as jsonb) - also to search inside json has come a long way


I was happy using ES, but with the requirement to add notes, it requires mutation


and I choose ES originally as the json stored in ES would be (currently is!) immutable


I think I need to ask some more questions of the business


We post updated profile data to ES regularly -- every time a member changes their profile. We don't view ES as immutable.


My usecase is something around fraud


If they create data around fraud, they want that data not be changeable, since it could be used as part of an official investigation, so they need to know the state of the world at that precise point in time.


I know I may sound biased here, but it might be worth looking at Crux


Reason being your need for point in time queries. The bitemporality feature of Crux is probably perfectly suited for what you need here


Thanks for the tip! 🙂


Hmmm, indeed......I will do some research


We are open to new tech, but it really has to be justifiable, and cost effective.


Our CTO doesn't just want to throw in any new shiney toy (and as you know, devs love their toys)


If you want an accounting trail for fraud etc, Datomic is a perfect match. If you want fancy searching, ES is great. It's why we use both MySQL and ES. We "publish" member profiles into ES every time one changes, so we can do member searches of profiles (typical dating stuff). We also keep an audit trail of all changes to key parts of a member profile.


We talked to Cognitect about our use case and some parts were a perfect fit for Datomic and other parts were totally not appropriate. We didn't want to run both Datomic and MySQL so we chose to just run the latter. But we would have needed a dedicated search service on top of both of those anyway -- and we were using Transparensee's Discovery engine for years, before we switched to ES.

Jakub Holý (HolyJak)09:01:10

Out of curiosity (and as a fact to include in future decisions), what was it that was OK in MySQL but totally inappropriate in Datomic? Has it to do with the lack of excision in D. Cloud or st. else?


@U0522TWDA We have some datasets that are extremely large -- beyond Datomic's reasonable size range at the time -- and we have some very high write datasets, which doesn't match Datomic's model. Datomic would be a perfect match for some of our datasets, but not everything.

👍 4

I see totally the need to do fancy searches, and ES is fantastic at that.


I think I need to go back to the business and determine if they invisage that


I think they don't


they only thing they want to know is finding something by an id (of which the stuff was created at), and perhaps seraching inside notes to pull back the bigger picture.


We use Elastic Cloud for our ES setup. About $900/month for what we're doing, but it can be a lot cheaper if your data volume and search traffic is lower.


(or a lot more expensive if your volumes/traffic are higher!)


I'm going to have a ponder - in the end, it's really a business decision, so I have to present to them some options


and see what they think


My gut, based on what you've described, is that Datomic Cloud + Elastic Cloud might be the sweet spot...


yeah, indeed. I'm looking over the datatomic stuff atm.

Jakub Holý (HolyJak)09:01:20

FYI I heard from two devs that are very fond of Clojure that if they had to choose between the language and Datomic, they would pick Datomic. It is, presumabely, such a game changer.

Jakub Holý (HolyJak)09:01:20

Also, I enjoyed a lot and For persuading business about Datomic, have a look at and the resources it links to. The only problem with Datomic Cloud (contrary to on-premise) I have experienced is missing excision, i.e. the ability to delete old data. That is bad for GDPR but perhaps good for your use case.


in with psql there an easy way to convert a pgObject returned by agg_array into a hashmap, my feeling is no because .getType doesn’t return the schema it just returns the table name


@tavistock Have you read and the sections it links to? It sounds like you want to extend ReadableParameter to that type perhaps?


yea, i am using ReadableColumn to implement the pgObject conversion, whenever you use json_agg or the like it returns a pgObject with a type of "json" and whenever you use array_agg it returns a pgObject with a type of table name as a string. I was wondering if there was a way that other people were using to covert the latter pgObject into a hashmap but i can’t think of a way that it would be possible to do that.


it may not even be possible with the interface that pgObject provides.


to give an example in psql:

select COALESCE(array_agg(b) FILTER (WHERE IS NOT NULL) as bs, '{}'),
from a
left join b on = a.b_id
group by;


the bs would be a list of pgObjects with a getType of “b” and getValue of “(1,\“example\“)”


and i want to go from pgObject -> {:id 1 :field "example"}


Hmm, PostgreSQL is a tricky beast with all its custom types. Nearly all of my maintenance headaches on and next.jdbc come from PG users 🙂


There are a few PG-specific libs out there that handle extensions to I think -- maybe one of those will give some insight into how to deal with this?


(I don't use PG myself, precisely because of all this sort of pain!)


thanks, ill look and see if the approaches other people have taken for pg and will help me out, thanks for you work on everything so far has been perfect and well documented, so much so that the only problems i ever run into is pgObject stuff being weird


@tavistock I'm not exactly following your questions, but here is how I coerce between clj/edn and postgres....

👍 4

☝️ good stuff!