Live data from Hacker News

PlanetScale is now generally available

planetscale.com

101–110 of 139 posts

Re: PlanetScale is now generally available

#101

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-b…

DyanmoDB is truly serverless, they give you a http endpoint and that's it, you don't have to deal with database connections.

> ...deal with database connections.

I think, you mean connection pooling?

Amazon Aurora has http endpoint too, for its serverless offering.

I use S3 with duckdb files in 'em as a sharded OLAP database of sorts. No transactions or joins though, but my workload is write once, ready plenty. Hoping Databricks' serverless SQL is a good fit once it emerges out of beta.

Re: PlanetScale is now generally available

#103
post #88

Earlier quoted context omitted.

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 is…

> 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 incomin…

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

Re: PlanetScale is now generally available

#104

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…

Errors get expensive, but DDoS attacks could literally kill your business.

Re: PlanetScale is now generally available

#105
post #19

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-b…

There is no clear definition with universal agreement. It's a hype-y term applied with... varying levels of rigor. However, roughly speaking, "serverless" rolls together 3 features: 1. Fine grained pay-per-use (e.g. pay for a query by the number of rows scanned) 2. The pricing dial goes down to zero when usage is small enough. 3. You generally don't control VM/instance-level scaling but something closer to the abstra…

This is good info thanks. I have some cloud Infra experience so I am interesting in knowing how does they keep the data stored and remove the "query" servers when not in use.

Possibly some kind of EBS equivalent storage which is attached to the VM when it's booted up? I wonder that creates more failures at the cost of operational simplicity?

Re: PlanetScale is now generally available

#106
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) 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.

Re: PlanetScale is now generally available

#107

Earlier quoted context omitted.

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.

>*might vary depending on the table statistics...

This is a good point. You can control for some variables (like query parameters), via testing, however as table statistics change, so does query planning. For instance, your table gets bigger (or smaller) and MySQL chooses a different query plan.

There's almost no way to completely predict pricing in all but the simplest of apps. Overall, the pricing model seems untenable.

Re: PlanetScale is now generally available

#108

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…

I've tried Aurora and Firebase. I think PlanetScale wins on 2 areas at 2 different scales: branching when you're small, and connections when you're large. With branching it's a feature where every dev can run a command and get their own database version to mess with. They can submit a pull request and as the tech lead I can check it and publish it to prod. Or integrate it with our CI. On connections, it is interestin…

Does the branching system have an anonymization layer? At pretty much every company that is beyond "tiny startup with < 10 employees" you really don't want to give every developer read access to all customer data.

Re: PlanetScale is now generally available

#109

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-b…

Serverless means infrastructure as code and you're in as much control of the system as they want, which can be near 0, and they'll tell you it's for your benefit to have no control. Why use a bank vault when you can have a crypto wallet.

Re: PlanetScale is now generally available

#110

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.

What made you switch to Postgres?

https://grimoire.ca/mysql/choose-something-else/
Post reply on HN