5 ms·
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 releas
by 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 agoSounds 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?
- samkottler 5y agoThe free tier is free forever.
- stronglikedan 5y ago> free forever or as long as a free tier exists ;-)
- onionisafruit 5y agoFree until you decide it isn't free anymore.
- deleted 5y ago[deleted]
- briandoll 5y agoThe free tier provides the stated usage levels at no cost, indefinitely. So if you were to stay under the quotas of data size, writes and reads, you don't pay at all. When you go over, you just pay for what you use. No servers, no pre-committed capacity, just simply pay for what you use.
- kall 5y agoDoes it mean you can write 10 million rows every month for free or does it mean you can write ten million rows, however many months that may take, and then pay for all use after that. The first one is how pricing generally works, but the page could be read as the second.
- lizztheblizz 5y agoThis is monthly. :)
- kall 5y agoOK, i think a little /mo on the pricing page wouldn‘t hurt.
- hodgesrm 5y ago> 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. I think you just described why developers liked MongoDB. It does not get a lot of love on HN, but having the DB schema map to your object model is very convenient.
- deleted 5y ago[deleted]
- tomc1985 5y agoAn ORM/migration system like ActiveRecord makes schema changes pretty simple.... hardly outside the domain of "mere mortal" engineer
- tomnipotent 5y agoIf you can use an ORM to run a migration on your database, then scaling is not your issue. But when you're dealing with terabytes of data or more with hundreds or thousands of concurrent queries short-and-long, you're going to have a bad time running a naïve tools migration scripts.