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

An Unlikely Database Migration

tailscale.com

Post reply on HN
Print view View original

181–190 of 190 posts

Re: An Unlikely Database Migration

#181

Post by enneff »

npiit wrote: post #170
enneff wrote: post #155

Earlier quoted context omitted.

> Tailscale brings no real value compared to Zero-tier This article has nothing to do with Tailscale the product and everything to do with the team's unconventional approach to engineering. That's what HN is interested in and why the post is being upvoted.

There is nothing unconventional in moving from SQL to key-value distributed database. And if it was any other company that submitted this very same post here we wouldn't be talking here right now as it would have never gotten a single upvote. The posts of this company almost always come with their upvotes right after submission (by others) and the founders were surprisingly replying minutes after submission. This is…

> moving from SQL to key-value distributed database

You didn't read the article, clearly.

> The posts of this company almost always come with their upvotes right after submission

This has already been explained to you in other comments, so I just assume you're being disingenuous now.

Find a new hobby.

Re: An Unlikely Database Migration

#182

Post by dang »

npiit wrote: post #2

Unfortunately this company is known for its shady agressive marketing on hacker news. The upvotes count is really suspicious and this is not the first time. EDIT: Why is the downvoting? the post was given like 9 upvotes in the first 5 minutes. I frequently go to "new" and this is a highly suspicious behaviur.

That's not true. I deal with shady marketing every day, I know from shady marketing, this is not that, and I don't like seeing people unjustly accused. Please stop creating accounts to spread this falsehood.

Re: An Unlikely Database Migration

#183

Post by npiit »

enneff wrote: post #181
npiit wrote: post #170

Earlier quoted context omitted.

There is nothing unconventional in moving from SQL to key-value distributed database. And if it was any other company that submitted this very same post here we wouldn't be talking here right now as it would have never gotten a single upvote. The posts of this company almost always come with their upvotes right after submission (by others) and the founders were surprisingly replying minutes after submission. This is…

> moving from SQL to key-value distributed database You didn't read the article, clearly. > The posts of this company almost always come with their upvotes right after submission This has already been explained to you in other comments, so I just assume you're being disingenuous now. Find a new hobby.

I read the article and I understood that the authors are stuck in the 1990s and just discovered the staggering fact that their data fit distributed kv stores not traditional sql .

>Find a new hobby.

like circle-jerking on hacker news?

Re: An Unlikely Database Migration

#184

Post by chupy »

0xbadcafebee wrote: post #176
bradfitz wrote: post #159

Earlier quoted context omitted.

I'd answer questions but I'm not sure where to start. I think we're pretty well aware of the pros and cons of all the options and between the team members designing this we have pretty good experience with all of them. But it's entirely possible we didn't communicate the design constraints well enough. (More: https://news.ycombinator.com/item?id=25769320 ) Our data's tiny. We don't want to do anything to access it. I…

You say you want to have a small database just for each control process deployment to be independent. But you need multiple nodes for etcd... So you currently have either a shared database for all control processes, or 3 nodes per control process, or 3 processes per control node, etc. Either way it seems weird. I get that SQLite wouldn't work, but it also doesn't make sense to have one completely independent database…

> It's just not that widely understood in production as sql databases, and has limitations which you might reach in a few years.

Reaching limitations in a few years and biting that bullet makes the difference between a successful startup that knows when and where to spend time innovating or a startup that spends all their time optimizing for that 1 million simultaneous requests / sec.

Re: An Unlikely Database Migration

#185

Post by robben1234 »

petters wrote: post #87

> (Attempts to avoid this with ORMs usually replace an annoying amount of typing with an annoying amount of magic and loss of efficiency.) Loss of efficiency? Come on, you were using a file before! :-) Article makes me glad I'm using Django. Just set up a managed Postgres instance in AWS and be done with it. Sqlite for testing locally. Just works and very little engineering time spent on persistent storage. Note: I d…

>Article makes me glad I'm using Django.

This was my main thought throughout reading it. So many things to consider and difficult issues to solve it seems they face a self-made database hell. Makes me appreciate the simplicity and stable performance of django orm + postgre.

Re: An Unlikely Database Migration

#186

Post by 0xbadcafebee »

chupy wrote: post #184
0xbadcafebee wrote: post #176

Earlier quoted context omitted.

You say you want to have a small database just for each control process deployment to be independent. But you need multiple nodes for etcd... So you currently have either a shared database for all control processes, or 3 nodes per control process, or 3 processes per control node, etc. Either way it seems weird. I get that SQLite wouldn't work, but it also doesn't make sense to have one completely independent database…

> It's just not that widely understood in production as sql databases, and has limitations which you might reach in a few years. Reaching limitations in a few years and biting that bullet makes the difference between a successful startup that knows when and where to spend time innovating or a startup that spends all their time optimizing for that 1 million simultaneous requests / sec.

It's not about optimizing for scale, it's about optimizing for velocity. I don't care if I can only get to 1K RPS. I care if my team and product can work quickly. You cannot work quickly later if you slap something together now and later realize, oh shit, we have to stop pushing features for a month so we can completely rebuild the backend and everything that depends on it.

It's the devil you know versus the devil you don't. SQL is a very well understood devil, so your plans around it will be reliable. I would argue that being able to accurately estimate future work is the most valuable business asset.

Re: An Unlikely Database Migration

#187

Post by Quekid5 »

winrid wrote: post #151
a1369209993 wrote: post #135

Earlier quoted context omitted.

> Have you thought about durability, though. That one's actually weirdly difficult to guarantee... Strictly speaking, it's literally impossible to guarantee[0], so it's more a question of what kinds and degrees of problems are in- versus out-of-scope for being able to recover from. 0: What happens if I smash your hard drive with a hammer? Oh, you have multiple hard drives? That's fine, I have multiple hammers.

What happened to the first hammer :D

I guess it wasn't Durable.

Re: An Unlikely Database Migration

#188

Post by npiit »

dang wrote: post #182
npiit wrote: post #2

Unfortunately this company is known for its shady agressive marketing on hacker news. The upvotes count is really suspicious and this is not the first time. EDIT: Why is the downvoting? the post was given like 9 upvotes in the first 5 minutes. I frequently go to "new" and this is a highly suspicious behaviur.

That's not true. I deal with shady marketing every day, I know from shady marketing, this is not that, and I don't like seeing people unjustly accused. Please stop creating accounts to spread this falsehood.

What is this?

Re: An Unlikely Database Migration

#189

Post by dang »

npiit wrote: post #188
dang wrote: post #182

Earlier quoted context omitted.

That's not true. I deal with shady marketing every day, I know from shady marketing, this is not that, and I don't like seeing people unjustly accused. Please stop creating accounts to spread this falsehood.

What is this?

You've been creating multiple accounts to troll HN with weird shit about one company for over a year now. It's bizarre and we've banned you multiple times. Please stop doing this.

We've seen literally zero evidence for anything that you're saying. Actually there's strong evidence against it.

Re: An Unlikely Database Migration

#190

Post by npiit »

dang wrote: post #189
npiit wrote: post #188

Earlier quoted context omitted.

What is this?

You've been creating multiple accounts to troll HN with weird shit about one company for over a year now. It's bizarre and we've banned you multiple times. Please stop doing this. We've seen literally zero evidence for anything that you're saying. Actually there's strong evidence against it.

[dead]
Post reply on HN