Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RethinkDB: why we failed (2017)

defmacro.org

Post reply on HN
Print view View original

221–230 of 237 posts

Re: RethinkDB: why we failed (2017)

#221

Post by assface »

geophile wrote: post #167

So much of this is familiar. I was at two database startups. The first one, an object-oriented database company (last 80s, early 90s) suffered from an extreme case of misperceived markets, due to the occasionally intentional blurring of the lines between a "database system" (which means SQL to nearly everyone, and we didn't to SQL), and a persistent storage class added to C/C++ (and later Smalltalk and Java). The sec…

>The second one (mid 2000s) was a neat physical storage trick, which should have been a feature of a database system, not an excuse for building a new one.

Can you say what database this was? Akiban? SchoonerSQL?

Re: RethinkDB: why we failed (2017)

#222

Post by dreamcompiler »

Aeolun wrote: post #54
dreamcompiler wrote: post #39

Earlier quoted context omitted.

Those are the exceptions that prove the rule. It's not impossible to succeed in developer tools; it's just a lot harder than other markets. And you usually also need an accidental luck factor like being the perfect product at the perfect time.

More like all dev tools that I can buy as an individual are easy to pay for. Things like a database would have to go through procurement if I wanted to use them and they weren’t free, and I avoid procurement like the plague. Why the hell wants to spend their time justifying why something is the best solution to people that don’t have a clue. I’d only go through that if the difference in quality was so palpable that I…

I have a whole rant about procurement -- don't get me started. The basic idea is that procurement should exist to enable mission performers to do their jobs with less friction, while ensuring legal compliance and minimizing cost to the company. But in fact procurement organizations often seem to think they exist solely to impede mission performers. This is not really their fault; it's just how their incentives are structured.

Re: RethinkDB: why we failed (2017)

#223

Post by Can_Not »

fastball wrote: post #197
nonpolitic wrote: post #61

> Developers love building developer tools, often for free. So while there is massive demand, the supply vastly outstrips it. This is key, and plays out over and over again in different forms. There are no points for difficulty, only supply and demand. PG puts this well [1]: > That's the essence of a startup: having brilliant people do work that's beneath them. Big companies try to hire the right person for the job.…

We're experiencing this a bit with our startup, except we're not building developer tools, we've built a (semi-personal) knowledge management platform. In the era of COVID, it seems like every developer with some extra free time has decided that they want to build their own PKM/note-taking/etc app, so competition has scaled up massively in the last year.

> it seems like every developer with some extra free time has decided that they want to build their own PKM/note-taking/etc app, so competition has scaled up massively in the last year.

Still none with dark mode, native apps, markdown.

Re: RethinkDB: why we failed (2017)

#224

Post by senderista »

mrweasel wrote: post #64
senderista wrote: post #57

Earlier quoted context omitted.

They finally got their engineering act together (via the Sleepycat acquisition), long after they'd made it big.

Didn’t Oracle buy Sleepycat?

Yes, my bad, I was referring to WiredTiger (still the same folks).

Re: RethinkDB: why we failed (2017)

#226

Post by zxspectrum1982 »

hibikir wrote: post #156
RedShift1 wrote: post #133

Earlier quoted context omitted.

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 t…

I concur. I was project manager for a migration from Microsoft SQL Server to Azure SQL. There were all sorts of problems, performance being one of them.

Re: RethinkDB: why we failed (2017)

#227

Post by cutemonster »

nostrademons wrote: post #210
thu2111 wrote: post #118

Earlier quoted context omitted.

But most companies could do things their suppliers do, because companies always have the option of hiring people with those skills and developing those competencies in house. E.g. Google moved from running their software in commercial datacenters to building their own, or how Amazon has progressively taken over more and more of the supply chain. Android is sold to firms that can build their own mobile operating syste…

That's an option in the same way that anyone can go back to college, specialize in pre-med, go to med school, complete residency, and then become a doctor. It's possible in theory. In practice, you're looking at a decade+ of your life, with significant risk that each step fails. So it is with companies bringing core competencies in-house. Each step takes time, and is fraught with risk. It's not a matter of simply hir…

> That's an option in the same way that anyone can go back to college, specialize in pre-med [ ... ]

Another analogy: Tesla's customers get the idea to just design and build their own cars instead.

Thanks for an insightful reply -- slightly helps me when thinking about my own projects

Re: RethinkDB: why we failed (2017)

#228

Post by bob1029 »

jandrewrogers wrote: post #22

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 basically our play. We took SQLite and wrapped a very compelling business app around it. None of our customers give a single shit that we use SQLite vs SQL Server, aside from passing comments on the IT deep dive calls.

"You don't need us to install any database software?"

"nah we have our own integrated data persistence mechanism".

"Cool. So about those firewall rules..."

That is about the extent to which our customers care. They are more interested in what actually shows up on their display and how stable the solution is than any particular technology choices we decided to make on their behalf.

No one wants to be responsible for picking a database engine. Pick it for your customers. That's part of the engineering.

Re: RethinkDB: why we failed (2017)

#229

Post by klysm »

bob1029 wrote: post #228
jandrewrogers wrote: post #22

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 basically our play. We took SQLite and wrapped a very compelling business app around it. None of our customers give a single shit that we use SQLite vs SQL Server, aside from passing comments on the IT deep dive calls. "You don't need us to install any database software?" "nah we have our own integrated data persistence mechanism". "Cool. So about those firewall rules..." That is about the extent to which our…

Out of all the database products out there, I probably trust SQLite the most to do what I ask of it.

Re: RethinkDB: why we failed (2017)

#230

Post by geophile »

assface wrote: post #221
geophile wrote: post #167

So much of this is familiar. I was at two database startups. The first one, an object-oriented database company (last 80s, early 90s) suffered from an extreme case of misperceived markets, due to the occasionally intentional blurring of the lines between a "database system" (which means SQL to nearly everyone, and we didn't to SQL), and a persistent storage class added to C/C++ (and later Smalltalk and Java). The sec…

>The second one (mid 2000s) was a neat physical storage trick, which should have been a feature of a database system, not an excuse for building a new one. Can you say what database this was? Akiban? SchoonerSQL?

A cognoscenti! It was Akiban.
Post reply on HN