71–80 of 135 posts
I already played around with Upstash and Fauna.
Somehow the signup shows an 422 error, then I get an confirmation email that leads to a blank page.
Earlier quoted context omitted.
Sure you can! and we will make it worth it.
I can't decide whether this joke is marketing folly or strategic genius. On the one hand, making light of how big an undertaking a _database engine migration_ would be makes you come off sounding like the "mongodb is web scale" guy. That's a pretty terrible look for a company proposing to take on critical production infrastructure. On the other hand, adding postgresql support to vitess is probably a _massive_ underta…
We concern ourselves with the productivity of our users. We also solve hard problems at scale, for many large companies. We have so many exciting developer focussed features that I think people will love, all the while being on a viable database. Vitess is by far the highest scale open source database solution out there.
Migration cost is a serious thing. We believe the immense leap in productivity you will gain over time from our product makes it more than worth it.
Amy I the only person reading this who doesn’t think that the marketing line in the middle about not managing a schema is super scary? > Developers want the durability, stability, and scalability of a SQL database but do not want to be constrained by managing a schema. It has been our goal to give both, not compromising on the power of your datastore but making changes feel as easy as deploying code. Sorry. There’s a…
The boulder-sized caveat for all this admittedly really neat stuff being: > PlanetScale's Non-Blocking Schema Changes' workflow doesn't support FOREIGN KEYs in users' databases. > PlanetScale determined that the production safety that Non-Blocking Schema Changes provide are worth this technical tradeoff. Learn more. https://docs.planetscale.com/concepts/nonblocking-schema-cha...
PlanetScale's (and Vitess') non-blocking schema changes rely on open source tools for MySQL like pt-online-schema-change and gh-ost, which are widely used in production environments everywhere, and neither of them are too comfortable supporting FK's, though pt-osc does accommodate them to some extent (https://www.percona.com/doc/percona-toolkit/3.0/pt-online-sc...). gh-ost's lack of support was discussed on HN previously here: https://news.ycombinator.com/item?id=16983620
A good collection of resources on why they're considered problematic and many companies designing large-scale MySQL schemas tend to drop them can also be found here: https://federico-razzoli.com/foreign-key-bugs-in-mysql-and-m...
Earlier quoted context omitted.
If it is MySQL compatible it's not vendor lock in. It's more like a clever trap, first hit is free etc. Will be interesting to follow this. I'm not db savvy so I don't mind leaving that job to someone else.
Vender lock-in isn't just about data formats, it's about the overall makeup of your infrastructure and development processes. If an org builds around the particular way PlanetScale manages DB branches and other minutiae of their service, they can't simply replace that with an in-house DB server overnight.
"Vendor lock-in" means that you're tied at a business-critical level to some proprietary technology _that you can't get anywhere else_.
If you rent Linux servers, Postgres databases, or even k8s setups from Azure, there's no shortage of alternative vendors willing to sell you compatible product should you tire of MS, and ideally you won't need to change much more than a few endpoints. However, if your entire user base lives in Azure AD, it's a very different story.
With sharding, where this stuff eventually gets you is when your assumptions about shard keys no longer hold.
Eg, you might have user initiated traffic to start with, so you can easily and automatically shard everything by user id or whatever. Then one day, those assumptions change because you might have to accommodate event driven traffic, ie not request/response, and the user’s id can’t be assumed to always be present. For example let’s say something in the real world causes an event to be pushed onto your queue. That event could correspond to a real user, but since it originated somewhere in the real world, there’s probably a separate id for how that user is represented. So you can’t rely on that user ID being present to shard things by.
Not sure, if that makes sense, but sharding can be hard. It’s not like free, and I still think it’s important for engineers to understand the mental model they’re using, even with a tool like vitess.
Also, I saw claim either on planetscale or vitess that MySQL has no native support for horizontal scaling with automatic sharding, but I think they do? I think you just have to pay for that though.
Also, cross-shard transactions were mentioned as another difficulty with sharding. They can be done with either sagas (depends on the context but it’s a design pattern), or 2PC which is available in MySQL > 5.8 I believe in the form of XA Transactions.
Earlier quoted context omitted.
he is probably referring to the docdb document store in yugabyte: https://docs.yugabyte.com/latest/architecture/layered-archit...
Indeed I was referring to yugabyte, apologies for the clumsy phrasing, I havent used crdb but I guess it is a postgres frontend layered on a KV store instead of a document store?
From the Vercel point of view, this promises to answer one of the most frequent, interesting, and technically challenging questions since we first launched our "immutable deploys". That is: how can I pair a brand new frontend preview deploy, with a serverless database with the specific schema my new feature needs? This technology makes the whole serverless stack feel complete.
More to the point, it probably cannot solve it efficiently at all, since it is not a graph database and thus cannot be paired with a generic GraphQL resolver (would generate join queries instead of lookups across edges) and a stack of generated static queries in the backend (no need to allow generic queries, just make it possible to write queries once and only once).