No post body was provided.
A database for 2022
11–20 of 336 posts
Re: A database for 2022
#12I'm so desperate for a SQL database where I can just put it on a bunch of commodity hardware via Docker, connect them up and never worry about this again. Ideally it'd monitor my queries and create indexes for me. pleeeeeeaaaaaaaaaaaassssseeeeeeeeee /dream FoundationDB is similar but you have to do so much yourself. It's more or less what I'm describing for a key value store though. Not sure why it's not more popular…
I am having quite a good time with CockroachDB. It has been mostly set-and-forget, and it auto-balances, and does rolling upgrades pretty smoothly.
Re: A database for 2022
#13The 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 ourselves into a cloud provider with a managed product like Spanner.
What about managed mysql/posgresql? no lock-in and installing them locally is trivial.
Re: A database for 2022
#14They're using litestream [1] to replicate a SQLite database, which streams additions to the SQLite WAL file to object storage and can replay it back. This is fairly hands-off from SQLite's perspective. There's also the SQLite Session Extension [2] that is a built-in way to support generating and applying "patches". I'm curious how these tools will mature, it seems like a good match for microservices. [1]: https://git…
I watched an interview of Mr. Hipp, creator of SQLite, that I can't find now but was pretty interesting. Aside from being way different than I expected for some reason, in a good way - very down to earth and friendly, he was asked specifically about that, and more or less answered that his job was to write a solid DB, and replication can be done elsewhere. That's a pretty honest answer, and looks like someone took up the challenge.
Re: A database for 2022
#15I'm so desperate for a SQL database where I can just put it on a bunch of commodity hardware via Docker, connect them up and never worry about this again. Ideally it'd monitor my queries and create indexes for me. pleeeeeeaaaaaaaaaaaassssseeeeeeeeee /dream FoundationDB is similar but you have to do so much yourself. It's more or less what I'm describing for a key value store though. Not sure why it's not more popular…
FoundationDB is an Apple thing, isn’t it? Might explain why. It feels kinda like they’ve put it out there and it just hasn’t had anyone with a marketing budget to push it along.
Re: A database for 2022
#16So 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 replicate.
Are we supposed to expect another blog post somewhere around a year down the road titled "SQLite didn't scale" or "The new library for replication that was released a few months ago contained a bug that took our prod down"?
Re: A database for 2022
#17... this is just replication of a database? As in the full database per node/replica? Hasn't AWS's SQL db-as-a-services had this for years now?
Pretty sure you could track down instances of this technology going back decades now. Nothing is new under the sun. Doesn't mean you can use it.
Re: A database for 2022
#18I 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 have different priorities and values. 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? They started using etcd knowing that he would become a bottle neck, that should have been a non-starter, right?
Re: A database for 2022
#19... this is just replication of a database? As in the full database per node/replica? Hasn't AWS's SQL db-as-a-services had this for years now?
I don't think they are claiming to have invented database replication, so what?
Re: A database for 2022
#20This is an April fool's joke, right?
Edit: no it's not..
> Footnote: coworkers point out it’s April Fool’s today and request that I clarify this isn’t a joke. Joke’s on them: every day’s April Fool’s in the Tailscale Database Engineering department.