I'm getting half-remembered flashbacks to some of the distributed, self-replicating Lotus Notes applications I worked on very early in my career
A database for 2022
211–220 of 336 posts
Re: A database for 2022
#212Earlier 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…
>> it seems like they are successful in spite of these decisions, not because of these decisions
That is my conclusion, too.
Re: A database for 2022
#213This 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…
Please could someone explain the "Bob Martin Sudoku Solver energy" reference?
Re: A database for 2022
#214Earlier 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…
The etcd solution was highly questionable. Actually, a prime example for reinventing the wheel, but worse.
Re: A database for 2022
#215Not commenting on tailscale, but for the state of databases. Sometimes boring is the right choice. PostgreSQL has worked for decades now, and seems to have regained much of the performance that MySQL once boasted. If you do this for the money, investing in tried and true (but boring) software should be the default solution. I watched with dread how the MongoDB fiasco played out a decade ago. Meanwhile, I kept using P…
It depends. I was in a demo call from Blaze, a CDP (Customer Data Platform), Segment.io competitor. Their underlying db seems to be MongoDB and for a CDP makes a lot of sense. In a CDP you collect all kind of data on n hard ids that identify 1 person interacting with your web assets, schemaless and json first is a lot easier to reason in this context than SQL. This is because you keep enriching your profile with additional attributes over time. Can PostgreSQL do this? Absolutely, but it’s not its main feature.
Things are complex, especially in data, I think it’s important to evaluate use cases rather than going with generic assumptions like “use boring tech”.
Re: A database for 2022
#216Not commenting on tailscale, but for the state of databases. Sometimes boring is the right choice. PostgreSQL has worked for decades now, and seems to have regained much of the performance that MySQL once boasted. If you do this for the money, investing in tried and true (but boring) software should be the default solution. I watched with dread how the MongoDB fiasco played out a decade ago. Meanwhile, I kept using P…
You say 'sometimes', I think it should be the default position.
When you want to deviate from the boring software and technology, there must be a very sound 'business case' for it.
If you are building a planetary scale business, OK, maybe that warrants something more fancy.
But how many companies really need that? I'm not limiting myself to the HN unicorns, but looking at the whole market.
Re: A database for 2022
#217I for one am enjoying this. Sure they could probably just use a regular ol' database, but where is the excitement in that!
SQLite is the most deployed database in the world
Not for this kind of applications. Same as Java being on 13 billion of devices, it doesn't mean anything if it's some config store underneath some mobile or desktop app.
Re: A database for 2022
#218Not commenting on tailscale, but for the state of databases. Sometimes boring is the right choice. PostgreSQL has worked for decades now, and seems to have regained much of the performance that MySQL once boasted. If you do this for the money, investing in tried and true (but boring) software should be the default solution. I watched with dread how the MongoDB fiasco played out a decade ago. Meanwhile, I kept using P…
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.
Re: A database for 2022
#219Maybe I missed something. How do you account for the VM downtime? The VM containing the service writing to the sqlite db, it can go down without warning. How do you mitigate that?
It doesn’t. Given that it periodically dumps the WAL to an S3 bucket for actual storage this sounds like async replication. Async replication is prone to lose last bits (last by time) of data when the node goes down. They’re probably more or less fine if the SQLite file is stored on the EBS though, it means they’ll just have to restart that node that failed or reattach EBS volume to a new healthy node. It does mean downtime though.
On another note I’m using Tailscale and it’s a wonderful service and I get it for free.
Re: A database for 2022
#220Not commenting on tailscale, but for the state of databases. Sometimes boring is the right choice. PostgreSQL has worked for decades now, and seems to have regained much of the performance that MySQL once boasted. If you do this for the money, investing in tried and true (but boring) software should be the default solution. I watched with dread how the MongoDB fiasco played out a decade ago. Meanwhile, I kept using P…
> I watched with dread how the MongoDB fiasco played out a decade ago.
Could you elaborate on this? MongoDB as a company is worth $30B, so it looks like they did at least some things right.