111–120 of 122 posts
Earlier quoted context omitted.
I've never seen that in any db I've worked with. If that's true, that's pretty huge.
It is true. It was NOT true a year ago, but it is now. I pushed it hard, Aphyr pushed it hard, and the RethinkDB team worked very hard addressing every issue we found. That's why RethinkDB failing is so tragic.
Other successful companies have used this business model. Mobile is the most common use case for a real-time DB. They didn't provide good iOS and Android integration. Technically Rethink is superior to Firebase, but Firebase is more successful.
I believe the thinking was that rethinkdb would always sit behind an API, and if you think about it, its not a bad assumption.
Other successful companies have used this business model. Mobile is the most common use case for a real-time DB. They didn't provide good iOS and Android integration. Technically Rethink is superior to Firebase, but Firebase is more successful.
I'm pretty sure Horizon was meant to fill that niche, though my first look at Firebase had me cringing a little as some of the security model wasn't clear at all, and I am still apprehensive about not having a translation layer between your db and deployed apps that you control.
Other successful companies have used this business model. Mobile is the most common use case for a real-time DB. They didn't provide good iOS and Android integration. Technically Rethink is superior to Firebase, but Firebase is more successful.
Only used Firebase before, why Technically Rethink is superior to Firebase?
Earlier quoted context omitted.
Well it's easy to shard when you don't support joins or foreign key constraints. Btw, as a person who works on Firebase, perhaps you can answer this question that has been bothering me about it. There's no way to model a foreign key relationship that's traversable in both ways without trusting the client application to update both directions, right? Isn't that a bit of a dealbreaker for anything other than a toy app?…
[edit: this is an irrelevant remark] RethinkDB supports joins: https://www.rethinkdb.com/docs/table-joins/ "Like many traditional database systems, RethinkDB supports JOIN commands to combine data from multiple tables. In RethinkDB joins are automatically distributed—a join command is automatically sent to the appropriate nodes across the cluster, the relevant data is combined, and the final result is presented to th…
Earlier quoted context omitted.
We're an open CORE (caps for emphasis) deep tech company YC has funded in the deep learning space. We have proprietary software we sell as well as helping people go closer to the applications. We spend a lot of time on relationships with fortune 2000 vendors with existing channels for distribution. As the CTO of a startup like this I spend my time on coding, leading an engineering team, and managing partnerships with…
> " but usually such things are in the 6 figure category or later and require something larger than what a startup can pay." RethinkDB's support prices depended on the size and needs of the customer, so were very reasonable for my company.
If I was doing support for startups that weren't paying me very much, I would have to question the return on investment there.
I was trying to say, that startups as customers are a bad idea and that support contracts if you DO have them as a business model should be in that range.
> Why do you fund ... companies ... which have no clear (to me) business model?
It's a great question and I used to wonder it myself.
Consider it in the engineering domain: companies get investment to do development. Some may have only an idea, some may have a prototype, some may have a product and need money for growth (these get the highest valuation as they have the lowest risk, but also tend to have the lowest returns). I don't think any of that should surprise anyone.
Well; companies appear in the same distribution of states in the business domain. Some, like Google, have no business model in mind and almost fail because of it. Some have a business model which does't look well baked but the entrepreneurs seem to understand it, so can probably develop it into something worthwhile.
And of course there are there ones where the investors want to know more about the sector. Open Source was like that back in the late 90s.
Earlier quoted context omitted.
Firebase works like that. The polling of databases is a really obvious limitation of existing databases once you see the alternative. (I work at Firebase)
Has Firebase been through Aphyr's Jepsen tests?
Earlier quoted context omitted.
In my opinion rethinkdb is super easy to get going and use. The low touch maintenance is what drew me originally. However, learning to live without transactions takes some rethinking of the approaches taken. It's totally doable but it may not come easy if you're used to transactions in an RDBMS. Of course in today's distributed multi service multi database world, learning to live without transactions is becoming more…
if "Databases should be indistinguishable from magic" then somehow you should be able to get transactions
Earlier quoted context omitted.
You can use it as the mobile device connector as clientside auth, push, latency compensation, presense and offline persistence are big features on their own. For sensitive joins, have a server side joiner with administrative privileges. Still, it's work that should be easier I agree. Firebase's strength is not what other DBs can do, but what they cannot.
I'm curious what Firebase users do in real life. Do people realize this is a problem? I can imagine making an app like that where all mutations go through my server and reads go through Firebase. How would this interact with the offline persistence feature though? I suppose you could allow the client to do some simple mutations like editing text fields. For the mutations that must go through the server, though, perha…
Instead, your server should listen to the Firebase, rather than have writes go a separate path (which loses lots of useful features). I think the term now is a client-database-server architecture.
it's not actually a problem for 90% of apps. It's usually in the users best interest not to break their relationships in the db. Think chat. Think info services like Pokemon. Cross table transactions are relative minority in the space of useful apps that's can make money. For those more complex domains, you need technical know how, and Firebase is a useful system component in a larger architecture.