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

A database for 2022

tailscale.com

Post reply on HN
Print view View original

131–140 of 336 posts

Re: A database for 2022

#131

Post by statictype »

tptacek wrote: post #128
mathgladiator wrote: post #122

I believe using a large JSON file is not half bad, but you do run into the problem of how do you index and query it in meaningful. I actually ran into this problem when building a game because a document doesn't provide a great model.. The relational model is... JUST... SO... GOOD. And, it is a shame that most of the relational systems are so complicated. A document within Adama ( https://www.adama-platform.com/ ) is…

If you have a "single source of truth", sqlite/Litestream seems like a pretty-near-optimal way of taking advantage of the relational model while keeping design simplicity. I don't know what the higher-level architecture of Tailscale is, but we have the same problems; we have a complicated "single source of truth" that takes the form of a Consul cluster, but sqlite makes an absolute ton of sense for us, because we can…

It would be interesting to known why a standard boring RDS setup wouldn’t solve their problem completely. In fact I would be more interested to understand that than the actual details of sqlite tailing.

(I think the reason they gave was vendor lock-in, but apart from that, I didn’t understand why it wouldn’t be adequate)

Re: A database for 2022

#132

Post by billywhizz »

bestinterest wrote: post #93
nosefrog wrote: post #53

There's a lot of negativity here, so I just wanted to comment that I think the approach Tailscale is taking with sqlite is pretty neat. MySQL and Postgres are both pretty complicated, so gluing together two simpler systems, sqlite and litestream, sounds appealing, and I'm interested to hear how it turns out in the long run.

Agreed, it's a bit of a shame for HN imo. I see a team who is being brilliant and understanding their domain down to the core with as minimal resources as they can get away with. There is incredible value in incrementally adding complexity only when needed.

tailscale = YAGNI to the MAX! i applaud their willingness to think outside the box 99% of devs seem to be happy to squeeze themselves into just because they read about it in a book by some self-appointed tech god.

Re: A database for 2022

#133

Post by ignoramous »

jeffffff wrote: post #124
ignoramous wrote: post #95

Earlier quoted context omitted.

I'm not sure why you're being downvoted. You're right: running databases isn't for every team! Reach out for a managed database if you can. But tailscale isn't some random group of engs. They've probably got the chops to pull off literally anything they want to. I mean TFA casually mentions online cross-database transfers, multiple zero-downtime schema migrations, inspecting litestream's replication code for feasibil…

if they're this talented, is their time really best spent on dba work rather than improving the product?

> is their time really best spent on dba work...

It seems to me that tailscale engs want to avoid DBA work but also not use managed offerings, and so, they're comfortable paying the costs they have to (such as multiple migrations).

> ...rather than improving the product?

Well, you'd guess they want to be able to continually improve their already credible product too. When TFA points out that zero vendor lock-in and hassle-free, local end-to-end tests are non-negotiable, I think it is for this reason.

----

> if they're this talented, is their time really best spent on...

From: https://tailscale.com/blog/go-linker/

"People are often surprised and sometimes horrified when they learn that Tailscale maintains its own fork of the Go toolchain. Tailscale is a small startup. Isn't that a horrible distraction, a flagrant burning of innovation tokens?"

"Maybe. But the thing is, you write code with the engineers you have."

"We had a problem: We kept crashing on iOS, and in addition to being awful, it was preventing us from adding features."

"Another team might have decided to cut even more features on iOS to try to achieve stability, or limited in some way the size of the tailnet that iOS could interact with."

"Another team might have radically redesigned the data structures to squeeze every last drop out of them."

"Another team might have rewritten the entire thing in Rust or C."

"Another team might have decided to accept the crashes and attempted to mitigate the pain by making re-establishment of connections faster."

"Another team might have decided to just live with it and put their focus elsewhere."

"The Tailscale team has Go expertise, spanning the standard library to the toolchain to the runtime to the ecosystem. It’s an asset, and it would be foolish not to use it when the occasion arises. And the fun thing about working on low level, performance-sensitive code is that that occasion arises with surprising frequency."

"Blog posts about how people solve their problems are fun and interesting, but they must always be taken with a healthy dose of context. There may be no other startups in existence for which working on the Go linker would be a sensible choice, but it was for us."

Re: A database for 2022

#134

Post by billywhizz »

kevin_nisbet wrote: post #80
ramenmeal wrote: post #18

I think I'm missing some context. Using a text file and using etcd as a DB for a production system seems like a terrible engineering decision. It seems like something you'd do as a proof of concept or side project. It's interesting that they're blogging about this, as if they're proud of it. I guess I'm just missing the point. This is their 3rd DB Migration, something that I prefer to avoid at all costs. I guess they…

> But I'm just confused, why would an engineer want to join a company that is making these decisions? Why would the company want their users to know about these decisions? This might actually be a really good filter for which types of engineers are good fit for their company. Because my read was very different than yours, as I looked at the decision lineage and thought to myself I could see myself making every one of…

the live replication feature litestream is implementing won't be using s3 - it will be direct node to node replication. hasn't been released yet and currently s3 is used for a cold backup that can be quickly restored to a fresh node as far as i know. https://github.com/benbjohnson/litestream/issues/8

Re: A database for 2022

#135

Post by tptacek »

dastbe wrote: post #108
tptacek wrote: post #87

This thread has (at least at the moment) serious Bob Martin Sudoku Solver energy to it. Tailscale has solved an infamously complicated problem using, for the most part, simple tools. They're not just successful; they're remarkably successful, spookily successful, upsettingly successful. Consider whether the secret sauce here might not be au courant database choices, but rather something much harder for random teams t…

nobody goes to these restaurants for their omelets, though at the same time nobody should care how tailscale actually implements things so long as it works well. imo they’re not solving a notoriously hard problem, they’re realizing that they have the tiniest version of this problem (and that will most likely continue to be true). when that’s the case and you want to prioritize stuff that moves the needle like dev vel…

They don't, but there are other "finesse" dishes that people do in fact go to restaurants for that are notable for their simplicity, and the fact that you can only pull them off if you have flawless technique. Japanese, in particular, is notorious for this.

Re: A database for 2022

#136

Post by tedunangst »

dahfizz wrote: post #112

This should be a new logical fallacy: appeal to current year. Every time I hear someone say "it's $CURRENT_YEAR, we obviously need to implement $PARTISAN_POLICY" I wonder about what fringe politics will be "obviously correct" in 3022.

Nothing in this post claims that the year intrinsically makes this the correct choice. It is the database for 2022 because it is now 2022 and this is the database they are now using.

Re: A database for 2022

#137

Post by tptacek »

statictype wrote: post #131
tptacek wrote: post #128

Earlier quoted context omitted.

If you have a "single source of truth", sqlite/Litestream seems like a pretty-near-optimal way of taking advantage of the relational model while keeping design simplicity. I don't know what the higher-level architecture of Tailscale is, but we have the same problems; we have a complicated "single source of truth" that takes the form of a Consul cluster, but sqlite makes an absolute ton of sense for us, because we can…

It would be interesting to known why a standard boring RDS setup wouldn’t solve their problem completely. In fact I would be more interested to understand that than the actual details of sqlite tailing. (I think the reason they gave was vendor lock-in, but apart from that, I didn’t understand why it wouldn’t be adequate)

One obvious reason not to use RDS is wanting disk-local caches of information replicated from a single leader, rather than having every single machine in your fleet calling out to an external service on every read. That's certainly why we're not considering Postgres in our infrastructure, even though managed Postgres is a product we in fact offer.

We use Postgres! It's the backing state for our API, and an important source of truth in our architecture. Postgres is a great way of serving a GraphQL API. It is not necessarily a good way to back an infrastructure service.

Re: A database for 2022

#138

Post by billywhizz »

dave78 wrote: post #71
Aeolun wrote: post #44

Earlier quoted context omitted.

> why would an engineer want to join a company that is making these decisions? Hmm, I can’t quite articulate why, but I would. Something about having the courage to be different.

I would actually love to work at a company like that. I've been a professional developer for over 20 years now and at least in my experience, too much unneeded complexity has been the root cause of so many defects and product failures. I'm constantly fighting battles to keep things simple. All the young devs on my team want to use every fancy new technology that passes by, but I just want things to work for my custom…

> All the young devs on my team want to use every fancy new technology that passes by, but I just want things to work for my customers with the smallest amount of downtime and late night pages.

i feel your pain dave. resume driven development and FAANG envy seem to be the dominant characteristics of far too many folks in the industry these days.

Re: A database for 2022

#139

Post by tptacek »

jrockway wrote: post #127
tptacek wrote: post #87

This thread has (at least at the moment) serious Bob Martin Sudoku Solver energy to it. Tailscale has solved an infamously complicated problem using, for the most part, simple tools. They're not just successful; they're remarkably successful, spookily successful, upsettingly successful. Consider whether the secret sauce here might not be au courant database choices, but rather something much harder for random teams t…

People seem really stressed that they've changed databases twice before. Their service never went down and they didn't stop delivering features while all this was happening, so I don't see the big deal. You pick what works at the time, and incrementally evolve as problems and solutions become apparent. This article could have easily been "why we were down for a day while some auto-vacuum setting was broken." Then eve…

Another comment on this thread tried to dunk on them, saying that they'd done this so many times before (JSON to etcd, etcd to sqlite) that they must be getting really good at it. That comment struck me as so close to understanding what they're doing right here, it was painful.
Post reply on HN