Hi! I'm the CTO of PlanetScale - the PostgreSQL offering we launched today is built on top of pure Postgres and doesn't come with any limitations.
The future sharded version will also be based on Postgres directly, and will be as compatible as possible. We're not looking to just speak the PG wire protocol to a different backend store.
Our experience has been that they do fire, but not reliably enough or soon enough to be worth anything other than validating the problem after the fact.
Author here - it's not that we're detecting failure better than they are (though certainly, we might be able to do it as fast as anyone else) - it's what you do afterwards that matters.
Being able to fail over to another database instance backed by a different volume in a different zone allows for a minimization of impact. This is well inline with AWS best practices, it's just arduous to do quickly and at-scale.
Answering on behalf of PlanetScale (I'm the CTO!). I don't remember exactly what was different from upstream, but it wasn't a whole lot of changes.
Fortunately, PlanetScale runs a well-maintained fork ourselves, so we're very used to taking custom changes and getting them deployed. In this case, we asked the Block team for all of their changes and went through them one by one to see what was needed to pull into our fork.
By the time we did the migration, we made sure that any behavior wouldn't be different where it mattered.
Mostly the diffs were related to running against the on-prem MySQL instances smoothly: stuff like changes to split tooling or how you boot up the pieces. We have had unique vindexes or query planning changes in the past but we either deprecated or upstreamed them prior to migration.
This is the un-fun work needed to get open source software into many different parts of the enterprise and government. It's not fun, and sometimes it's not even very difficult, but its usually very tie consuming and full of arcane knowledge.
Signed, someone who was dropped a big application and asked to make it FIPS compliant ASAP.
Open, closed, it's all a bunch of fun getting working in FIPS mode. Especially 3rd party applications. They'll call a library, that calls a library that uses something not compliant.
While FIPS is a pain in the ass, can show you potential failures your software has with using ancient crypto methods that are easy to enable and completely compromise the security of your software.
but i think there's some requirements in FIPS that are really just checkbox rather than actual security. I suppose it's easier to have a list of checkboxes to tick from a compliance perspective.
I'm pretty happy about this, I don't think Apple should be forced to open up iMessage, but not adopting the RCS standard always seemed a bit underhanded to me. Even if it sucks, better cross-platform messaging is a win for everyone.
What monopoly? Android has a larger market share than Apple by quite a large factor in the European Union.
Saying that Apple does not provide value is laughable - saying that it isn't worth 30% of the transaction value might be one thing, but they provide the R&D to create the device, the platform, the review infrastructure, update infrastructure, development environment, etc.
I'm not even sure I disagree with you, but you have to at least describe what you are against correctly.
> Saying that Apple does not provide value is laughable - saying that it isn't worth 30% of the transaction value might be one thing, but they provide the R&D to create the device, the platform, the review infrastructure, update infrastructure, development environment, etc.
By that same measure I should be allowed to ask how this R&D benefits the majority of app developers on the app store. Honestly, when it comes to the value Apple provides to their developers, a much stronger argument would be their marketing that leads to extraordinary customer loyalty, in addition to the higher value market in terms of what customers they attract.
But R&D? Honestly you're joking right? The majority of the platforms "cool" features are locked down and not available to developers. Can I make use of the iPhones SOS feature for my emergency service? Nope, this is an Apple exclusive service, only offered by and through them themselves.
What about NFC/digital payments? Yeah no. Can't access that as an developer without a heavily restricted API.
What about their industry leading Bluetooth stack? Nope, also locked down. I can only pair certain devices, hell I can't even enable platform interoperability between Android and iOS, even though we _know this works_ due to the covid contact tracing feature.
Good luck with trying to offer a competing product to the Apple Watch on their platform. You can't.
Development infrastructure? You mean the infrastructure that I can also only procure through them? The infrastructure that consists of a Mac that I need to actually publish iOS apps, even though nothing would be stopping me from developing these apps on another platform, say Linux?
What about CI/CD and testing and security research? Remember, up until 1-2 years ago, Apple actively went to court against offers such as those of corellium, like when you wanted a virtual device to test your app with.
Google had all this and more on a free app store with a much more fractured ecosystem.
I could go on and on about this, but the majority of app store developers doesn't make use of a large part of their "R&D". A large part of what you call "R&D" I call the typical Apple BS of claiming well established technologies and practices as their own invention and then somehow finding a way to charge you for it.
I'd accept this argument in smaller markets what with the VR goggles and whatnot, and I agree that from a design standpoint, all of these API's / lockdowns are well intentioned and make sense.
But at the same time, the antitrust violation standpoint holds for me as well. Even if I tried, I could not offer a competing product to say, the Apple Watch, because Apple will not allow me to create a device with the same interoperability like their own devices.
This is useful - using an exit node with an Apple TV is useful as well for navigating around certain tools that are geo-blocked. Before, you'd have to handle it outside of the device which is much more difficult.
I'm going to play around with this later in the week.
Here in the PNW there is basically one corridor that would make sense as a semi-high speed (160+ kph) rail, which is Portland-Seattle-Vancouver. They are all under 200 miles from each other and connected by one road that is often very congested.
The current Amtrak route is not frequent, fast or cheap enough to be a good alternative to driving for most people.
Hourly service between them would be a boon to the whole area, and allow for a ton of flights to not happen between the cities for connecting traffic.
I'm in Seattle, my new-ish townhouse has a heat pump and it's never been too cold for it to be functional - it's worked hard some of the really cold+snowy days the last few years, but never to the point where it wasn't heating the house up perfectly fine.
I am not sure I would pay $27k for the whole install, but once it's there I've found it to be great. Extremely inexpensive to run and with all of Seattle's power being carbon-neutral, totally guilt free to set it to 68F at night during a hot summer day.
The future sharded version will also be based on Postgres directly, and will be as compatible as possible. We're not looking to just speak the PG wire protocol to a different backend store.