Hmm why didn't mongodb ever take off with Clojure? You'd think it would be a really good fit.

A lot of people have a very low opinion of mongo. For all kinds of reasons, including the query language, the data model, and in the past maybe still, chose unsafe defaults to appear faster

Clojure is a fantastic fit for the relational model

A table is like a seq of maps

> why didn't mongodb ever take off with Clojure? If I were to guess, when your programming language is far better at working with heterogenous data than <Database>, you don't need to offload that burden to the DB.

More generally, I feel like people found the good parts of RDBMSes by way of finding the bad parts of NoSQL dbs (and vice-versa). Since a massive swath of business-as-usual software has forever been solved under the relational model, it seems reasonable that people will want guarantees that traditional RDBMSes provide. Anecdotally, too often a service/app + NoSQL db basically grows to become example of Greenspun's Tenth rule applied to DBs; viz. the combination becomes an ad-hoc, informal, bug-ridden, slow implementation of half an RDBMS. Also machines have become so phenomenally capable, that choosing a distributed system (common value proposition proffered by NoSQL vendors) is less and less of a good choice even for reasonably large scale mission-critical applications. Zerodha offers https://zerodha.tech/blog/hello-world/ of this (~Xx Terabytes of data in one Postgres box, for a heavily used stock brokerage---up to 7 million trades/day).

Wow, how have I never seen this talk before? Better late than never! https://www.youtube.com/watch?v=3ka4KY7TMTU

> why didn't mongodb ever take off with Clojure? Probably because Mongo was a fad and people who chose it did so because other people chose it. You can apply that to NoSQL in general. I'm not sure that people who choose an obscure language like Clojure are crowd followers 😛 Maybe a better way of putting that is to say that Clojure developers are not evaluating the language based on superficial characteristics, such as syntax, but on a deeper understanding of what is useful in a language. I think people who choose Mongo do so mostly because it appears to be convenient at a superficial level. In other words the 2 sets of users evaluate technology against a different set of criteria that simply don't overlap.

My dirty secret is that I learned Clojure because I liked the parenthesis syntax in emacs-lisp :(

some other dbs adopted/support the query langage and wire protocol even

fdb comes to mind

(FoundationDB)

Honestly, MongoDB is a pain to use. It sounds wonderful in theory, but in practice, to have all the minimum guarantees that a DB should have (you know, you save your data and it indeed saves, not silently destroys it? Anyone?) MongoDB ends up being the same speed, or a tad slower than PostgreSQL for example. Now combine that with the idea of documents (that, IMHO, does not translate well to how things work in practice) and design decisions that you can have that may haunt you forever (for example, save authors under books, and then sometime in the future someone asks for every book a specific author wrote, even considering pen-names) and now you have a HUGE PAIN to deal with. Most people (me included!) that worked with MongoDB were not aware that there are a HUGE list of features in PostgreSQL (for example) that makes relational databases fun again - JSONB, but also arrays (no more "join-tables", you can put address_ids in a single field (no foreign keys for now, but hey, Mongo also doesn't offer it!)), custom indexes, etc...

early on mongodb was a semi decent choice for quick & dirty prototypes, and pg didn't have all the bells & whistles it has now (it was still great)

you had to rewrite the whole thing eventually tho if there was adoption, so there's that. But some made it work quite far (I think foursquare use(d) it)

clojure programmers have a propensity towards writing obviously correct programs; mongodb had some high profile correctness/consistency issues

(it's reductive, but that's how I remember it)

the jepsen reports tore mongodb apart

I felt embarrassed for them

yup, that was bad

but I also saw how it was to operate it at my last job

the team that used it was constantly in pain from it

I was a mongodb cluster admin from 2013-2015, and I rather enjoyed mongo from the ops side

I remember doing a cluster upgrade from 2.4 -> 2.6 -> 3.0, adding a TLS jacket along the way, and we didn't drop a single connection

but I didn't had to use it an app developer 😅

that said most dbs do require a fair amount of work to maintain if you diy

(not talking about the managed offerings)

I remember hearing the difference in experiences of operation when the jepsen report came out, too. not sure why that is

I remember when we tinkered with mongodb when NoSQL became a thing (or some time after). Our conclusion was: hey this is just a cache?

I have upgraded mongo versions from 3.4->3.6 and now 4.0->4.2 with no downtime. I was a client of a SaaS but AWS RDS still takes the DB down for 10-30 minutes for a major upgrade.

So I would love if Postgres had the same ops story as mongo, with a built-in router, no downtime failover etc etc.

Regarding mongo syntax, I prefer working with maps rather than with strings. If it wasn't for HoneySQL I'd be very sad in Clojure land.

The main reason we are moving away from Mongo is joins: Mongo is just not the right fit.

a fun set of conference micro/lightning talks: Say nice things about technologies you don't like

Regarding why people chose Mongo without looking much into it, a former colleague was maintaining that Mongo + JS are ideal matches because Mongo stores JSON and JS processes JSON natively. First claim is false and second claim irrelevant - but you can see how people can arrive at this conclusion.

My take is that if your data naturally represents as documents it might be a good idea to consider a document database. If your data is highly relational, it’s probably best to go with a relational database. You also need to consider ACID-requirements for your data and processes. In some cases throughput might be more important than integrity and in other cases you might have to make several complex transactions with hard consistency guarantees. Yet another thing is what are the typical access patterns to the data. Once these are clear enough it’s time to choose appropriate technology and do your homework well. 🙂

Who here's gearing up for tomorrow's World Cup Draw? (apologies to everyone in Italy, and Egypt, and anyone else whose National Football Teams did not qualify)