Live data from Hacker News

A database for 2022

tailscale.com

281–290 of 336 posts

Re: A database for 2022

#281
post #23

I for one am enjoying this. Sure they could probably just use a regular ol' database, but where is the excitement in that!

Excitement is only for people who are learning.

you should always be learning. and excited when you are. do you know everything?

Re: A database for 2022

#282

Earlier quoted context omitted.

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

Some examples: they could get rid of that pointless bootstrap on their website, they are shoving almost 1.5 MBs for a single font alone on their main page and their HTML semantics are nowhere to be found. This will all impact their bounce rate, accessibility and SEO. I just don't believe the tale of "such skilled engineering teams" which don't show that in their products but blogposts.

do you have doubts those people are skilled? https://en.wikipedia.org/wiki/Brad_Fitzpatrick https://news.ycombinator.com/item?id=21727925

Re: A database for 2022

#283

That was a fun read but I'm missing something here. I've never worked on large scale systems and I don't understand why they didn't choose My or Postgre SQL. Some comments say that it's because they're complicated but what exactly is complicated about them? Can someone with more experience explain to me what would have happened if, for example, they used PostgreSQL from the beginning? P.S Apologies if this is a stupi…

i don't think it's a stupid question and not sure why you getting downvoted. the earlier blog post from tailscale goes into more detail about how the system in question works: https://tailscale.com/blog/an-unlikely-database-migration/

> Tailscale’s coordination server, our “control plane”, has become known as CONTROL. It’s currently a single Go process on a single VM.

if they had used postgres/mysql or some other external RDBMS then that would have meant managing a whole other set of dependencies and doing at least an IPC/Pipe roundtrip for every single query instead of being able to use an embedded database like custom-built JSON db or SQLite which is only going to need in-process syscalls for reading/writing to disk/cache.

so, this allows them to scale their queries vertically orders of magnitude more than an external db (SQLite can do an insane amount of simple read queries per second) as well as making their whole dev/test/release cycle simpler and easier to manage.

that's my understanding anyway - hopefully it makes some sense.

Re: A database for 2022

#284
post #264

Earlier quoted context omitted.

Yep. IMHO MySQL becoming boring (fast, pretty reliable, non-compliant quirks being ironed out, decent backup tool availability, credible admin tools, JSON and CTE support) is one of the most important long term trends on the internet. Along with the parallel evolution of PHP.

I strongly dislike the combination of php and MySQL, from the (recent) experiences I’ve had with it. I don’t see a good reason to pick that as a greenfield stack, but I could be convinced otherwise.

MySQL + PHP (Laravel + Composer + Lighthouse + Spatie MediaLibrary) is very productive.

Re: A database for 2022

#285
post #264

Earlier quoted context omitted.

I strongly dislike the combination of php and MySQL, from the (recent) experiences I’ve had with it. I don’t see a good reason to pick that as a greenfield stack, but I could be convinced otherwise.

For me it's not necessarily the tech themselves, but the lack of any framework to guide development for the next guy. All the PHP+MySQL I've worked with has been horribly bespoke and brittle. Want to significantly change a URL? Need to refactor every path in the .PHP file, because it's importing something from ../.. Or get in the spaghetti business with path aliasing on the webserver. Want to refactor the database sc…

There are several PHP frameworks worth using.

Laravel is, IMO, among the best web frameworks available full stop. Certainly one of the most maturely documented.

It addresses all the points you make.

Re: A database for 2022

#286
post #269

Earlier quoted context omitted.

Why can't a company use cloud? It's not like there's Amazonbox client I could install now and get the same service. Dropbox never was about the storage itself, IMHO - it was about the ease of usage. There were enough options to get storage - cloud or non-cloud - when it came out, but none of them had the easy folder-based sync and sharing (public folder) of Dropbox.

It's not if the company uses cloud or not. It's if they are solving the hard problems or instead, outsourcing the technical challenges to their cloud provider while charging the user a non justifiable premium for the intuitive user interface :-) So it's about the eventual value add and the business case. The challenging part is to provide the back-end. Get massive storage, with proper checksum integrity, at a cost ef…

> Sharing a folder or file from Dropbox is no more intuitive than using the S3 console.

I've not really used the S3 console but, at least on macOS, sharing a file from Dropbox is as simple as "right-click on the file in Finder, Share..." then enter an email address or create a share link from the popup. Or I can right-click and "Copy Dropbox Link" if the direct link is good enough.

Is the S3 console simpler than a right-click?

Re: A database for 2022

#287
post #269

Earlier quoted context omitted.

Why can't a company use cloud? It's not like there's Amazonbox client I could install now and get the same service. Dropbox never was about the storage itself, IMHO - it was about the ease of usage. There were enough options to get storage - cloud or non-cloud - when it came out, but none of them had the easy folder-based sync and sharing (public folder) of Dropbox.

It's not if the company uses cloud or not. It's if they are solving the hard problems or instead, outsourcing the technical challenges to their cloud provider while charging the user a non justifiable premium for the intuitive user interface :-) So it's about the eventual value add and the business case. The challenging part is to provide the back-end. Get massive storage, with proper checksum integrity, at a cost ef…

Their fundament is UX, not technology. Their technology could be whatever and users wouldn't care - the users care about syncing their files easily. Few geeks might flame about it on a tech forum, but nothing more.

Not that I like Dropbox too much. I'm going to switch to my self hosted solution. But it's certainly not as easy as using Dropbox, even as someone who uses AWS since 2012 frequently.

Re: A database for 2022

#288
post #269

Earlier quoted context omitted.

It's not if the company uses cloud or not. It's if they are solving the hard problems or instead, outsourcing the technical challenges to their cloud provider while charging the user a non justifiable premium for the intuitive user interface :-) So it's about the eventual value add and the business case. The challenging part is to provide the back-end. Get massive storage, with proper checksum integrity, at a cost ef…

> Sharing a folder or file from Dropbox is no more intuitive than using the S3 console. I've not really used the S3 console but, at least on macOS, sharing a file from Dropbox is as simple as "right-click on the file in Finder, Share..." then enter an email address or create a share link from the popup. Or I can right-click and "Copy Dropbox Link" if the direct link is good enough. Is the S3 console simpler than a ri…

Even easier and safer, create a signed url that expires after 5 min...Send it to the user...

aws s3 presign s3://awsexamplebucket/test2.txt --expires-in 300

Re: A database for 2022

#289
post #267

At first I was also a little confused by this architecture. I think that was because I was missing a clear picture of what they want to do. I think it is: - one leader that can write to the db - a ton of other hosts that can read from the "streamed" db and want to do so often/fast - hosts send their writes (if they have any?) to the leader via some api call (?) Is that right? If so, the solution makes a ton of sense.…

It's replacing etcd, which has essentially that model.

Re: A database for 2022

#290

Earlier quoted context omitted.

Quoted post unavailable.

You don't know what this database is --- upthread, you said you don't even know what the product is. All you appear to know is that they should be using something like RDS. Isn't that a weird position to take?

it's also kinda weird to write a blog post about a database being used for what is apparently a very specific use case without mentioning what that use case is. the burden of proof is on tailscale to explain why they need to deviate from industry norm here and clearly from the entire comment thread of people wondering the same thing as me they haven't done that. this blog post might actually be valuable if they included more context so that people could learn when something like this might be a good idea, especially since it's not a good idea >99% of the time. as is, no one should be surprised by this response.
Post reply on HN