47 ms·

PlanetScale – Database for Developers

279 points by samlambert 5y ago

sorenbs 5y ago
I have been using the beta version of PlanetScale for a while, and it is extremely cool. It's using the mature technology that powers Youtube to provide a developer experience for databases similar to what Vercel and Netlify provide for hosting: It will give you a database branch for each Git branch and help you manage the workflows around it. And it is the first truly serverless relational database offering that I am aware of. The cost scale to 0, so it is perfect for small projects, but that same instance will scale to support massive load when you need it.
cfors 5y ago
> 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. So is this a wrapper around managing Schemas powered by Vitesse? (Btw, had to go to your github to figure that out) If you want to be the database for developers you should know that developers do care about how you do this scaling.
Allstar 5y ago
It's not entirely clear from the website or the documentation, but this seems to be build exclusively for MySQL?
- samlambert 5y ago
  Yes we are MySQL compatible.
  - rad_gruchalski 5y ago
    100% compatible? Is there a document with a compatibility matrix? Edit: I guess this is it: https://vitess.io/docs/reference/compatibility/mysql-compatibility/ https://vitess.io/docs/reference/compatibility/mysql-compati....
Rauchg 5y ago
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.
- adamfeldman 5y ago
  Branching wasn't mentioned in the linked blog post, but I assume that is what the parent comment is excited about: https://docs.planetscale.com/concepts/branching https://docs.planetscale.com/concepts/branching
  - Rauchg 5y ago
    Indeed, thank you!
- eurasiantiger 5y ago
  It doesn’t solve the N+1 queries problem in a generic way. That is a major hurdle in scaling complexity-wise, which in turn is often deeply coupled with business realities. 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).
  - ransom1538 5y ago
    "It doesn’t solve the N+1 queries problem in a generic way." IMHO, this isn't trying to solve people looping queries. The fastest way to solve this is to not loop queries. This solves auto-sharding (well vitness did). See slack architects comment below.
    - eurasiantiger 5y ago
christiansakai 5y ago
will this support blob as well like S3?
CSDude 5y ago
It looks great, congrats
- harshit164 5y ago
  Appreciate that. thank you
nebulous1 5y ago
I have to admit that with the previous mocking of "web scale", I initially assumed this was satire.
briandoll 5y ago
Before GitHub launched, I built some large eCommerce sites, and for a vcs we used CVS, and then Subversion. We had a person on our team with the title of release manager, because branching in Subversion, and merging back to make releases, was a specialist effort that took time, patience, and managing a tremendous amount of fighting between teams of what features and fixes could even be merged together in order to ship this release. When I started using git, it broke my brain. I wasn't really sure I understood it, but the idea of cheap local branches soon became the most important thing to me in a vcs, and everything became easier and so much faster. You could just work on code the way real life happens, not in some methodical pre-planned release schedule that always rubbed harshly against the reality of bug fixes and ever changing minds. Planetscale is a lot like that transformation. We've been thinking of databases as this specialist thing, where the arcane knowledge required to make it perform well is a specialist role, and something completely untouchable by mortal engineers. While we've learned about the importance of good data modeling, we've dealt with a layer in our stack that is essentially static. Shipping features that require changes to a database schema sit and languish, because the pain and coordination required can often be too much for a team to want to deal with. What PlanetScale has done is solve two massive problems in one platform. First, since it's built on Vitess, it Just Works At Scale. You don't need to fiddle with knobs to get it to perform well. You most definitely are not even in the top 10% of what is already running on Vitess, so you don't really need to worry about ever outgrowing PlanetScale. But the BIG innovation here is what is possible now that a database works the way the SDLC has evolved with git. Make a branch, change the schema, roll it out with your code. Just like anything else, really. Use the PlanetScale CLI to actually USE your database. Change the schema because it will make your code better, and don't worry that you're somehow going to do it wrong. PlanetScale just made databases useful for developers beyond a nearly-static data store. It's a high-scale database that you can change like code. It will break your brain a little at first, just like git did. And then you'll wonder why the hell we waited so long to have a database this good.
- chris_st 5y ago
  Sounds great! One question about pricing -- I can't tell if the "free" tier costs are for one month, or ongoing. That is, do you get the free tier amounts for one month and then pay from then on, or is that level of service free from then on?
deleted 5y ago
[deleted]
jaredcwhite 5y ago
Can I install this locally? Will it work without an internet connection? Is it fully open source? From what I can tell, the answer to all three questions is no. Is it yet another example of vendor lock-in? Yes.
- deleted 5y ago
  [deleted]
- unknown_error 5y ago
  There is still value in proprietary solutions that offer significant time/money savings vs open source. Not all of us have infinite resources to develop and maintain every solution in-house, whether that's an auto-scaling database or email or Google Docs or whatever. For small/medium businesses, sometimes it's better just to let the experts do their thing and build on top of it...
- sigg3 5y ago
  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.
  - jaredcwhite 5y ago
    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.
    - piaste 5y ago
      True enough, but by that standard, every service would constitute lock-in. A cleaning company isn't lock-in just because you don't have in-house janitors. "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.
paxys 5y ago
If I understand correctly, PlanetScale = hosted Vitess? I assume it was started by the creators/maintainers of the project (similar to Confluent and such)?
- samlambert 5y ago
  Yes!
stalluri 5y ago
Branching looks super dope! https://docs.planetscale.com/concepts/branching https://docs.planetscale.com/concepts/branching
wiradikusuma 5y ago
Can serverless solutions e.g. AWS Lamba or Google Cloud Run connect to this?
- samlambert 5y ago
  Yes absolutely!
  - jopsen 5y ago
    Where is it hosted? Do you have instances in all data centers moving shards to where they are used? Using databases outside the same availability zone can be slower...
aantix 5y ago
I wonder what the latency would be to have a heroku insurance pointed at a PlanetScale instance. Doesn’t look like there’s Postgres compatibility.
vira28 5y ago
Wondering will we see something like this for Postgres? I like the cool things but I can’t migrate to MySQL just because of this.
- samlambert 5y ago
  Sure you can! and we will make it worth it.
  - NAR8789 5y ago
    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_ undertaking. Sure, it might make sense for you to contribute to in the long run to open up that customer segment, but at your current stage postgresql customers are probably more of a product-distraction than anything. In that light, driving us away for now is probably the best policy. I'm gonna give you the benefit of the doubt. Well played, sir. Well played. EDIT: nevermind, all your other comments so far in this thread are variations on "Yes, we can do that!". You're promising the moon, and that's fishy. Bit of unsolicited advice (you know what they say about unsolicited advice, but here goes...): You'd be better off admitting some weaknesses and discussing tradeoffs. For examples, take a look at other HN threads where execs have hopped on. What qualities do you seen in posts that get the most positive responses? Now compare that to the confusion and skepticism in this thread. Your messaging has landed off-target. You're proposing to take over a piece of people's critical production infrastructure. As a potential buyer considering an infrastructure provider, seeing "buy our product and we'll solve all your problems" just makes me skeptical. It makes you sound like a used car salesman. Your landing page delivers that basic message, and your comments in this thread reinforce the resulting impression. Conversely, if in these comments you soberly acknowledged your limitations, transitioned to a detailed treatment about tradeoffs, and _then_ used that save to toot your horn some more, that would give the impression you've considered this problem deeply, help me figure out how closely your value prop is aligned to my goals, and make me more inclined to trust you, your company, and your product. As it is... I see your comment and it makes me think your company isn't ready to take on my infrastructure (this is my database we're talking about here... if you're not taking something as basic as migration costs seriously, what other nasty surprises are waiting for me down the line?). Then, I take a look at your about page (maybe this guy's just an entry-level marketer in the people-pleaser phase), and I see that you, Sam Lambert, are the Chief Product Officer. That gives me some serious doubts about the future viability of your company, because now I'm worried the CPO is fundamentally out of touch with the userbase and can't grapple with difficult details. You will not be touching my data any time soon, but I'll be watching for changes, and I honestly wish you luck. I like your vision, but your messaging execution needs work and your product execution is yet-unproven. EDIT: kudos to lizztheblizz for giving more detailed answers that inspire confidence. You've significantly repaired my impressions of your company.
capableweb 5y ago
Sounds interesting but there is not enough information for me to get a picture of what this actually means. Thought I was gonna be clever and install it, run it and see what it is all about but I can't figure out how to get it. One link is "sign up" and the other is "contact sales" but I'm not interested in either, I'm interested in "Download" but I cannot find it anywhere. Am I stupid or misunderstanding something fundamentally here? Is just a hosted DB or something like that?
- moshmosh 5y ago
  It's a hosted DB, and as far as I can tell the Killer Feature is that it makes schema updates less painful. How it does that without significant performance trade-offs or caps is unclear to me. [EDIT] on reading further in their docs, my suspicion is that their "branching" concept is a hell of a lot more limited than I believed at first. I initially took it to mean you could have multiple active schemas working on your data at once—instead, I think it's more like exporting just the schema of your DB and importing it to a fresh DB, which is nothing new and doesn't run into all kinds of operational and security issues the other workflow would. I'm fairly sure all the actual magic is in the schema diffing, and the docs make me think even that isn't as fully-magical as one might hope.
  - lizztheblizz 5y ago
    It's closer to your original assumption than your second. Branching relies on vreplication, and it does actually allow you to develop multiple versions of your schema against your full production dataset. The "magic" is a powerful materialization engine that allows every branch to maintain its own version, and it _does_ allow you to work with your actual data. This is just scratching the surface of what that can do, though. We have loads more features cooking. :)
2color 5y ago
This is wonderful. I've been developing with relational databases for 12 years and couldn't be more excited about this. Scaling down to 0 opens up a world of opportunities when it comes to team development workflows. The idea of quick environments per pull request is within reach. Not to mention that it scales with you. The one thing I'm curious about is how it compares with CockroachDB
- machiaweliczny 5y ago
  Quick environment per pull request is available with SQLite now :)
- lizztheblizz 5y ago
  12+ years of massive scale production use for Vitess and 26+ years of hardening for MySQL and InnoDB. PlanetScale adds some (imho) great features on top of that, but it's standing on the shoulders of giants that have proven themselves over and over. ... Also, I guess it's MySQL-compatible rather than Postgres-compatible? :)
unknown_error 5y ago
Can someone please explain how Vitess works, in plain English? How does it magically make MySQL scale? And then what does PlanetScale add on top of Vitess hosted anywhere else? Sorry, the linked blog post is both very abstract and assumes a high level of preexisting knowledge about database scaling.
- moshmosh 5y ago
  IME the answer to "how did they make [hard to scale thing] easily scalable?" is usually that they introduce limitations in how you can use [hard to scale thing] so you can't use it in ways that are hard to scale, then automate scaling it in well-known ways for use cases that are so-limited. Vitesse's site mentions that it relies on horizontal sharding, so right off the bat, my guess is that you can't use it in ways that are sharding-unfriendly, or if you can then you'll be met with restrictions on much of the "magic" of it if you do. Rarely is it the case that someone's actually discovered e.g. novel math or something to make the hard part easier. Better tools (to do well-understood things more easily for this use case) and restrictions (so you don't use it in ways the tools can't handle) are the usual way.
  - lizztheblizz 5y ago
    The "ease" we used to refer to in Vitess primarily relates to its interaction with the application side, where it basically presents itself as "one big MySQL datastore". It uses a standard MySQL connector, and in general, once you have the infrastructure up and running with a compatible schema design, there's not too much to worry about from a coding standpoint. Sharding happens transparently to the application code, which generally translates to fewer code changes required. Admittedly, that view left out the considerable challenge of actually deploying and running the infrastructure, designing and optimizing that schema, along with all the joys of managing large cluster environments. That's what PlanetScale, the product, aims to solve. Dealing with clustering infrastructure IS a hurdle for most teams to overcome, and though Vitess' feature set and compatibility has expanded greatly to accommodate some of the most demanding use cases on the web today, a lot of its functionality can still be out of reach for a developer just trying to merge some code and a schema change. Abstracting as much of that complexity away from the end user is the goal, as well as making their lives easier with a ton of the functionality we've always wanted to see built with Vitess. I can confirm that that is not an "easy" job on our end. :)
qaq 5y ago
With solutions like CockroachDB, YugabyteDB etc. gaining steam do things like Vitess have a place long term?
satyrnein 5y ago
It sounds like the database branch has copy of the production schema, but what about the data itself? We've been using AWS Aurora clones to quickly give developers copies of production, can zero-copy clones be made as part of the branch?
pratio 5y ago
The pricing gives me anxiety. $1.25/mo per 10GB storage $15/mo per 100 Million rows read $15/mo per 10 Million rows written But I won't lie, super excited to give this a try.
gryzzly 5y ago
is it not funny that something with a word "scale" in it disabled creation of databases because of being under load?
itwy 5y ago
> The site is experiencing higher than normal traffic and we have temporarily halted database creation. Ironic coming from the infinitely scalable database, isn't it?
- paxys 5y ago
  Well that restriction will probably disappear if you just give them your credit card number
- chachra 5y ago
  ironic indeed...took me a few seconds to read the white text on a yellow banner at the top why I couldn't create a db!
halostatue 5y ago
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 always a schema, and learning to manage it is a _good_ thing. If you’re not ready to manage and migrate, then you’re not in production. You’re in something else.
- deleted 5y ago
  [deleted]
- Aeolun 5y ago
  Schrodingers production environment.
- shlomi-noach 5y ago
  There is always a schema, and PlanetScale, in particular, promotes the use of schemas. That is, behind the scenes we operate Vitess, which is an infrastructure and sharding framework on top of MySQL. You will create schemas in PlanetScale just as you would in MySQL. Managing the schema, though: operating schema changes in code and in production, mitigating schema conflicts, scheduling migrations, running online migrations, experimenting with schema changes, etc., are something relational databases don't provide the right (or any) tooling for developers, and this is one of the things PlanetScale aims to bring to developers. In my past experience as a production engineer, and in our many discussions within the community, we've seen many approaches developers take just to avoid the hassle of running yet another ALTER TABLE; whether because it requires going through a different team, or because this poses an availability risk, etc. PlanetScale offers to bring ownership back in the developer's hands. Hope this clarifies. We'll publish more soon, and I'll be able to provide more links. (I'm an engineer at PlanetScale) (Edit for grammar/typos)
  - halostatue 5y ago
    I’m not sure what to say to that. In the former (database changes belong to a different team), there’s not much that can be helped. Given the number of people—on HN, no less—who have war stories about having accidentally dropped the production database because of insufficient protections and the desire of many businesses to know that their vendors are following SOC2 and similar safety and security protocols, I completely get that. In the latter case (availability risk), there’s no sympathy I can provide. Developers need to be aware of what their changes mean. Sometimes this means that you make a separate table. Sometimes it means you have a downtime event which means an overnight deploy. Sometimes it means you have to figure out how to do a zero-downtime series of migrations. Step 0: make sure you need the migration. Step 1: modify the app to conditionally query or update the new column based on whether the change is present or not, and without requiring a value in the column. (Since it’s not, this will work as an `if false` case for now.) Deploy. Step 2: modify the database to add the column with no constraints (safe and trivial on most SQL databases). Deploy. Step 3: modify the app to start filling in fields that should not be null. (That is, provide constraint validation at the application level; or, if dropping a column, start setting the value to a least damaging value or NULL if you could have made a required field no longer required.) Deploy. Step 4: After some time, run a backfill to fill in new required values (or clear old values) that haven’t been modified yet. If you’ve done this right, it should be a small number. Optionally, do this periodically for small subsets of data. Step 5: Run a final backfill and deploy a schema migration that adds your constraint/drops your column (dropping a column is optional if you’ve got a hard zero downtime requirement; just make sure no one tries to use it and make sure it’s not part of the application schema; schema comments are your friend). Step 6: Deploy a version of the app that doesn’t act conditionally. Yes, it takes longer. I’ve run migrations this way for the last seven years and we’ve had essentially _no_ downtime because of migrations. I think we’ve had ~4 hours of preventative downtime across ~10 databases in that time. Usually, when we’re ready for the piece that can cause downtime…there’s about a five minute hiccup. Developers who can’t reason through safe table alterations shouldn’t be making those changes, and PlanetScale is going to make some business people very unhappy when their developer changes something that they didn’t actually understand and causes downtime regardless of PS’s “guarantees”.
golondon 5y ago
Aren't schema changes are actually a big problem when there is a huge amount of data in the table. Adding a column / index to a table that has 500M rows in it is usually the pita. This is definitely something on the right direction, but would love to see this supporting this with the data itself.
- lizztheblizz 5y ago
  That is exactly what we _do_ support. Our team includes the original developer of gh-ost for MySQL, which has been built to execute these kinds of massive changes at scale at GitHub. We've integrated it tightly with Vitess. Once your branch is ready to be merged with production, it executes that change in a completely non-blocking way.
  - golondon 5y ago
    Ok, but most of the time you would like to test that change on a copy or almost up to date replica, to see measure things like how long it does take. If you were copying the data, with things like PII filtering, to the branch development database and allow folks to test it there it would be even more amazing. Great start tho!
    - lizztheblizz 5y ago
      Give it a shot, because the current implementation specifically side steps the need for that full copy, and does let you test functionally against fully up-to-date production data. You're right, though, it doesn't cover all of those uses cases. Luckily, Vitess does offer most of that out of the box already. Just need them exposed through the PlanetScale UI. :)
ngrilly 5y ago
Really great finally seeing a “serverless” SQL database based on MySQL and Vitess that scales from 0 to n, even with a free tier! Where are you hosted? What latency should we expect from AWS, GCP, DigitalOcean and fly.io? And also what degree of compatibility should we expect with MySQL? The doc is quite sparse on this.
- lizztheblizz 5y ago
  Vitess' compatibility with MySQL has made major leaps in the past couple of versions and the team has started focusing on locking in ongoing compatibility with various popular development frameworks. You can find those here, and more are getting added regularly: https://github.com/planetscale/vitess-framework-testing/ https://github.com/planetscale/vitess-framework-testing/ The basics of MySQL compatibility are described in here, though it's important to keep in mind that just because something "works" doesn't always mean it's the best way to do things in a sharded environment: https://vitess.io/docs/reference/compatibility/mysql-compatibility/ https://vitess.io/docs/reference/compatibility/mysql-compati...
  - ngrilly 5y ago
    Thanks! Not having window functions and CTEs is a significant limitation for any kind of data analysis. But I guess the main use case is pure OLTP where it is – a bit – less relevant.
adambair 5y ago
The amount of buzzwords on the site made me think this was some kind of elaborate joke. I'm not yet convinced it isn't...
olivierlacan 5y ago
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-changes https://docs.planetscale.com/concepts/nonblocking-schema-cha...
- lizztheblizz 5y ago
  To be clear, this is not a Vitess/PlanetScale-specific opinion or choice. Foreign key constraints are a bit of a controversial topic in large-scale MySQL environments in general, which is the greater context in which this design decision was made by the Vitess team. 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-schema-change.html 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 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-mariadb https://federico-razzoli.com/foreign-key-bugs-in-mysql-and-m...
  - Jarwain 5y ago
    Do you know if foreign keys tend to be a problem on postgresql as well?
    - lizztheblizz 5y ago
      I don't have nearly the experience in Postgres environments to have seen the same level of real-world impact there, but a quick search presents me with the following documentation, which seems to indicate mostly similar performance challenges related to the use of Foreign Key Constraints: https://www.postgresql.org/docs/13/populate.html#POPULATE-RM-FKEYS https://www.postgresql.org/docs/13/populate.html#POPULATE-RM...
k__ 5y ago
I'm currently searching for a serverless database for my next project and will look into it. 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.
- tasuki 5y ago
  What is a serverless database and why are you searching for one for your next project?
  - k__ 5y ago
    A managed database thats automatically scales horizontally and is priced on-demand. I want it for my next project, because I don't want to pay for what I don't use, but also don't want to provision or maintain additional instances manually.
    - tasuki 5y ago
      Explanation at the exact level of detail I wanted - thank you :)
asimpletune 5y ago
So just wanted to add a few random thoughts about some of this stuff. 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.
isatty 5y ago
What is this? Reading this post does not explain it, but I figure it some sort of new DB.
dastbe 5y ago
What do yall see as the next devx improvements beyond branching and no-fear schema migrations? I'd be really interested in how you might apply the workflows you're defining towards (IMO) bigger problems like data migration and backfills.
- lizztheblizz 5y ago
  Already on it. :) https://vitess.io/docs/reference/vreplication/vreplication/ https://vitess.io/docs/reference/vreplication/vreplication/
dkarras 5y ago
And if your company fails my company fails with it? How would I ever move out of this? Very impressive tech! But the upside is not worth the vendor risk for me. Edit: or maybe this is not an issue at all - but the website copy does not make it clear, so take it as a suggestion please.
Aeolun 5y ago
> Developers want the durability, stability, and scalability of a SQL database but do not want to be constrained by managing a schema Speak for yourself. I love my schemas. This article is also 100% fluff, and zero actual information. Obviously I won’t sign up to anything without an ounce of information being provided up front.
- mixmastamyk 5y ago
  Indeed, you either manage a schema or get managed by it.
  - samlambert 5y ago
    This is MySQL. There is a schema. We just make it super easy to manage.
    - mixmastamyk 5y ago
      Sounds good, thanks. Any reason these folks chose mysql? Wouldn’t have been my first choice. Edit: appears the middle layer is mysql only.
- lysecret 5y ago
  Haha that's actually a good point. I love to have a reference for how my data is structured.
  - deleted 5y ago
    [deleted]
  - shlomi-noach 5y ago
    Per https://news.ycombinator.com/item?id=27203568 https://news.ycombinator.com/item?id=27203568, there is a a normal MySQL schema. This is about how PlanetScale solves the schema management friction, so as to enable developers working with schemas: safe branching, online schema changes, deployment queues, protected branches, conflict resolution. (I'm an engineer at PlanetScale)
etaioinshrdlu 5y ago
I heard YouTube migrated away from Vitess to Spanner. Does anyone know why?
dadrian 5y ago
At 100,000 writes per second (which is roughly what the last data-driven system I worked on did), this would be $400K per month. It seems to be the case with all the NewSQL databases that they're still just not economical to run unless you are FAANG. Get a Bigtable / HBase / etc and build a custom system and save $50-350K per month. For a sub 100 person company, it's a no-brainer.
numToStr 5y ago
If you look closely, its logo look like a planet is dabbing.
voiper1 5y ago
What are the geographical locations - can I choose which data center? What kind of redundancy or backups are there? Does a full table scan count as a read? Is there planetscale specific tooling for managing indexes or primary keys?
slooonz 5y ago
How does branching work ? Is it provided by Vitess, or did you build it on top of it ?
igravious 5y ago
Railsers, if you're perplexed by what's going on here this Rails specific documentation helped me: https://docs.planetscale.com/tutorial/connect-rails-app https://docs.planetscale.com/tutorial/connect-rails-app
ksec 5y ago
Am I the only finding it extremely light on useful information? And after reading all the comments here those questions are still not answered. Basically a Hosted Vitess with MySQL? Where is DC? Backup included? Redundancy? Spending Cap? Own Infrastructure or on top of other Cloud ? Support Level? Uptime Guarantee? etc etc. All of these are basic info required from a SaaS, and they are missing. Not even a FAQ.
- jccooper 5y ago
  DC seems to be Amazon East-1 based on their status page [https://planetscale.freshstatus.io/ https://planetscale.freshstatus.io/]. As for the rest? Very good questions. Just coming out of beta, so perhaps they're still filling out the website.
  - ksec 5y ago
    >Just coming out of beta Thanks for the info on Amazon. I guess I will have to check it out again when they announce it is out of beta.
Gys 5y ago
I cannot find anything on the website about matters like uptime and backups?

279 points by samlambert 5y ago

I have been using the beta version of PlanetScale for a while, and it is extremely cool. It's using the mature technology that powers Youtube to provide a developer experience for databases similar to what Vercel and Netlify provide for hosting: It will give you a database branch for each Git branch and help you manage the workflows around it. And it is the first truly serverless relational database offering that I am aware of. The cost scale to 0, so it is perfect for small projects, but that same instance will scale to support massive load when you need it.

cfors 5y ago

> 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. So is this a wrapper around managing Schemas powered by Vitesse? (Btw, had to go to your github to figure that out) If you want to be the database for developers you should know that developers do care about how you do this scaling.

Allstar 5y ago

It's not entirely clear from the website or the documentation, but this seems to be build exclusively for MySQL?

samlambert 5y ago
Yes we are MySQL compatible.
- rad_gruchalski 5y ago
  100% compatible? Is there a document with a compatibility matrix? Edit: I guess this is it: https://vitess.io/docs/reference/compatibility/mysql-compatibility/ https://vitess.io/docs/reference/compatibility/mysql-compati....

Rauchg 5y ago

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.

adamfeldman 5y ago
Branching wasn't mentioned in the linked blog post, but I assume that is what the parent comment is excited about: https://docs.planetscale.com/concepts/branching https://docs.planetscale.com/concepts/branching
- Rauchg 5y ago
  Indeed, thank you!
eurasiantiger 5y ago
It doesn’t solve the N+1 queries problem in a generic way. That is a major hurdle in scaling complexity-wise, which in turn is often deeply coupled with business realities. 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).
- ransom1538 5y ago
  "It doesn’t solve the N+1 queries problem in a generic way." IMHO, this isn't trying to solve people looping queries. The fastest way to solve this is to not loop queries. This solves auto-sharding (well vitness did). See slack architects comment below.
  - eurasiantiger 5y ago

christiansakai 5y ago

will this support blob as well like S3?

CSDude 5y ago

It looks great, congrats

harshit164 5y ago
Appreciate that. thank you

nebulous1 5y ago

I have to admit that with the previous mocking of "web scale", I initially assumed this was satire.

briandoll 5y ago

Before GitHub launched, I built some large eCommerce sites, and for a vcs we used CVS, and then Subversion. We had a person on our team with the title of release manager, because branching in Subversion, and merging back to make releases, was a specialist effort that took time, patience, and managing a tremendous amount of fighting between teams of what features and fixes could even be merged together in order to ship this release. When I started using git, it broke my brain. I wasn't really sure I understood it, but the idea of cheap local branches soon became the most important thing to me in a vcs, and everything became easier and so much faster. You could just work on code the way real life happens, not in some methodical pre-planned release schedule that always rubbed harshly against the reality of bug fixes and ever changing minds. Planetscale is a lot like that transformation. We've been thinking of databases as this specialist thing, where the arcane knowledge required to make it perform well is a specialist role, and something completely untouchable by mortal engineers. While we've learned about the importance of good data modeling, we've dealt with a layer in our stack that is essentially static. Shipping features that require changes to a database schema sit and languish, because the pain and coordination required can often be too much for a team to want to deal with. What PlanetScale has done is solve two massive problems in one platform. First, since it's built on Vitess, it Just Works At Scale. You don't need to fiddle with knobs to get it to perform well. You most definitely are not even in the top 10% of what is already running on Vitess, so you don't really need to worry about ever outgrowing PlanetScale. But the BIG innovation here is what is possible now that a database works the way the SDLC has evolved with git. Make a branch, change the schema, roll it out with your code. Just like anything else, really. Use the PlanetScale CLI to actually USE your database. Change the schema because it will make your code better, and don't worry that you're somehow going to do it wrong. PlanetScale just made databases useful for developers beyond a nearly-static data store. It's a high-scale database that you can change like code. It will break your brain a little at first, just like git did. And then you'll wonder why the hell we waited so long to have a database this good.

chris_st 5y ago
Sounds great! One question about pricing -- I can't tell if the "free" tier costs are for one month, or ongoing. That is, do you get the free tier amounts for one month and then pay from then on, or is that level of service free from then on?

deleted 5y ago

[deleted]

jaredcwhite 5y ago

Can I install this locally? Will it work without an internet connection? Is it fully open source? From what I can tell, the answer to all three questions is no. Is it yet another example of vendor lock-in? Yes.

deleted 5y ago
[deleted]
unknown_error 5y ago
There is still value in proprietary solutions that offer significant time/money savings vs open source. Not all of us have infinite resources to develop and maintain every solution in-house, whether that's an auto-scaling database or email or Google Docs or whatever. For small/medium businesses, sometimes it's better just to let the experts do their thing and build on top of it...
sigg3 5y ago
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.
- jaredcwhite 5y ago
  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.
  - piaste 5y ago
    True enough, but by that standard, every service would constitute lock-in. A cleaning company isn't lock-in just because you don't have in-house janitors. "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.

paxys 5y ago

If I understand correctly, PlanetScale = hosted Vitess? I assume it was started by the creators/maintainers of the project (similar to Confluent and such)?

samlambert 5y ago
Yes!

stalluri 5y ago

Branching looks super dope! https://docs.planetscale.com/concepts/branching https://docs.planetscale.com/concepts/branching

wiradikusuma 5y ago

Can serverless solutions e.g. AWS Lamba or Google Cloud Run connect to this?

samlambert 5y ago
Yes absolutely!
- jopsen 5y ago
  Where is it hosted? Do you have instances in all data centers moving shards to where they are used? Using databases outside the same availability zone can be slower...

aantix 5y ago

I wonder what the latency would be to have a heroku insurance pointed at a PlanetScale instance. Doesn’t look like there’s Postgres compatibility.

vira28 5y ago

Wondering will we see something like this for Postgres? I like the cool things but I can’t migrate to MySQL just because of this.

samlambert 5y ago
Sure you can! and we will make it worth it.
- NAR8789 5y ago
  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_ undertaking. Sure, it might make sense for you to contribute to in the long run to open up that customer segment, but at your current stage postgresql customers are probably more of a product-distraction than anything. In that light, driving us away for now is probably the best policy. I'm gonna give you the benefit of the doubt. Well played, sir. Well played. EDIT: nevermind, all your other comments so far in this thread are variations on "Yes, we can do that!". You're promising the moon, and that's fishy. Bit of unsolicited advice (you know what they say about unsolicited advice, but here goes...): You'd be better off admitting some weaknesses and discussing tradeoffs. For examples, take a look at other HN threads where execs have hopped on. What qualities do you seen in posts that get the most positive responses? Now compare that to the confusion and skepticism in this thread. Your messaging has landed off-target. You're proposing to take over a piece of people's critical production infrastructure. As a potential buyer considering an infrastructure provider, seeing "buy our product and we'll solve all your problems" just makes me skeptical. It makes you sound like a used car salesman. Your landing page delivers that basic message, and your comments in this thread reinforce the resulting impression. Conversely, if in these comments you soberly acknowledged your limitations, transitioned to a detailed treatment about tradeoffs, and _then_ used that save to toot your horn some more, that would give the impression you've considered this problem deeply, help me figure out how closely your value prop is aligned to my goals, and make me more inclined to trust you, your company, and your product. As it is... I see your comment and it makes me think your company isn't ready to take on my infrastructure (this is my database we're talking about here... if you're not taking something as basic as migration costs seriously, what other nasty surprises are waiting for me down the line?). Then, I take a look at your about page (maybe this guy's just an entry-level marketer in the people-pleaser phase), and I see that you, Sam Lambert, are the Chief Product Officer. That gives me some serious doubts about the future viability of your company, because now I'm worried the CPO is fundamentally out of touch with the userbase and can't grapple with difficult details. You will not be touching my data any time soon, but I'll be watching for changes, and I honestly wish you luck. I like your vision, but your messaging execution needs work and your product execution is yet-unproven. EDIT: kudos to lizztheblizz for giving more detailed answers that inspire confidence. You've significantly repaired my impressions of your company.

capableweb 5y ago

Sounds interesting but there is not enough information for me to get a picture of what this actually means. Thought I was gonna be clever and install it, run it and see what it is all about but I can't figure out how to get it. One link is "sign up" and the other is "contact sales" but I'm not interested in either, I'm interested in "Download" but I cannot find it anywhere. Am I stupid or misunderstanding something fundamentally here? Is just a hosted DB or something like that?

moshmosh 5y ago
It's a hosted DB, and as far as I can tell the Killer Feature is that it makes schema updates less painful. How it does that without significant performance trade-offs or caps is unclear to me. [EDIT] on reading further in their docs, my suspicion is that their "branching" concept is a hell of a lot more limited than I believed at first. I initially took it to mean you could have multiple active schemas working on your data at once—instead, I think it's more like exporting just the schema of your DB and importing it to a fresh DB, which is nothing new and doesn't run into all kinds of operational and security issues the other workflow would. I'm fairly sure all the actual magic is in the schema diffing, and the docs make me think even that isn't as fully-magical as one might hope.
- lizztheblizz 5y ago
  It's closer to your original assumption than your second. Branching relies on vreplication, and it does actually allow you to develop multiple versions of your schema against your full production dataset. The "magic" is a powerful materialization engine that allows every branch to maintain its own version, and it _does_ allow you to work with your actual data. This is just scratching the surface of what that can do, though. We have loads more features cooking. :)

2color 5y ago

This is wonderful. I've been developing with relational databases for 12 years and couldn't be more excited about this. Scaling down to 0 opens up a world of opportunities when it comes to team development workflows. The idea of quick environments per pull request is within reach. Not to mention that it scales with you. The one thing I'm curious about is how it compares with CockroachDB

machiaweliczny 5y ago
Quick environment per pull request is available with SQLite now :)
lizztheblizz 5y ago
12+ years of massive scale production use for Vitess and 26+ years of hardening for MySQL and InnoDB. PlanetScale adds some (imho) great features on top of that, but it's standing on the shoulders of giants that have proven themselves over and over. ... Also, I guess it's MySQL-compatible rather than Postgres-compatible? :)

unknown_error 5y ago

Can someone please explain how Vitess works, in plain English? How does it magically make MySQL scale? And then what does PlanetScale add on top of Vitess hosted anywhere else? Sorry, the linked blog post is both very abstract and assumes a high level of preexisting knowledge about database scaling.

moshmosh 5y ago
IME the answer to "how did they make [hard to scale thing] easily scalable?" is usually that they introduce limitations in how you can use [hard to scale thing] so you can't use it in ways that are hard to scale, then automate scaling it in well-known ways for use cases that are so-limited. Vitesse's site mentions that it relies on horizontal sharding, so right off the bat, my guess is that you can't use it in ways that are sharding-unfriendly, or if you can then you'll be met with restrictions on much of the "magic" of it if you do. Rarely is it the case that someone's actually discovered e.g. novel math or something to make the hard part easier. Better tools (to do well-understood things more easily for this use case) and restrictions (so you don't use it in ways the tools can't handle) are the usual way.
- lizztheblizz 5y ago
  The "ease" we used to refer to in Vitess primarily relates to its interaction with the application side, where it basically presents itself as "one big MySQL datastore". It uses a standard MySQL connector, and in general, once you have the infrastructure up and running with a compatible schema design, there's not too much to worry about from a coding standpoint. Sharding happens transparently to the application code, which generally translates to fewer code changes required. Admittedly, that view left out the considerable challenge of actually deploying and running the infrastructure, designing and optimizing that schema, along with all the joys of managing large cluster environments. That's what PlanetScale, the product, aims to solve. Dealing with clustering infrastructure IS a hurdle for most teams to overcome, and though Vitess' feature set and compatibility has expanded greatly to accommodate some of the most demanding use cases on the web today, a lot of its functionality can still be out of reach for a developer just trying to merge some code and a schema change. Abstracting as much of that complexity away from the end user is the goal, as well as making their lives easier with a ton of the functionality we've always wanted to see built with Vitess. I can confirm that that is not an "easy" job on our end. :)

qaq 5y ago

With solutions like CockroachDB, YugabyteDB etc. gaining steam do things like Vitess have a place long term?

satyrnein 5y ago

It sounds like the database branch has copy of the production schema, but what about the data itself? We've been using AWS Aurora clones to quickly give developers copies of production, can zero-copy clones be made as part of the branch?

pratio 5y ago

The pricing gives me anxiety. $1.25/mo per 10GB storage $15/mo per 100 Million rows read $15/mo per 10 Million rows written But I won't lie, super excited to give this a try.

gryzzly 5y ago

is it not funny that something with a word "scale" in it disabled creation of databases because of being under load?

itwy 5y ago

> The site is experiencing higher than normal traffic and we have temporarily halted database creation. Ironic coming from the infinitely scalable database, isn't it?

paxys 5y ago
Well that restriction will probably disappear if you just give them your credit card number
chachra 5y ago
ironic indeed...took me a few seconds to read the white text on a yellow banner at the top why I couldn't create a db!

halostatue 5y ago

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 always a schema, and learning to manage it is a _good_ thing. If you’re not ready to manage and migrate, then you’re not in production. You’re in something else.

deleted 5y ago
[deleted]
Aeolun 5y ago
Schrodingers production environment.
shlomi-noach 5y ago
There is always a schema, and PlanetScale, in particular, promotes the use of schemas. That is, behind the scenes we operate Vitess, which is an infrastructure and sharding framework on top of MySQL. You will create schemas in PlanetScale just as you would in MySQL. Managing the schema, though: operating schema changes in code and in production, mitigating schema conflicts, scheduling migrations, running online migrations, experimenting with schema changes, etc., are something relational databases don't provide the right (or any) tooling for developers, and this is one of the things PlanetScale aims to bring to developers. In my past experience as a production engineer, and in our many discussions within the community, we've seen many approaches developers take just to avoid the hassle of running yet another ALTER TABLE; whether because it requires going through a different team, or because this poses an availability risk, etc. PlanetScale offers to bring ownership back in the developer's hands. Hope this clarifies. We'll publish more soon, and I'll be able to provide more links. (I'm an engineer at PlanetScale) (Edit for grammar/typos)
- halostatue 5y ago
  I’m not sure what to say to that. In the former (database changes belong to a different team), there’s not much that can be helped. Given the number of people—on HN, no less—who have war stories about having accidentally dropped the production database because of insufficient protections and the desire of many businesses to know that their vendors are following SOC2 and similar safety and security protocols, I completely get that. In the latter case (availability risk), there’s no sympathy I can provide. Developers need to be aware of what their changes mean. Sometimes this means that you make a separate table. Sometimes it means you have a downtime event which means an overnight deploy. Sometimes it means you have to figure out how to do a zero-downtime series of migrations. Step 0: make sure you need the migration. Step 1: modify the app to conditionally query or update the new column based on whether the change is present or not, and without requiring a value in the column. (Since it’s not, this will work as an `if false` case for now.) Deploy. Step 2: modify the database to add the column with no constraints (safe and trivial on most SQL databases). Deploy. Step 3: modify the app to start filling in fields that should not be null. (That is, provide constraint validation at the application level; or, if dropping a column, start setting the value to a least damaging value or NULL if you could have made a required field no longer required.) Deploy. Step 4: After some time, run a backfill to fill in new required values (or clear old values) that haven’t been modified yet. If you’ve done this right, it should be a small number. Optionally, do this periodically for small subsets of data. Step 5: Run a final backfill and deploy a schema migration that adds your constraint/drops your column (dropping a column is optional if you’ve got a hard zero downtime requirement; just make sure no one tries to use it and make sure it’s not part of the application schema; schema comments are your friend). Step 6: Deploy a version of the app that doesn’t act conditionally. Yes, it takes longer. I’ve run migrations this way for the last seven years and we’ve had essentially _no_ downtime because of migrations. I think we’ve had ~4 hours of preventative downtime across ~10 databases in that time. Usually, when we’re ready for the piece that can cause downtime…there’s about a five minute hiccup. Developers who can’t reason through safe table alterations shouldn’t be making those changes, and PlanetScale is going to make some business people very unhappy when their developer changes something that they didn’t actually understand and causes downtime regardless of PS’s “guarantees”.

golondon 5y ago

Aren't schema changes are actually a big problem when there is a huge amount of data in the table. Adding a column / index to a table that has 500M rows in it is usually the pita. This is definitely something on the right direction, but would love to see this supporting this with the data itself.

lizztheblizz 5y ago
That is exactly what we _do_ support. Our team includes the original developer of gh-ost for MySQL, which has been built to execute these kinds of massive changes at scale at GitHub. We've integrated it tightly with Vitess. Once your branch is ready to be merged with production, it executes that change in a completely non-blocking way.
- golondon 5y ago
  Ok, but most of the time you would like to test that change on a copy or almost up to date replica, to see measure things like how long it does take. If you were copying the data, with things like PII filtering, to the branch development database and allow folks to test it there it would be even more amazing. Great start tho!
  - lizztheblizz 5y ago
    Give it a shot, because the current implementation specifically side steps the need for that full copy, and does let you test functionally against fully up-to-date production data. You're right, though, it doesn't cover all of those uses cases. Luckily, Vitess does offer most of that out of the box already. Just need them exposed through the PlanetScale UI. :)

ngrilly 5y ago

Really great finally seeing a “serverless” SQL database based on MySQL and Vitess that scales from 0 to n, even with a free tier! Where are you hosted? What latency should we expect from AWS, GCP, DigitalOcean and fly.io? And also what degree of compatibility should we expect with MySQL? The doc is quite sparse on this.

lizztheblizz 5y ago
Vitess' compatibility with MySQL has made major leaps in the past couple of versions and the team has started focusing on locking in ongoing compatibility with various popular development frameworks. You can find those here, and more are getting added regularly: https://github.com/planetscale/vitess-framework-testing/ https://github.com/planetscale/vitess-framework-testing/ The basics of MySQL compatibility are described in here, though it's important to keep in mind that just because something "works" doesn't always mean it's the best way to do things in a sharded environment: https://vitess.io/docs/reference/compatibility/mysql-compatibility/ https://vitess.io/docs/reference/compatibility/mysql-compati...
- ngrilly 5y ago
  Thanks! Not having window functions and CTEs is a significant limitation for any kind of data analysis. But I guess the main use case is pure OLTP where it is – a bit – less relevant.

adambair 5y ago

The amount of buzzwords on the site made me think this was some kind of elaborate joke. I'm not yet convinced it isn't...

olivierlacan 5y ago

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-changes https://docs.planetscale.com/concepts/nonblocking-schema-cha...

lizztheblizz 5y ago
To be clear, this is not a Vitess/PlanetScale-specific opinion or choice. Foreign key constraints are a bit of a controversial topic in large-scale MySQL environments in general, which is the greater context in which this design decision was made by the Vitess team. 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-schema-change.html 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 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-mariadb https://federico-razzoli.com/foreign-key-bugs-in-mysql-and-m...
- Jarwain 5y ago
  Do you know if foreign keys tend to be a problem on postgresql as well?
  - lizztheblizz 5y ago
    I don't have nearly the experience in Postgres environments to have seen the same level of real-world impact there, but a quick search presents me with the following documentation, which seems to indicate mostly similar performance challenges related to the use of Foreign Key Constraints: https://www.postgresql.org/docs/13/populate.html#POPULATE-RM-FKEYS https://www.postgresql.org/docs/13/populate.html#POPULATE-RM...

k__ 5y ago

I'm currently searching for a serverless database for my next project and will look into it. 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.

tasuki 5y ago
What is a serverless database and why are you searching for one for your next project?
- k__ 5y ago
  A managed database thats automatically scales horizontally and is priced on-demand. I want it for my next project, because I don't want to pay for what I don't use, but also don't want to provision or maintain additional instances manually.
  - tasuki 5y ago
    Explanation at the exact level of detail I wanted - thank you :)

asimpletune 5y ago

So just wanted to add a few random thoughts about some of this stuff. 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.

isatty 5y ago

What is this? Reading this post does not explain it, but I figure it some sort of new DB.

dastbe 5y ago

What do yall see as the next devx improvements beyond branching and no-fear schema migrations? I'd be really interested in how you might apply the workflows you're defining towards (IMO) bigger problems like data migration and backfills.

lizztheblizz 5y ago
Already on it. :) https://vitess.io/docs/reference/vreplication/vreplication/ https://vitess.io/docs/reference/vreplication/vreplication/

dkarras 5y ago

And if your company fails my company fails with it? How would I ever move out of this? Very impressive tech! But the upside is not worth the vendor risk for me. Edit: or maybe this is not an issue at all - but the website copy does not make it clear, so take it as a suggestion please.

Aeolun 5y ago

> Developers want the durability, stability, and scalability of a SQL database but do not want to be constrained by managing a schema Speak for yourself. I love my schemas. This article is also 100% fluff, and zero actual information. Obviously I won’t sign up to anything without an ounce of information being provided up front.

mixmastamyk 5y ago
Indeed, you either manage a schema or get managed by it.
- samlambert 5y ago
  This is MySQL. There is a schema. We just make it super easy to manage.
  - mixmastamyk 5y ago
    Sounds good, thanks. Any reason these folks chose mysql? Wouldn’t have been my first choice. Edit: appears the middle layer is mysql only.
lysecret 5y ago
Haha that's actually a good point. I love to have a reference for how my data is structured.
- deleted 5y ago
  [deleted]
- shlomi-noach 5y ago
  Per https://news.ycombinator.com/item?id=27203568 https://news.ycombinator.com/item?id=27203568, there is a a normal MySQL schema. This is about how PlanetScale solves the schema management friction, so as to enable developers working with schemas: safe branching, online schema changes, deployment queues, protected branches, conflict resolution. (I'm an engineer at PlanetScale)

etaioinshrdlu 5y ago

I heard YouTube migrated away from Vitess to Spanner. Does anyone know why?

dadrian 5y ago

At 100,000 writes per second (which is roughly what the last data-driven system I worked on did), this would be $400K per month. It seems to be the case with all the NewSQL databases that they're still just not economical to run unless you are FAANG. Get a Bigtable / HBase / etc and build a custom system and save $50-350K per month. For a sub 100 person company, it's a no-brainer.

numToStr 5y ago

If you look closely, its logo look like a planet is dabbing.

voiper1 5y ago

What are the geographical locations - can I choose which data center? What kind of redundancy or backups are there? Does a full table scan count as a read? Is there planetscale specific tooling for managing indexes or primary keys?

slooonz 5y ago

How does branching work ? Is it provided by Vitess, or did you build it on top of it ?

igravious 5y ago

Railsers, if you're perplexed by what's going on here this Rails specific documentation helped me: https://docs.planetscale.com/tutorial/connect-rails-app https://docs.planetscale.com/tutorial/connect-rails-app

ksec 5y ago

Am I the only finding it extremely light on useful information? And after reading all the comments here those questions are still not answered. Basically a Hosted Vitess with MySQL? Where is DC? Backup included? Redundancy? Spending Cap? Own Infrastructure or on top of other Cloud ? Support Level? Uptime Guarantee? etc etc. All of these are basic info required from a SaaS, and they are missing. Not even a FAQ.

jccooper 5y ago
DC seems to be Amazon East-1 based on their status page [https://planetscale.freshstatus.io/ https://planetscale.freshstatus.io/]. As for the rest? Very good questions. Just coming out of beta, so perhaps they're still filling out the website.
- ksec 5y ago
  >Just coming out of beta Thanks for the info on Amazon. I guess I will have to check it out again when they announce it is out of beta.

Gys 5y ago

I cannot find anything on the website about matters like uptime and backups?