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.
PlanetScale is now generally available
61–70 of 139 posts
Re: PlanetScale is now generally available
#62I 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-b…
Nothing to manage, and it should scale to zero cost when not in use.
Re: PlanetScale is now generally available
#63Warning: 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.
Nonsense. It wasn't 20k and it was corrected.
Re: PlanetScale is now generally available
#64I 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…
Their FAQ [1] clarifies this somewhat:
> Every time a query retrieves a row from the database, it is counted as a row read. Every time a row is written to the database, it is counted as a row written.
[1] https://planetscale.com/pricing (FAQ at bottom of the page)
Re: PlanetScale is now generally available
#65I 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-b…
"Serverless Database"
It's just a database service. You don't run the servers. You pay someone to do that and you just connect to it and use it and someone else maintains the servers, storage, scaling, backups, patches, etc., according to some SLA and other terms.
There are indeed servers somewhere. "Serverless" is misleading cloud speak for the otherwise easily understood concept of a service.
Re: PlanetScale is now generally available
#66PlanetScale 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).
Re: PlanetScale is now generally available
#67I 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…
Their FAQ [1] clarifies this somewhat: > Every time a query retrieves a row from the database, it is counted as a row read. Every time a row is written to the database, it is counted as a row written. [1] https://planetscale.com/pricing (FAQ at bottom of the page)
> Reads: Retrieving or inspecting rows during a query or mutation of any kind to your PlanetScale databases
That's what the detailed pricing page says, which is somewhat different. The pricing is actually per row inspected, not per row returned to the client. So in aggregations you'd pay for every single row you aggregate. So I'd argue that the FAQ is actually misleading.
Re: PlanetScale is now generally available
#68I 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…
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?
MySQL’s “explain ” does exactly what you described and better. It shows indexes used, exact number of rows scanned etc. It’s the first thing I do when I suspect a query taking time. It’s a pity that not too many backend engineers know about it now a days.
Re: PlanetScale is now generally available
#69I 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…
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?
Yes, through `EXPLAIN`.
Re: PlanetScale is now generally available
#70Earlier quoted context omitted.
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?
MySQL’s “explain ” does exactly what you described and better. It shows indexes used, exact number of rows scanned etc. It’s the first thing I do when I suspect a query taking time. It’s a pity that not too many backend engineers know about it now a days.
That only explains the particular query plan chosen for the query at that time. This might vary depending on the table statistics, query parameter or moon phase if you're unlucky. It is a very important tool, but doesn't solve the problem here that in the end the database is in control and decides how many rows to read, not you.