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

151–160 of 336 posts

Re: A database for 2022

#151

Post by bArray »

(Ignoring the fact this may be an April fools joke.)

> We’re going to put everything in a single file on disk again.

For most small scale projects I'm just reading and writing lines to a file on disk. Sure, I could over-engineer some database, or I could get a minimal viable project off of the ground and worry about scaling later. Most projects run into issues long before scalability.

I found myself recently wanting a lightweight key-value store for random structures. For this purpose, I created a toy single-file key-value store [1] in less than 256 lines of C. It's not quite ready for prime time, but it's incredibly easy to use.

[1] https://gitlab.com/danbarry16/u-database

Re: A database for 2022

#152

Post by 0des »

reilly3000 wrote: post #146
tptacek wrote: post #143

Earlier quoted context omitted.

I did commit the cardinal sin of HN metacommentary and referred to the state of the thread at a point in time as if it was a durable property of the thread, which was a mistake I own and take full responsibility for.

If anything, this ^^^ is how you win the long game. History will surface itself when you make assertions. Gracefully revocability scales.

At least he's not the Dropbox guy

Re: A database for 2022

#153

Post by jitl »

tapirl wrote: post #110
database_guy wrote: post #33

Earlier quoted context omitted.

It started as a proprietary database. Apple acquired it and then open sourced it eventually.

Didn't it start as an open source database? then apple acquired it and made it close sourced, then open sourced it again after several years. It is weird that this DB has a good reputation which doesn't match its popularity.

FoundationDB was the first publicly available distributed transactional KV on the market that I can recall. It wasn’t “open” though - always proprietary. They generated a lot of hype and good press for being this NoSQL DB that was all about ACID correctness in the age of “mongo is webscale (by writing to /dev/null)”. They had a demo showing impressive throughout on a low power cluster with no data loss during a power cycle. I think that despite generally impressive tech they had some trouble selling but did end up selling the company to Apple.

Re: A database for 2022

#154

Post by ctopher7 »

a little bit oot, but just installed tailscale on my dev stack (ec2, bare metal at home and my macbook air). mindblown by its simplicity and "it just works". Use it for logging purposes (ELK is too heavy for free tier ec2) and CI/CD (again, too heavy for my free tier ec2)

Re: A database for 2022

#156

Post by jeffffff »

tptacek wrote: post #144
jeffffff wrote: post #119

Earlier quoted context omitted.

they've already had to migrate twice due to questionable technology decisions. having to migrate again due to needing to change cloud providers seems a lot less likely than having to migrate again because their outside the box technology choice didn't pan out.

"Questionable technology decisions". You're trying to dunk, but I don't think you understand where the hoop is. Their technology decisions have panned out Tailscale well . We should all be so fortunate. This isn't Twitter with the "fail whale"; the only reason you know about any of this stuff is because they wrote about it. They ran their entire service with a JSON file backend for 18 months, and switched from it to…

i really don't know a ton about this product or team but it sounds like if they had used aurora mysql or aurora postgres in the first place then there would be nothing to write a blog post about because it would've just worked and kept working. they say they want to avoid vendor lock-in but if the vendor became a real issue they'd be doing their first migration instead of being on v3 already. additionally, their bespoke solution relies on s3, which is also a vendor-specific technology, so it seems like they haven't avoided vendor lock in? i've seen many cases of developers doing more work to avoid vendor lock-in than it would take to replatform if it ended up being a necessity, and this really feels like that looking at it from the outside. i'd understand this better if mysql or postgres couldn't solve their problem, but that is not the case here, and i can't wrap my head around a company who is ok with their devs reinventing a very good wheel 3 times when the obvious choice would've worked fine the first time. it seems like they are successful in spite of these decisions, not because of these decisions.

https://mcfunley.com/choose-boring-technology

Re: A database for 2022

#157

Post by jimbokun »

tptacek wrote: post #135
dastbe wrote: post #108

Earlier quoted context omitted.

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.

There’s a manga about a food critic (Oishinbou [1]), where he takes another food critic to a hole in the wall Tokyo restaurant as an example of elite cooking. The chef-owner brings him his meal.

Which is just a piece of cooked fish, rice, and miso soup. The critic is first almost insulted by such a simple meal. But then realizes the fish, rice and soup are prepared to perfection, and is amazed at the chef’s skill.

[1] https://en.wikipedia.org/wiki/Oishinbo

Re: A database for 2022

#158

Post by tptacek »

jeffffff wrote: post #156
tptacek wrote: post #144

Earlier quoted context omitted.

"Questionable technology decisions". You're trying to dunk, but I don't think you understand where the hoop is. Their technology decisions have panned out Tailscale well . We should all be so fortunate. This isn't Twitter with the "fail whale"; the only reason you know about any of this stuff is because they wrote about it. They ran their entire service with a JSON file backend for 18 months, and switched from it to…

i really don't know a ton about this product or team but it sounds like if they had used aurora mysql or aurora postgres in the first place then there would be nothing to write a blog post about because it would've just worked and kept working. they say they want to avoid vendor lock-in but if the vendor became a real issue they'd be doing their first migration instead of being on v3 already. additionally, their besp…

You should start by learning more about the product, and then tell them they should use Aurora for all their backing store.

Re: A database for 2022

#159

Post by astrange »

tapirl wrote: post #110
database_guy wrote: post #33

Earlier quoted context omitted.

It started as a proprietary database. Apple acquired it and then open sourced it eventually.

Didn't it start as an open source database? then apple acquired it and made it close sourced, then open sourced it again after several years. It is weird that this DB has a good reputation which doesn't match its popularity.

The source was licensed to some people but it wasn’t open source IIRC.

Re: A database for 2022

#160

Post by jeffffff »

ignoramous wrote: post #133
jeffffff wrote: post #124

Earlier quoted context omitted.

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

> 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 zero vendor lock-in and hassle-free, local end-to-end tests are non-negotiable, why are they using s3? migrating to another s3 compatible backend would be similar in effort to migrating from aurora mysql or postgres to another managed mysql or postgres service or to self-hosted mysql or postgres

Post reply on HN