[potatolicious]

Ah yes. I once worked at a startup that insisted on Mongo despite not having anywhere near the data volume for it to make any sense at all. Like, we're talking 5 orders of magnitude off of what one would reasonably expect to need a Mongo deployment.

I was but a baby engineer then, and the leads would not countenance anything as pedestrian as MySQL/Postgres.

Anyway, fast forward a bit and we were tasked with building an in-house messaging service. And at that point Mongo's eventual consistency became a roaring problem. Users would get notifications that they had a new message, and then when they tried to read it it was... well... not yet consistent.

We ended up implementing all kinds of ugly UX hacks to work around this, but really we could've run the entire thing off of sqlite on a single box and users would've been able to read messages instantaneously, so...

[nicoburns]

I've seen similar with Firebase. Luckily I took over as tech lead at this company, so I was able to migrate us to Postgres. Amusingly, as well as being more reliable, the Postgres version (on a single small database instance) was also much faster than the previous Firebase-based version (due to it enabling JOINs in the database rather than in application code).

[potatolicious]

Funnily enough prior to this startup I had worked at a rainforest-themed big tech co where we ran all kinds of stuff on MySQL without issue, at scales that dwarfed what this startup was up to by 3-4 orders of magnitude.

I feel like that's kind of the other arm of this whole argument: on the one hand, you ain't gonna need that "scalable" thing. On the other hand, the "unscalable" thing scales waaaaaay higher than you are led to believe.

A single primary instance with a few read-only mirrors gets you a reaaaaaaally long way before you have to seriously think about doing something else.

[toast0]

> On the other hand, the "unscalable" thing scales waaaaaay higher than you are led to believe.

Agreeing with you... Any reasonable database will scale pretty far if you put in a machine with 160 cores and 3 TB of RAM. And that's just a single socket board.

There's no reason to do anything other than get bigger machines until you're near or at the limits of single socket. Dual socket and cpu generations should cover you for long enough to move to something else if you need to. Sharding a traditional database works pretty well in a lot of cases, and it mostly feels like the regular database.

[nicoburns]

That, and a lot of companies don't have the scale they think they have.

The Postgres database for a company I worked for (that was very concerned about scaling when they interviewed me because their inefficient "nosql" solution was slow) ran very happily on a machine with 2 shared CPU cores and 4GB RAM.

[andoando]

Dawg tinder was operating at 20M DAU with all its DB based on Dynamo. Probably still is.

And yeah there was ton of those issues but yolo

[walkabout]

I watched a company you've probably heard of burn stupid amounts of money because one guy there was trying to build a personal brand as a Graph Database Expert, and another had fallen hard for Neo4j's marketing. Stability issues, stupid bugs, weak featureset, mediocre performance for most of the stuff they wanted to do (Neo4j, at least at this time, was tuned to perform some graph-related operations very fast, but it was extremely easy to find other graph-related operations that it's terrible at, and they're weren't exactly obscure things) all stretching out project development times to like 2x what they needed to be, with absolutely zero benefits for it. So fucking dumb.

Meanwhile all they needed was... frankly, probably SQLite, for their particular use case, having each client of theirs based around a single portable file actually would have been a big win for them. Their data for each client were tiny, like put-it-all-in-memory-on-an-RPi2 tiny. But no, "it's graphs so we need a graph database! Everything's graphs when you think about it, really! (So says Neo4j's marketing material, anyway)"