15 ms·

PlanetScale is now generally available

246 points by petercooper 5y ago

nojito 5y ago
>What’s more? This allows you to pay only for the database resources you use, on a second-by-second basis. ..." This is the biggest sham in technology offerings today. The idea that you only pay what you use is a misnomer.
- dmarlow 5y ago
  How so?
  - nojito 5y ago
    No one can accurately predict what they need plus they are incentivized to use more.
- ec109685 5y ago
  Right, should be resources you "reserve".
pepemon 5y ago
Vitess is awesome. Nice to see that there is the managed offering available too now!
gh123man 5y ago
This seems cool. I am currently shopping around for a cheap managed database for an app I am launching soon (and bootstrapping - so cost is a concern right now). We are starting small but want room to grow. The free tier looks really promising! Especially compared to some of the entry level plans on other cloud providers. Can anyone who has tried Planetscale and compared it to other managed database solutions tell me about their experience?
- dewey 5y ago
  I think going for a speciality database at this stage is premature optimization. Go with the safe choice (Existing tooling, knowledge, free tiers) and use Postgres or something else established. Later on you can always move workloads to other databases if needed.
  - AYBABTME 5y ago
    It's not really specialized, it's a fancy MySQL until you need more. And then, it becomes 'more' at the click of a button. IMO if I were starting a cheap MySQL-powered project today, I'd use their free tier. The branching stuff is genius, and they're really focused on offering a clean user experience.
- remorses 5y ago
  It is pretty awesome The dashboard is clean and easy to navigate The branching feature is really good idea, it allows you to confidently run migrations with no downtime The daily backups are also great, no additional steps to set them up They also have a graph to check query latency which is nice The only downside is that they dont have foreign keys but I used prisma referential integrity for that so not really an issue for me
  - porker 5y ago
    > The branching feature is really good idea, it allows you to confidently run migrations with no downtime So this branching feature is one I still don't understand properly. Let's imagine my startup is big enough to warrant a PlanetScale database. Hundreds of rows are written every second. When I branch, are those writes applied to the original and the branch? If so, what happens with migrations that mean the incoming writes no longer work? Or is the "confidence" it gives not about full migrations but about knowing that if your migration fails the original DB is still working?
    - aseipp 5y ago
      Every branch in PlanetScale has its own separate MySQL connection credentials first off (and conceptually just looks like a separate DB), so no. You'll be using your main production database as usual, and you'll have separate credentials for a branch where you can make schema changes like ALTER TABLE, and you "connect" to that branch with... whatever. Deploy a canary version of your app, use your SQL IDE, whatever. The main branch always prohibits changes like ALTER TABLE or CREATE DATABASE. Merging a branch where the CREATE/ALTER happened is the only way to bring changes to the production database that serves your users queries. When you merge a branch in PlanetScale, you can still write to the database while the migration is happening, online. This is done through "Online Schema Change", but the TL;DR is that a system in the background creates the new database, reads the mysql binlogs from your original database, including all the writes, and propagates those writes to the new database with the changes applied. It does this continuously, in real time. Once the new database is caught up, the system switches over transparently to make the changes atomically appear live.[1] The requirement is that the running application server has to be able to handle both the old and new schema at the same time. This is easy if you do something like "add a column that isn't yet used and will be soon", but harder for "dropping a column that is in use". No database alone can solve this however, you have to coordinate your application layer correctly so that it can handle the switch over when you apply the changes. But this means you can have very high uptime with e.g. blue/green deployments and staged rollouts, and you'll never have to take your DB offline for it. It's also trite but "hundreds of writes a second" is nothing. Vitess can handle 100x that write load (probably much more) and deal with schema changes to petabyte-scale databases completely online. PlanetScale currently doesn't let you control the Vitess keyspace sharding configuration (yet) which is crucial to this but I suspect it will happen eventually. But they'll also let you run Vitess in your own K8S environment while they provide a control plane, so you wouldn't pay list price, anyway. I do not have any affiliation with PlanetScale but it's a pretty cool product I could see myself using for my low-volume needs, just because of the pay-as-you-go model where I don't pay for e.g. RDS allocation. And I say that as a really big PostgreSQL fan. [1] https://github.com/github/gh-ost https://github.com/github/gh-ost
ahachete 5y ago
I'm a bit confused with the "branching" [0] and "non-blocking schema changes" [1] features. I'm confused as they sound like "the next big thing" and I don't see anything special here. Not saying are bad concepts or ideas, the contrary. But not really useful either. Surely I'm missing something, so I would love to hear from the PlanetScale team here if possible. I have a strong and long Postgres operational background, so I may be also here with assumptions that might be different in MySQL/Vitess/PlanetScale. My main concerns/questions are: * I can't imagine testing DDL changes without data. Having data there is so important to understand the change and its impact, that I won't do them without data. And unless I'm mistaken, these branches only contain DDL, no data at all ("data from the main database is not copied to development branches"). * While it sounds neat, has a web UI and a CLI, managing branches of a schema and using CI and approval lifecycle... is something that sounds like I could do, and possibly better (as it is more integrated with tooling and workflows) from Git platforms themselves, isn't it? I could do branches, merges, CI, comments on MRs, approval... I could even easily build a deploy queue ("promote") with a CI. Doesn't sound like too hard. * I don't understand how the "safeness" and the non-blocking nature of changes are ensured. Many DDL changes will take different amount of locks on rows or tables, which may cause some queuing and even lock storms in the presence of incoming traffic. Without incoming traffic, they may run fine. In other words: the impact of a migration can only be determined in combination with the traffic hitting production. How does PlanetScale do this? How for example is handled the case where a DDL changes the type of a column to another type which causes a table rewrite, which essentially locks the table and prevents concurrent writes? Again, not saying both concepts are bad. Terminology and methodology may be already an innovation. And surely I'm missing a lot. But other than this, I don't see myself using this (testing migrations without data is a showstopper, and not the only one) and I don't see much of an innovation from a safeness perspective here. Why this system isn't one where thin clones of the database are created as the branches (e.g. like in Database Lab Engine [2]), where you can play with data too, and then some data synchronization is performed to switch over to the branch once done (is not easy at all, but doable with many precautions)? That would be a significant improvement in the process, IMHO. [0]: https://docs.planetscale.com/concepts/branching https://docs.planetscale.com/concepts/branching [1]: https://docs.planetscale.com/concepts/nonblocking-schema-changes https://docs.planetscale.com/concepts/nonblocking-schema-cha... [2]: https://postgres.ai/products/realistic-test-environments https://postgres.ai/products/realistic-test-environments
mooreds 5y ago
If you don't know what PlanetScale is, it is a serverless database offering. It is compatible with MySQL and offers lots of tooling on top of it. More here: https://docs.planetscale.com/ https://docs.planetscale.com/ When I looked at it a few months ago, it had some limitations (lack of referential integrity, MySQL version compatibility) but I'm not sure if they've been addressed (or, in some cases, if they are possible to address). Anyway, always nice to see more competition in such a fundamentally important space, so congrats!
- mercwear 5y ago
  Thanks for this. The site does a poor job of explaining what they actually do
- epberry 5y ago
  The referential integrity piece (otherwise known as Foreign Keys) will not be addressed and is a limitation - some might say feature - of Vitess. They wrote a pretty good piece about it here, https://docs.planetscale.com/tutorials/operating-without-foreign-keys https://docs.planetscale.com/tutorials/operating-without-for...
  - mooreds 5y ago
    Thanks, that looks pretty useful. To me, this means that planetscale (and vitess) immediately become less useful for a large class of applications: existing apps that use an RDBMS that you want to scale. Because most existing apps will expect FKs. I haven't tested my employer's application (which has FKs) to see what will happen, but I doubt it will be smooth sailing. But there's probably plenty of greenfield development where teams would prefer to stick with standards like SQL rather than a proprietary noSQL language, and that seems like a great fit for this solution.
    - jeffbee 5y ago
      There is not and will never be a solution to the problem of horizontally scaling an application and database designed jointly for a single-box ACID RDBMS. You have to compromise something to get the scaling.
candiddevmike 5y ago
Open source, serverless, developer experience, really going for SEO with this blog. But it doesn't say anything about what the product does or that it's MySQL compatible. Don't waste your time reading it.
- SnorkelTan 5y ago
  Also mentions the incredible journey they are on... Reminds me of https://ourincrediblejourney.tumblr.com/ https://ourincrediblejourney.tumblr.com/
notum 5y ago
It's nice that they have solved backups in a very respectable manner which alleviates the feeling of being locked in.
ComputerGuru 5y ago
So does this share MySQL’s weaknesses? As someone that used MySQL for over a decade before seeing the light and switching to Postgres, I’d be more reassured if this wasn’t compatible with any existing RDBMS than with it being MySQL compatible.
- gmiller123456 5y ago
  What made you switch to Postgres?
  - deathanatos 5y ago
    https://grimoire.ca/mysql/choose-something-else/ https://grimoire.ca/mysql/choose-something-else/
    - derekperkins 5y ago
      As with most similar rants against the earlier days of MySQL, the majority of these points are based on old versions and don't reflect how things have been for almost a decade.
      - deathanatos 5y ago
        The question was what made me switch, which was all the crap MySQL does to a dev. That blog post is the best that I know of that captures the fractal of bad design that is MySQL. While, yes, it matches my understanding that some of those points are no longer valid, it doesn't match my understanding that most of the points are no longer valid. (E.g., just a few years ago, when I last used MySQL, I seem to remember that it still struggled w/ UTF-8, still struggled with the definition of what a "key" is, and still struggled with functional dependencies.)
        derekperkins 5y ago
        Postgres is a great choice too, and for most intents and purposes, Postgres or MySQL is the correct default choice for a database, so I'm not trying to persuade you to switch back. Just clarifying that almost none of the points in that article are still valid, including UTF-8 handling. The author themselves put a disclaimer at the top of the article stating as much. Not quite sure what you mean by "definition of a key" or "struggled with functional dependencies", so I can't speak to those directly.
herodotus 5y ago
I am having trouble understanding what a "Serveless Database" is. When I do a search of the term, I get hype, not a definition. For example: "What is Serverless Database? Serverless Database is a prerequisite for Serverless Computing. These are specially designed for the workloads which are unpredictable and can change rapidly. What’s more? This allows you to pay only for the database resources you use, on a second-by-second basis. ..." I would really appreciate it if someone would give us a clear definition of this term.
- pm90 5y ago
  “Pay for only what you use” database.
  - freen 5y ago
    Scales up and down automatically.
  - mbesto 5y ago
    I'm curious about what kind of workloads people would be using a serverless DB for? If I understand it correctly, let's say my DB is only being used to process 1M transactions from 9am-1pm, I'm basically only paying for the load during that time, versus a managed DB where it's being paid to be on 24/7. With most serverless there is a penalty though - cold startup. So is it purely an economic play for esoteric DB workloads? If my DB is realistically going to be churning for 24/7 anyway, why would I ever use serverless DBs?
    - spelunker 5y ago
      Lower operational burden - if you're using a serverless db maintaining servers is one less thing to think about. Same with any infrastructure - you don't have to worry about orchestration, load balancing, authentication, etc.
      - mbesto 5y ago
        I mean, I can essentially do this with any PaaS DB, no? RDS, Azure SQL, Cosmos, etc.
Xorlev 5y ago
"built on top of the only open source database proven at hyper scale, Vitess." Vitess is a sharding layer. Furthermore, I'm sure Cassandra (for all it's flaws) would beg to differ, Netflix had a huge C* deployment. Is hyperscale larger than webscale? Hmm...
- ksec 5y ago
  >Is hyperscale larger than webscale? I am sure Youtube is larger than Netflix, by many order of magnitude.
  - atombender 5y ago
    Note that YouTube no longer uses Vitess. It was migrated over to Spanner 2 years ago (maybe earlier).
    - derekperkins 5y ago
      FWIW, that migration wasn't because they chose to move to Spanner, they were required to.
sergiotapia 5y ago
Warning: One misconfiguration of your database and you will get hammered by billing. One guy forgot to put foreign keys and got a $20,000 bill.
- sudhirj 5y ago
  Indexes, rather. They charge by rows read, so if you don't add indexes you will (very quickly) read all the rows in your table on every query. That racks your bill really fast. The foreign key thing is because the author thought foreign keys add indexes, but here foreign keys are no-ops and don't do anything. Because it's so distributed there's no support for foreign keys.
- samlambert 5y ago
  Nonsense. It wasn't 20k and it was corrected.
  - hyuuu 5y ago
    link?
    - manigandham 5y ago
      Here's the story: https://news.ycombinator.com/item?id=29132572 https://news.ycombinator.com/item?id=29132572
cyounkins 5y ago
I'm skeptical that YouTube would be using this for anything remotely significant given Google's strong propensity to only use internal technologies that they fully control.
- qaq 5y ago
  This was opensourced by google founders were @ google and wrote the thing
- romero-jk 5y ago
  They swithed to spanner.
- danielrhodes 5y ago
  I doubt YouTube is using the cloud service. If they're not 100% on Google's services by now, they still use Vitess. Vitess is the open source project PlanetScale manages which lets you horizontally scale MySQL databases.
jfbaro 5y ago
Congrats! Amazing offering. Is there any plan to support PostgreSQL as well?
fabian2k 5y ago
I still don't understand how you can work safely with this kind of pricing model. You pay $1.50 per 10 million rows inspected by the database. A relational database like MySQL has a query planner, so you're not fully in control over how exactly the database accesses your data. How many rows are read not only depends on your specific SQL query but also on the contents of the tables you read and the parameters supplied along with the query. A statistics update that triggers a bad query plan on a table with 10 million rows could cause a full table scan instead of retrieving a few rows using an index scan. Suddenly your query is a million times more expensive at $1.50 per query. Depending on how quickly and widely this scales, that could get very expensive very fast. 10 million rows is also not a lot for a relational database. I know my comparison now isn't fair as you get a lot more with the hosted version, but a quick and dirty experiment with Postgres and a small table of two ints and a text column with 10 million rows took ~1.5 seconds to query on my desktop, using only 1 CPU core. Translated into this pricing model that's something like $60 per minute.
- siquick 5y ago
  "Hey Infrastucture Finance Boss, we need a new database." "Thats cool, how much per month should we budget?" "$1.50 per 10 million rows inspected" "What? How much is that per month?" "TBC, and we won't know until we start using it" "RDS is $x per month so you're sticking with that"
- jabo 5y ago
  Their CEO mentioned that they’re working on an updated pricing model to address this issue, in another HN thread: https://news.ycombinator.com/item?id=29133026 https://news.ycombinator.com/item?id=29133026
- mooreds 5y ago
  See also https://briananglin.me/posts/spending-5k-to-learn-how-database-indexes-work/ https://briananglin.me/posts/spending-5k-to-learn-how-databa...
- rustc 5y ago
  Does MySQL (or PlanetScale) provide a way to input a query and get a lower/upper bound on the number of rows the query will "inspect" when run?
DeathArrow 5y ago
I only see buzzwords and hype in the post. Nothing technical, nothing much about why would make a good business sense to use their offering.
rubyn00bie 5y ago
PlanetScale is probably the only database vendor I like, and I don’t just like ‘em. I love ‘em. It works extremely well (Vitess) and scales easily using PlanetScales UI. The the thing that I like about ‘em so much is their great customer service… there have been a few hiccups but they’ve always been quick to remedy and above all honest about it. Vitess, for what it’s worth, is probably still under the radar for most people but is a really nice piece of technology (distributed database built on MySQL).
_ben_ 5y ago
Related to some of the comments here, we are building PolyScale.ai https://www.polyscale.ai/ https://www.polyscale.ai/ which is a global database cache. This solves regional latency and read query performance (concurrency), whilst maintaining the transactionality of the origin database.
ralusek 5y ago
Priced at more than a dollar per GB per month? Seems kind of nuts.
williamtwild 5y ago
I would love to try this out but having only worked with MSSQL and Postgres for any large datasets I wanted to check size limitations of MySql and found this from 2020: "In addition, a practical size limit on MySQL databases with shared hosting is: A database should not contain more than 1,000 tables; Each individual table should not exceed 1 GB in size or 20 million rows; The total size of all the tables in a database should not exceed 2 GB." This seems to be parroted elsewhere. 2GB is nothing. Is this accurate?
_9rq6 5y ago
I will bet my money that planetscale sales will not eclipse Amazon RDS.
compiotr 5y ago
This seems dodgy. Is planetscale behind Vitess? If you press the "Learn more about Vitess" button you get to a page that gives you the impression that it is the homepage of Vitess (and that it is their product). But the actual website of vitess (https://vitess.io https://vitess.io) mentions nothing of planetscale and the people behind it. Additionally, planetscale are displaying users of Vitess which makes it look like they are also users of planetscale.
- shlomi-noach 5y ago
  PlanetScale engineer and Vitess contributor here. As a brief history, Vitess was originally developed as an open source project in YouTube, and then handed over to CNCF. PlanetScale was created by authors of Vitess, and employs a team of Vitess developers and contributors. There are Vitess contributors outside PlanetScale, from companies such as Slack, Square, Nozzle, Pinterest and others (apologies to people/companies not mentioned). Just to explain how we work, if you ever come by to KubeCon, you're likely to find our Vitess booth. It is normally staffed by PlanetScale engineers. But in that booth we wear the Vitess hat, not the PlanetScale hat. We want to respect Vitess for being its own open source project, which we share with our community friends from different companies. Then again, as we employ many Vitess contributors, including the Vitess project leader Deepthi Sigireddi, we do pride in driving this OSS project from within PlanetScale. As we wear our PlanetScale hat, we give credit to the Vitess technology our product is based on.
max_ 5y ago
On what port does finger run on?

246 points by petercooper 5y ago

>What’s more? This allows you to pay only for the database resources you use, on a second-by-second basis. ..." This is the biggest sham in technology offerings today. The idea that you only pay what you use is a misnomer.

dmarlow 5y ago
How so?
- nojito 5y ago
  No one can accurately predict what they need plus they are incentivized to use more.
ec109685 5y ago
Right, should be resources you "reserve".

pepemon 5y ago

Vitess is awesome. Nice to see that there is the managed offering available too now!

gh123man 5y ago

This seems cool. I am currently shopping around for a cheap managed database for an app I am launching soon (and bootstrapping - so cost is a concern right now). We are starting small but want room to grow. The free tier looks really promising! Especially compared to some of the entry level plans on other cloud providers. Can anyone who has tried Planetscale and compared it to other managed database solutions tell me about their experience?

dewey 5y ago
I think going for a speciality database at this stage is premature optimization. Go with the safe choice (Existing tooling, knowledge, free tiers) and use Postgres or something else established. Later on you can always move workloads to other databases if needed.
- AYBABTME 5y ago
  It's not really specialized, it's a fancy MySQL until you need more. And then, it becomes 'more' at the click of a button. IMO if I were starting a cheap MySQL-powered project today, I'd use their free tier. The branching stuff is genius, and they're really focused on offering a clean user experience.
remorses 5y ago
It is pretty awesome The dashboard is clean and easy to navigate The branching feature is really good idea, it allows you to confidently run migrations with no downtime The daily backups are also great, no additional steps to set them up They also have a graph to check query latency which is nice The only downside is that they dont have foreign keys but I used prisma referential integrity for that so not really an issue for me
- porker 5y ago
  > The branching feature is really good idea, it allows you to confidently run migrations with no downtime So this branching feature is one I still don't understand properly. Let's imagine my startup is big enough to warrant a PlanetScale database. Hundreds of rows are written every second. When I branch, are those writes applied to the original and the branch? If so, what happens with migrations that mean the incoming writes no longer work? Or is the "confidence" it gives not about full migrations but about knowing that if your migration fails the original DB is still working?
  - aseipp 5y ago
    Every branch in PlanetScale has its own separate MySQL connection credentials first off (and conceptually just looks like a separate DB), so no. You'll be using your main production database as usual, and you'll have separate credentials for a branch where you can make schema changes like ALTER TABLE, and you "connect" to that branch with... whatever. Deploy a canary version of your app, use your SQL IDE, whatever. The main branch always prohibits changes like ALTER TABLE or CREATE DATABASE. Merging a branch where the CREATE/ALTER happened is the only way to bring changes to the production database that serves your users queries. When you merge a branch in PlanetScale, you can still write to the database while the migration is happening, online. This is done through "Online Schema Change", but the TL;DR is that a system in the background creates the new database, reads the mysql binlogs from your original database, including all the writes, and propagates those writes to the new database with the changes applied. It does this continuously, in real time. Once the new database is caught up, the system switches over transparently to make the changes atomically appear live.[1] The requirement is that the running application server has to be able to handle both the old and new schema at the same time. This is easy if you do something like "add a column that isn't yet used and will be soon", but harder for "dropping a column that is in use". No database alone can solve this however, you have to coordinate your application layer correctly so that it can handle the switch over when you apply the changes. But this means you can have very high uptime with e.g. blue/green deployments and staged rollouts, and you'll never have to take your DB offline for it. It's also trite but "hundreds of writes a second" is nothing. Vitess can handle 100x that write load (probably much more) and deal with schema changes to petabyte-scale databases completely online. PlanetScale currently doesn't let you control the Vitess keyspace sharding configuration (yet) which is crucial to this but I suspect it will happen eventually. But they'll also let you run Vitess in your own K8S environment while they provide a control plane, so you wouldn't pay list price, anyway. I do not have any affiliation with PlanetScale but it's a pretty cool product I could see myself using for my low-volume needs, just because of the pay-as-you-go model where I don't pay for e.g. RDS allocation. And I say that as a really big PostgreSQL fan. [1] https://github.com/github/gh-ost https://github.com/github/gh-ost

ahachete 5y ago

I'm a bit confused with the "branching" [0] and "non-blocking schema changes" [1] features. I'm confused as they sound like "the next big thing" and I don't see anything special here. Not saying are bad concepts or ideas, the contrary. But not really useful either. Surely I'm missing something, so I would love to hear from the PlanetScale team here if possible. I have a strong and long Postgres operational background, so I may be also here with assumptions that might be different in MySQL/Vitess/PlanetScale. My main concerns/questions are: * I can't imagine testing DDL changes without data. Having data there is so important to understand the change and its impact, that I won't do them without data. And unless I'm mistaken, these branches only contain DDL, no data at all ("data from the main database is not copied to development branches"). * While it sounds neat, has a web UI and a CLI, managing branches of a schema and using CI and approval lifecycle... is something that sounds like I could do, and possibly better (as it is more integrated with tooling and workflows) from Git platforms themselves, isn't it? I could do branches, merges, CI, comments on MRs, approval... I could even easily build a deploy queue ("promote") with a CI. Doesn't sound like too hard. * I don't understand how the "safeness" and the non-blocking nature of changes are ensured. Many DDL changes will take different amount of locks on rows or tables, which may cause some queuing and even lock storms in the presence of incoming traffic. Without incoming traffic, they may run fine. In other words: the impact of a migration can only be determined in combination with the traffic hitting production. How does PlanetScale do this? How for example is handled the case where a DDL changes the type of a column to another type which causes a table rewrite, which essentially locks the table and prevents concurrent writes? Again, not saying both concepts are bad. Terminology and methodology may be already an innovation. And surely I'm missing a lot. But other than this, I don't see myself using this (testing migrations without data is a showstopper, and not the only one) and I don't see much of an innovation from a safeness perspective here. Why this system isn't one where thin clones of the database are created as the branches (e.g. like in Database Lab Engine [2]), where you can play with data too, and then some data synchronization is performed to switch over to the branch once done (is not easy at all, but doable with many precautions)? That would be a significant improvement in the process, IMHO. [0]: https://docs.planetscale.com/concepts/branching https://docs.planetscale.com/concepts/branching [1]: https://docs.planetscale.com/concepts/nonblocking-schema-changes https://docs.planetscale.com/concepts/nonblocking-schema-cha... [2]: https://postgres.ai/products/realistic-test-environments https://postgres.ai/products/realistic-test-environments

mooreds 5y ago

If you don't know what PlanetScale is, it is a serverless database offering. It is compatible with MySQL and offers lots of tooling on top of it. More here: https://docs.planetscale.com/ https://docs.planetscale.com/ When I looked at it a few months ago, it had some limitations (lack of referential integrity, MySQL version compatibility) but I'm not sure if they've been addressed (or, in some cases, if they are possible to address). Anyway, always nice to see more competition in such a fundamentally important space, so congrats!

mercwear 5y ago
Thanks for this. The site does a poor job of explaining what they actually do
epberry 5y ago
The referential integrity piece (otherwise known as Foreign Keys) will not be addressed and is a limitation - some might say feature - of Vitess. They wrote a pretty good piece about it here, https://docs.planetscale.com/tutorials/operating-without-foreign-keys https://docs.planetscale.com/tutorials/operating-without-for...
- mooreds 5y ago
  Thanks, that looks pretty useful. To me, this means that planetscale (and vitess) immediately become less useful for a large class of applications: existing apps that use an RDBMS that you want to scale. Because most existing apps will expect FKs. I haven't tested my employer's application (which has FKs) to see what will happen, but I doubt it will be smooth sailing. But there's probably plenty of greenfield development where teams would prefer to stick with standards like SQL rather than a proprietary noSQL language, and that seems like a great fit for this solution.
  - jeffbee 5y ago
    There is not and will never be a solution to the problem of horizontally scaling an application and database designed jointly for a single-box ACID RDBMS. You have to compromise something to get the scaling.

candiddevmike 5y ago

Open source, serverless, developer experience, really going for SEO with this blog. But it doesn't say anything about what the product does or that it's MySQL compatible. Don't waste your time reading it.

SnorkelTan 5y ago
Also mentions the incredible journey they are on... Reminds me of https://ourincrediblejourney.tumblr.com/ https://ourincrediblejourney.tumblr.com/

notum 5y ago

It's nice that they have solved backups in a very respectable manner which alleviates the feeling of being locked in.

ComputerGuru 5y ago

So does this share MySQL’s weaknesses? As someone that used MySQL for over a decade before seeing the light and switching to Postgres, I’d be more reassured if this wasn’t compatible with any existing RDBMS than with it being MySQL compatible.

gmiller123456 5y ago
What made you switch to Postgres?
- deathanatos 5y ago
  https://grimoire.ca/mysql/choose-something-else/ https://grimoire.ca/mysql/choose-something-else/
  - derekperkins 5y ago
    As with most similar rants against the earlier days of MySQL, the majority of these points are based on old versions and don't reflect how things have been for almost a decade.
    - deathanatos 5y ago
      The question was what made me switch, which was all the crap MySQL does to a dev. That blog post is the best that I know of that captures the fractal of bad design that is MySQL. While, yes, it matches my understanding that some of those points are no longer valid, it doesn't match my understanding that most of the points are no longer valid. (E.g., just a few years ago, when I last used MySQL, I seem to remember that it still struggled w/ UTF-8, still struggled with the definition of what a "key" is, and still struggled with functional dependencies.)
      - derekperkins 5y ago
        Postgres is a great choice too, and for most intents and purposes, Postgres or MySQL is the correct default choice for a database, so I'm not trying to persuade you to switch back. Just clarifying that almost none of the points in that article are still valid, including UTF-8 handling. The author themselves put a disclaimer at the top of the article stating as much. Not quite sure what you mean by "definition of a key" or "struggled with functional dependencies", so I can't speak to those directly.

herodotus 5y ago

I am having trouble understanding what a "Serveless Database" is. When I do a search of the term, I get hype, not a definition. For example: "What is Serverless Database? Serverless Database is a prerequisite for Serverless Computing. These are specially designed for the workloads which are unpredictable and can change rapidly. What’s more? This allows you to pay only for the database resources you use, on a second-by-second basis. ..." I would really appreciate it if someone would give us a clear definition of this term.

pm90 5y ago
“Pay for only what you use” database.
- freen 5y ago
  Scales up and down automatically.
- mbesto 5y ago
  I'm curious about what kind of workloads people would be using a serverless DB for? If I understand it correctly, let's say my DB is only being used to process 1M transactions from 9am-1pm, I'm basically only paying for the load during that time, versus a managed DB where it's being paid to be on 24/7. With most serverless there is a penalty though - cold startup. So is it purely an economic play for esoteric DB workloads? If my DB is realistically going to be churning for 24/7 anyway, why would I ever use serverless DBs?
  - spelunker 5y ago
    Lower operational burden - if you're using a serverless db maintaining servers is one less thing to think about. Same with any infrastructure - you don't have to worry about orchestration, load balancing, authentication, etc.
    - mbesto 5y ago
      I mean, I can essentially do this with any PaaS DB, no? RDS, Azure SQL, Cosmos, etc.

Xorlev 5y ago

"built on top of the only open source database proven at hyper scale, Vitess." Vitess is a sharding layer. Furthermore, I'm sure Cassandra (for all it's flaws) would beg to differ, Netflix had a huge C* deployment. Is hyperscale larger than webscale? Hmm...

ksec 5y ago
>Is hyperscale larger than webscale? I am sure Youtube is larger than Netflix, by many order of magnitude.
- atombender 5y ago
  Note that YouTube no longer uses Vitess. It was migrated over to Spanner 2 years ago (maybe earlier).
  - derekperkins 5y ago
    FWIW, that migration wasn't because they chose to move to Spanner, they were required to.

sergiotapia 5y ago

Warning: One misconfiguration of your database and you will get hammered by billing. One guy forgot to put foreign keys and got a $20,000 bill.

sudhirj 5y ago
Indexes, rather. They charge by rows read, so if you don't add indexes you will (very quickly) read all the rows in your table on every query. That racks your bill really fast. The foreign key thing is because the author thought foreign keys add indexes, but here foreign keys are no-ops and don't do anything. Because it's so distributed there's no support for foreign keys.
samlambert 5y ago
Nonsense. It wasn't 20k and it was corrected.
- hyuuu 5y ago
  link?
  - manigandham 5y ago
    Here's the story: https://news.ycombinator.com/item?id=29132572 https://news.ycombinator.com/item?id=29132572

cyounkins 5y ago

I'm skeptical that YouTube would be using this for anything remotely significant given Google's strong propensity to only use internal technologies that they fully control.

qaq 5y ago
This was opensourced by google founders were @ google and wrote the thing
romero-jk 5y ago
They swithed to spanner.
danielrhodes 5y ago
I doubt YouTube is using the cloud service. If they're not 100% on Google's services by now, they still use Vitess. Vitess is the open source project PlanetScale manages which lets you horizontally scale MySQL databases.

jfbaro 5y ago

Congrats! Amazing offering. Is there any plan to support PostgreSQL as well?

fabian2k 5y ago

I still don't understand how you can work safely with this kind of pricing model. You pay $1.50 per 10 million rows inspected by the database. A relational database like MySQL has a query planner, so you're not fully in control over how exactly the database accesses your data. How many rows are read not only depends on your specific SQL query but also on the contents of the tables you read and the parameters supplied along with the query. A statistics update that triggers a bad query plan on a table with 10 million rows could cause a full table scan instead of retrieving a few rows using an index scan. Suddenly your query is a million times more expensive at $1.50 per query. Depending on how quickly and widely this scales, that could get very expensive very fast. 10 million rows is also not a lot for a relational database. I know my comparison now isn't fair as you get a lot more with the hosted version, but a quick and dirty experiment with Postgres and a small table of two ints and a text column with 10 million rows took ~1.5 seconds to query on my desktop, using only 1 CPU core. Translated into this pricing model that's something like $60 per minute.

siquick 5y ago
"Hey Infrastucture Finance Boss, we need a new database." "Thats cool, how much per month should we budget?" "$1.50 per 10 million rows inspected" "What? How much is that per month?" "TBC, and we won't know until we start using it" "RDS is $x per month so you're sticking with that"
jabo 5y ago
Their CEO mentioned that they’re working on an updated pricing model to address this issue, in another HN thread: https://news.ycombinator.com/item?id=29133026 https://news.ycombinator.com/item?id=29133026
mooreds 5y ago
See also https://briananglin.me/posts/spending-5k-to-learn-how-database-indexes-work/ https://briananglin.me/posts/spending-5k-to-learn-how-databa...
rustc 5y ago
Does MySQL (or PlanetScale) provide a way to input a query and get a lower/upper bound on the number of rows the query will "inspect" when run?

DeathArrow 5y ago

I only see buzzwords and hype in the post. Nothing technical, nothing much about why would make a good business sense to use their offering.

rubyn00bie 5y ago

PlanetScale is probably the only database vendor I like, and I don’t just like ‘em. I love ‘em. It works extremely well (Vitess) and scales easily using PlanetScales UI. The the thing that I like about ‘em so much is their great customer service… there have been a few hiccups but they’ve always been quick to remedy and above all honest about it. Vitess, for what it’s worth, is probably still under the radar for most people but is a really nice piece of technology (distributed database built on MySQL).

_ben_ 5y ago

Related to some of the comments here, we are building PolyScale.ai https://www.polyscale.ai/ https://www.polyscale.ai/ which is a global database cache. This solves regional latency and read query performance (concurrency), whilst maintaining the transactionality of the origin database.

ralusek 5y ago

Priced at more than a dollar per GB per month? Seems kind of nuts.

williamtwild 5y ago

I would love to try this out but having only worked with MSSQL and Postgres for any large datasets I wanted to check size limitations of MySql and found this from 2020: "In addition, a practical size limit on MySQL databases with shared hosting is: A database should not contain more than 1,000 tables; Each individual table should not exceed 1 GB in size or 20 million rows; The total size of all the tables in a database should not exceed 2 GB." This seems to be parroted elsewhere. 2GB is nothing. Is this accurate?

_9rq6 5y ago

I will bet my money that planetscale sales will not eclipse Amazon RDS.

compiotr 5y ago

This seems dodgy. Is planetscale behind Vitess? If you press the "Learn more about Vitess" button you get to a page that gives you the impression that it is the homepage of Vitess (and that it is their product). But the actual website of vitess (https://vitess.io https://vitess.io) mentions nothing of planetscale and the people behind it. Additionally, planetscale are displaying users of Vitess which makes it look like they are also users of planetscale.

shlomi-noach 5y ago
PlanetScale engineer and Vitess contributor here. As a brief history, Vitess was originally developed as an open source project in YouTube, and then handed over to CNCF. PlanetScale was created by authors of Vitess, and employs a team of Vitess developers and contributors. There are Vitess contributors outside PlanetScale, from companies such as Slack, Square, Nozzle, Pinterest and others (apologies to people/companies not mentioned). Just to explain how we work, if you ever come by to KubeCon, you're likely to find our Vitess booth. It is normally staffed by PlanetScale engineers. But in that booth we wear the Vitess hat, not the PlanetScale hat. We want to respect Vitess for being its own open source project, which we share with our community friends from different companies. Then again, as we employ many Vitess contributors, including the Vitess project leader Deepthi Sigireddi, we do pride in driving this OSS project from within PlanetScale. As we wear our PlanetScale hat, we give credit to the Vitess technology our product is based on.

max_ 5y ago

On what port does finger run on?