In short, it is a great solution for a couple of reasons:
- It is clean and simple. You will find what you want on their dashboard easily and unless you want to orchestrate multiple DBs or any hackery special scaling, this gives you a simple great solution. You get a basic understable monitoring and querying tool, too.
- Fast setup. Really you register and get going in a few clicks.
- PRICE. Oh my god… Search around for any database providers and i don’t know if you can find a legit managed MySQL server for less. Their free tier gets you 10million row writes and 1BILLION (with a ‘B’) row reads per month. (These row reads include every row that your query has to read to find the thing that it’s searching/filtering for. But still..) This is a great. And you can track it actively on your dashboard how much you have already used. Just to give a base, I tested my API back and forth on the first day of usage and it took 1k row reads total. That means I can do this 1 million more times. In 1 month. That’s just nice. And IF you happen to go crazy and step over the limit, you will be chareged 1-1.5$ for every next million. 10k concurrent connections allowed. 10GB storage in free plan. Should be good. Read more here.
There are some drawbacks, but none of them is meaningful:
- You are not allowed to use FOREIGN KEY constraint in your queries. This has a performance reasons, (pretty interesting details if you read after it by the way,) but the point is that you can’t use them. Nor should your ORM. But simply pointing row IDs at each other is no problem, really, with even the most basic SQL skills. It’s just somewhat unusal. But they well reasoned it. And it’s OK with me. ✔
- No Postgres engine, or any other database engine. Planet scale only runs MySQL. Which is okay for me. Really widely supported, so you can get a lot of help when planning to scale up or just migrate. No true drawback really. ✔
- Low configurability. If you compare it to Amazons AWS RDS for example, you’ll see that you don’t have a million ways to set things up here, at least not in the free tier. Custom backup policies, server or cahing configs, etc. But I guess that is the point of ‘maganed’ DB hosting. And here is the thing: IF you happen to go viral with your application and suddenly face wild traffic, you will still survive those busy weeks easily only for a few dollars of upgrade here, and you will have a chance to prepare a pretty safe migration to any other larger plan or provider.
When developing an application, making sure to be able to react to changes efficiently is the key for scalability. And not making sure that a single tool will solve everything. Planet scale free tier will carry you for fragment bucks far enough and will hold you when time comes until you involve a more expensive, more complex DB solution. Until then, don’t pay more. ✔
And to add comparison, as it is mentioned previously, I started my project with an AWS RDS on a Postgres database, and without any heavy usage really in 13 days I piled up 13$ of billable usage. Which is not crazy but if you think about it it is probably not necessary for an app that has just started.
By the way, this stuff is hooked up with AWS database infrastructure under the hood, so you can rest easy that it has a solid foundation.
All in all, looking like a great app starter DB soution and practically free until you blow up and go viral.