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

21–30 of 336 posts

Re: A database for 2022

#21

Post by butlerm »

KwisaksHaderach wrote: post #13

The obvious candidates were MySQL (or one of its renamed variants given who bought it) or PostgreSQL, but several of us on the team have operational experience running these databases and didn’t enjoy the prospect of wrestling with the ops overhead of making live replication work and behave well. Other databases like CockroachDB looked very tempting, but we had zero experience with it. And we didn’t want to lock ours…

If you install it locally, that is pretty much the definition of an unmanaged database. Other than by the user of course.

Re: A database for 2022

#22

Post by maximilianroos »

I see a dozen comments here, all critiquing their proposal. Surely this is April Fools?

> I'm sorry, but what the fuck? Just writing the blog posts alone might have consumed more work-hours than what it would have taken to set a database up in the first place.

> 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.

> This is their 3rd DB Migration, something that I prefer to avoid at all costs. I guess they have different priorities and values. But I'm just confused, why would an engineer want to join a company that is making these decisions?

Re: A database for 2022

#24

Post by alexjurkiewicz »

butlerm wrote: post #21
KwisaksHaderach wrote: post #13

The obvious candidates were MySQL (or one of its renamed variants given who bought it) or PostgreSQL, but several of us on the team have operational experience running these databases and didn’t enjoy the prospect of wrestling with the ops overhead of making live replication work and behave well. Other databases like CockroachDB looked very tempting, but we had zero experience with it. And we didn’t want to lock ours…

If you install it locally, that is pretty much the definition of an unmanaged database. Other than by the user of course.

You can use a managed version of the database in production, and an "unmanaged" local Docker image during development.

Re: A database for 2022

#25

Post by Dylan16807 »

musjleman wrote: post #16

So to recap their timeline: * Instead of an actual database use a JSON file. * Write a blog post about how that didn't scale. * Instead of an actual database hand-roll something else. * Write a blog post about how that didn't scale. * Instead of a database with built-in replication which is tailor built for key-value storage use SQLite with a single table containing key-value pairs and some fresh glue to make it repl…

Okay, but this is a database now.

Is there a reason the replication needs to be built-in?

Re: A database for 2022

#26

Post by [deleted] »

musjleman wrote: post #16

So to recap their timeline: * Instead of an actual database use a JSON file. * Write a blog post about how that didn't scale. * Instead of an actual database hand-roll something else. * Write a blog post about how that didn't scale. * Instead of a database with built-in replication which is tailor built for key-value storage use SQLite with a single table containing key-value pairs and some fresh glue to make it repl…

[deleted]

Re: A database for 2022

#27

Post by [deleted] »

Dylan16807 wrote: post #25
musjleman wrote: post #16

So to recap their timeline: * Instead of an actual database use a JSON file. * Write a blog post about how that didn't scale. * Instead of an actual database hand-roll something else. * Write a blog post about how that didn't scale. * Instead of a database with built-in replication which is tailor built for key-value storage use SQLite with a single table containing key-value pairs and some fresh glue to make it repl…

Okay, but this is a database now. Is there a reason the replication needs to be built-in?

[deleted]

Re: A database for 2022

#28

Post by bradfitz »

musjleman wrote: post #16

So to recap their timeline: * Instead of an actual database use a JSON file. * Write a blog post about how that didn't scale. * Instead of an actual database hand-roll something else. * Write a blog post about how that didn't scale. * Instead of a database with built-in replication which is tailor built for key-value storage use SQLite with a single table containing key-value pairs and some fresh glue to make it repl…

Tailscale employee here.

Our database needs are tiny, as explained in the earlier post. So we optimize for things like: "can we run all our tests quickly and easily in many environments without containers and VMs?" All three of our storage schemes have had that property.

We have MySQL and PostgreSQL veterans on the team. We know those options well.

Re: A database for 2022

#29

Post by artificialLimbs »

Dylan16807 wrote: post #25
musjleman wrote: post #16

So to recap their timeline: * Instead of an actual database use a JSON file. * Write a blog post about how that didn't scale. * Instead of an actual database hand-roll something else. * Write a blog post about how that didn't scale. * Instead of a database with built-in replication which is tailor built for key-value storage use SQLite with a single table containing key-value pairs and some fresh glue to make it repl…

Okay, but this is a database now. Is there a reason the replication needs to be built-in?

I thought replication was useful for backups or testing. Maybe other things. edit: I know practically nothing about db.

Re: A database for 2022

#30

Post by srameshc »

musjleman wrote: post #16

So to recap their timeline: * Instead of an actual database use a JSON file. * Write a blog post about how that didn't scale. * Instead of an actual database hand-roll something else. * Write a blog post about how that didn't scale. * Instead of a database with built-in replication which is tailor built for key-value storage use SQLite with a single table containing key-value pairs and some fresh glue to make it repl…

Why not ? You can be a spectator to it watch them succeed or fail.
Post reply on HN