Live data from Hacker News

RethinkDB: why we failed (2017)

defmacro.org

151–160 of 237 posts

Re: RethinkDB: why we failed (2017)

#151
post #66

> People wanted RethinkDB to be fast on workloads they actually tried, rather than “real world” workloads we suggested Uh no, It was slow on real world workloads, you just don't want to admit it.

I think that's his point. That's why he put "real world" in scare quotes.

I dont think so because he could have said it plainly since it was generally slow, but instead he implied that the use cases users were trying weren't "real world" use cases that fit within what a database of its class should be able to do. Hes not being totally honest about the performance issues and how much of an impact it had on their failure.

Re: RethinkDB: why we failed (2017)

#152

Database startups suffer from an extreme case of an important truism in startups generally: the product you think you are selling is not the product the customer thinks they are buying. No one buys a database per se , they are just a means to some other end. People that love database technology — that would be me — tend to start database companies. It is very difficult to sell a database. It is much, much easier to s…

This the key. I'm also a dreamer of a better RDBMs (https://tablam.org) and wish I could live doing it... but working on the sector of small business what they want is a better access/excel. Probably that is what bigger companies want too.

So the internal tech is just a mean to make that possible. I think if a db engine provide the equivalent of the auto-admin of Django it will sell itself easily :)

However this is also hard because DBs engines touch several complex things (storage, concurrency, compilers, interpreters, etc) and is hard to find people for this plus the funding.

Re: RethinkDB: why we failed (2017)

#153

Database startups suffer from an extreme case of an important truism in startups generally: the product you think you are selling is not the product the customer thinks they are buying. No one buys a database per se , they are just a means to some other end. People that love database technology — that would be me — tend to start database companies. It is very difficult to sell a database. It is much, much easier to s…

This is exactly why Oracle in the 90s and 00s starting buying up software Application companies (Peoplesoft, JD Edwards, Hyperion, etc). And then in the old on-premise world, you sell them both the App and require the use of your database which is an additional sale. This strategy doesn’t work in a Cloud world though. Since customers are no longer buying the individual components (like the database) but are instead j…

IIRC, Oracle managed to get a huge, well paying customer (DoD) behind their "we build a better database" pitch.

That provided enough funding, users and support to move into applications. In fact even if they didn't expand into other areas, that support could have kept them as a profitable DB company for decades.

Re: RethinkDB: why we failed (2017)

#154
post #34

This is akin to everyone’s dream to start a cozy, atmospheric coffee shop. These types of coffee bars fold very quickly or at best give founders years of servitude below minimum wage. The reason is that the type of behaviour this kind of establishment encourages - lounging, book reading, laptop work is exactly the opposite of the quick serve model that is conducive to high revenue. The customer loves this model, the…

Interesting, I think this is why private clubs used to be a thing and may be the only way to get a sustainable cozy, atmospheric coffee shop. Because really that's what you're selling, not coffee, but atmosphere. And membership is a way to charge for your real product.

> private clubs used to be a thing

They are absolutely still a thing in every major city.

Re: RethinkDB: why we failed (2017)

#155
post #138

Earlier quoted context omitted.

Querying is in pure JS, easy to do stuff programmatically. But if starting new, with a team that did not know Mongo well already, not a real advantage. I still prefer querying something nested in mongo to querying something nested in JSONB, but I can work with either. And back when I started with it, JSONb did not exist. I would say JSONB was also a godsend though as our roadmaps now have a clear path to something we…

I can't follow this through, I'm interested in nosql databases because there are indeed patterns of access where a db as a key value store is helpful. > Querying is in pure JS, easy to do stuff programmatically. You mean you do your logic at the application layer? Like if you need X objects and Y objects where Y have an identifier to the X objects they're related to you build them in JS after retrieving them? What is…

Oh no, apologies for the lack of clarity. I would not get the whole thing and build it in the application layer before sending it to the client.

If I want a particular array item nested a few levels in a JSON, the query as JSON object instead of query as an SQL is just a bit easier to put together (which is what i mean by pure JS). Sometimes, putting complex queries together takes fewer lines of code. Neither is really better or worse.

But I want the database doing the work and want to transform as little as possible on the application layer. Sometimes it is inevitable, but sub-optimal, for sure.

In terms of anything where you need to do a lot of joins when querying -- NoSQL is not good and I would not advise Mongo at all. It depends on what you are building. A lot of applications (and even games) now just pass JSONs around. If I show a user profile, I get that json. If, on the profile, I need to show where she lies in a leaderboard, that react component hits a separate API call to get the data needed for it, etc.

But no difference really. And yes, if the JSON is just a column in postgres, even the early stuff is nearly as easy as it is in postgresql.

If I were looking at a DB for a simple key/value store, I would not look at Mongo. Others here likely know better, but I pick up Redis (out of habit, but also it is awesome even if overkill in many scenarios). Mongo would do it but I would not do so except temporarily. I tend to throw Redis in my stacks early in development as I tend to need it later.

BTW by no means do I love Mongo. For example, Mongo is awful when it comes to things simiilar to joining in SQL land. You end up in these hellscapes where there is no choice but to store a ton of redundant data. Is it the end of the world? No, storage is cheap. But is it good? No.

And I am old so I do not find the value in arguing about tools. It is like me hating a hammer. I am interested in what is better and what folks here think about things coming down the pipeline, or whether Arango is worth looking at, etc. But I do appreciate your sort of inquiry as I have learned from it -- for example I did not know you can index inner fields of JSONs. I really need to revisit is as recent versions of PG seem to get better and better.

Context matters a ton. If you are going right to production with something, that is not really where I operate. But in general, as many have said, if more than one thing will do it, the best tool is the one you know best. You are likely to implement it efficiently, etc.

Re: RethinkDB: why we failed (2017)

#156

Earlier quoted context omitted.

How’s Snowflake doing? One thing these database companies have going for themselves, is that once a customer company’s data and code is locked in to a particular database, then it becomes very very hard to get out. Not impossible, but just very difficult.

I've heard this line many times but is this actually true? Are there stories or statistics of these things?

Even the migrations that appear small end up being huge. Over a decade ago, I was working for a large biotech company, which at the time was having trouble with their Oracle installation. The technical team, being very conservative, and having never worked anywhere else before, decided that the easiest way out was to purchase a large Exadata machine, as that was the less risky proposition: It's still supposed to be the same Oracle they knew and loved, except faster, and in far bigger iron than they were running before. So they ignored the scary price tag, believing that they were going to save a mint in recreating their data store.

Well, things weren't this easy. It was Oracle alright, so all the queries, triggers and views still worked... except the performance characteristics were completely different, because Exadata does all kinds of interesting things to extract more performance. So all the hints, manual query plans? just downright wrong, and often slower than before. In the end, easily a third of the queries needed rewrites, plus all the internal tuning changes that the very large DBA team did to make queries perform well. The whole effort cost many thousands of man months, on top of the oracle hardware, and the never cheap oracle license.

So even a migration from Oracle to a different flavor of Oracle can end up freezing a department with hundreds of tech workers for a year, and this was considered to be the cheapest choice! Imagine how much fun this would be if it was a large lift that, say, went from a RDBMS to NoSQL.

Re: RethinkDB: why we failed (2017)

#157

Database startups suffer from an extreme case of an important truism in startups generally: the product you think you are selling is not the product the customer thinks they are buying. No one buys a database per se , they are just a means to some other end. People that love database technology — that would be me — tend to start database companies. It is very difficult to sell a database. It is much, much easier to s…

Joel Spolsky wrote about this quite a few times, Architecture astronauts take over "What is it going to take for you to get the message that customers don’t want the things that architecture astronauts just love to build. The people? They love twitter. And flickr and delicious and picasa and tripit and ebay and a million other fun things, which they do want, and this so called synchronization problem is just not an a…

> paying untenable salaries to kids with more ultimate frisbee experience than Python, whose main job will be to play foosball in the googleplex and walk around trying to get someone…anyone…to come see the demo code they’ve just written with their “20% time,” doing some kind of, let me guess, cloud-based synchronization… between Microsoft and Google the starting salary for a smart CS grad is inching dangerously close to six figures and these smart kids, the cream of our universities, are working on hopeless and useless architecture astronomy because these companies are like cancers, driven to grow at all cost,

Re: RethinkDB: why we failed (2017)

#158

Earlier quoted context omitted.

> I think jetbrains, github, atlassian et al would like a word with you. Yeah, but those are outliers drowning in a sea of free development tools. The price that they can charge is effectively limited by how much it would cost some to replicate the subset of that tool that they actually use. A business that is paying $X/year for $DEVSOFTWARE for their entire devteam pays that only while $X is less than the cost of pa…

Do you know any company that seriously wrote their own development IDE or project management solution comparable to Jira for internal use? That sounds like absolute madness to me. I agree though that you should never sell to developers, most of them really don't care how they spend their time as long as they are occupied and work on something they deem interesting, so they will happily spend months or years reinventi…

> Do you know any company that seriously wrote their own development IDE or project management solution comparable to Jira for internal use? That sounds like absolute madness to me.

I worked for one and you're right, it was madness. They still did it though.

Re: RethinkDB: why we failed (2017)

#159

Read The Economist religiously. It will make you better faster. You can read the Economist if you'd like, but it won't make you a better entrepreneur. Instead, find people who are smarter than you (in your area), do everything you can to convince them to spare you some of their time, and then be a humble (but discerning) sponge of information. The challenge in fast changing markets is that the best information isn't…

Agreed, that part struck me as odd. I think it's making the job more intellectual than it is.

I would add to your list: spend as much time as possible with customers and figure out the actual pain.

Re: RethinkDB: why we failed (2017)

#160
post #34

This is akin to everyone’s dream to start a cozy, atmospheric coffee shop. These types of coffee bars fold very quickly or at best give founders years of servitude below minimum wage. The reason is that the type of behaviour this kind of establishment encourages - lounging, book reading, laptop work is exactly the opposite of the quick serve model that is conducive to high revenue. The customer loves this model, the…

Interesting, I think this is why private clubs used to be a thing and may be the only way to get a sustainable cozy, atmospheric coffee shop. Because really that's what you're selling, not coffee, but atmosphere. And membership is a way to charge for your real product.

Or charge for time, like Ziferblat do: https://ziferblat.co.uk/
Post reply on HN