Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PlanetScale – Database for Developers

planetscale.com

Post reply on HN
Print view View original

81–90 of 135 posts

Re: PlanetScale – Database for Developers

#81

Post by e12e »

vira28 wrote: post #25

Wondering will we see something like this for Postgres? I like the cool things but I can’t migrate to MySQL just because of this.

Ed: obviously this does not solve the bigger service of providing "magic" scale up/down, though.

It looks like the "branching schema" is essentially:

CREATE DATABASE branch_name WITH TEMPLATE main;

I might actually have to try this - I hadn't really thought template dbs would be all that useful in pg - but this branch and test för dev use-case is interesting.

Then there's COPY (for data) and rename to "promote" a branch with data (one would probably want to run DDL on main db though:

ALTER DATABASE branch_name RENAME TO main; -- would have to move old main out of the way first - but might be possible in same transaction?

Re: PlanetScale – Database for Developers

#82

Post by anarazel »

qeternity wrote: post #78
motives wrote: post #69

Earlier quoted context omitted.

Indeed I was referring to yugabyte, apologies for the clumsy phrasing, I havent used crdb but I guess it is a postgres frontend layered on a KV store instead of a document store?

As opposed to? Postgres is “just” a Postgres front end on top of a kv store.

I don't think that's really true. Which part of postgres would you describe as a KV store, compared to what cockroach does with RocksDB?

Re: PlanetScale – Database for Developers

#83

Post by dastbe »

What do yall see as the next devx improvements beyond branching and no-fear schema migrations? I'd be really interested in how you might apply the workflows you're defining towards (IMO) bigger problems like data migration and backfills.

Re: PlanetScale – Database for Developers

#84

Post by lizztheblizz »

dastbe wrote: post #83

What do yall see as the next devx improvements beyond branching and no-fear schema migrations? I'd be really interested in how you might apply the workflows you're defining towards (IMO) bigger problems like data migration and backfills.

Already on it. :) https://vitess.io/docs/reference/vreplication/vreplication/

Re: PlanetScale – Database for Developers

#85

Post by ransom1538 »

eurasiantiger wrote: post #80
Rauchg wrote: post #6

From the Vercel point of view, this promises to answer one of the most frequent, interesting, and technically challenging questions since we first launched our "immutable deploys". That is: how can I pair a brand new frontend preview deploy, with a serverless database with the specific schema my new feature needs? This technology makes the whole serverless stack feel complete.

It doesn’t solve the N+1 queries problem in a generic way. That is a major hurdle in scaling complexity-wise , which in turn is often deeply coupled with business realities. More to the point, it probably cannot solve it efficiently at all, since it is not a graph database and thus cannot be paired with a generic GraphQL resolver (would generate join queries instead of lookups across edges) and a stack of generated s…

"It doesn’t solve the N+1 queries problem in a generic way."

IMHO, this isn't trying to solve people looping queries. The fastest way to solve this is to not loop queries.

This solves auto-sharding (well vitness did). See slack architects comment below.

Re: PlanetScale – Database for Developers

#86

Post by lizztheblizz »

2color wrote: post #27

This is wonderful. I've been developing with relational databases for 12 years and couldn't be more excited about this. Scaling down to 0 opens up a world of opportunities when it comes to team development workflows. The idea of quick environments per pull request is within reach. Not to mention that it scales with you. The one thing I'm curious about is how it compares with CockroachDB

12+ years of massive scale production use for Vitess and 26+ years of hardening for MySQL and InnoDB. PlanetScale adds some (imho) great features on top of that, but it's standing on the shoulders of giants that have proven themselves over and over.

... Also, I guess it's MySQL-compatible rather than Postgres-compatible? :)

Re: PlanetScale – Database for Developers

#87

Post by lizztheblizz »

golondon wrote: post #68
lizztheblizz wrote: post #67

Earlier quoted context omitted.

That is exactly what we _do_ support. Our team includes the original developer of gh-ost for MySQL, which has been built to execute these kinds of massive changes at scale at GitHub. We've integrated it tightly with Vitess. Once your branch is ready to be merged with production, it executes that change in a completely non-blocking way.

Ok, but most of the time you would like to test that change on a copy or almost up to date replica, to see measure things like how long it does take. If you were copying the data, with things like PII filtering, to the branch development database and allow folks to test it there it would be even more amazing. Great start tho!

Give it a shot, because the current implementation specifically side steps the need for that full copy, and does let you test functionally against fully up-to-date production data.

You're right, though, it doesn't cover all of those uses cases. Luckily, Vitess does offer most of that out of the box already. Just need them exposed through the PlanetScale UI. :)

Re: PlanetScale – Database for Developers

#88

Post by Jarwain »

lizztheblizz wrote: post #75
olivierlacan wrote: post #65

The boulder-sized caveat for all this admittedly really neat stuff being: > PlanetScale's Non-Blocking Schema Changes' workflow doesn't support FOREIGN KEYs in users' databases. > PlanetScale determined that the production safety that Non-Blocking Schema Changes provide are worth this technical tradeoff. Learn more. https://docs.planetscale.com/concepts/nonblocking-schema-cha...

To be clear, this is not a Vitess/PlanetScale-specific opinion or choice. Foreign key constraints are a bit of a controversial topic in large-scale MySQL environments in general, which is the greater context in which this design decision was made by the Vitess team. PlanetScale's (and Vitess') non-blocking schema changes rely on open source tools for MySQL like pt-online-schema-change and gh-ost, which are widely use…

Do you know if foreign keys tend to be a problem on postgresql as well?

Re: PlanetScale – Database for Developers

#89

Post by dkarras »

And if your company fails my company fails with it? How would I ever move out of this?

Very impressive tech! But the upside is not worth the vendor risk for me.

Edit: or maybe this is not an issue at all - but the website copy does not make it clear, so take it as a suggestion please.

Re: PlanetScale – Database for Developers

#90

Post by dcherman »

kmavm wrote: post #45
motives wrote: post #44

Earlier quoted context omitted.

As I understand it, Vitess is basically a really powerful sharding system, which goes a step further than typical sharding solutions by basically making the shards one or more unique databases. In the case of someone like slack, because your tenant (e.g your company slack), is completely isolated from other tenants, you can treat that basically as its own database, and have a master for just that DB, allowing much be…

I was Chief Architect at Slack from 2016 to 2020, and was privileged to work with the engineers who were doing the work of migrating to Vitess in that timeframe. The assumption that tenants are perfectly isolated is actually the original sin of early Slack infrastructure that we adopted Vitess to migrate away from. From some earlier features in the Enterprise product (which joins lots of "little Slacks" into a corpor…

Random aside, were you at KubeCon a couple years ago chatting with Sugu at the whole conference party in San Diegi? If so, hi! I was crazy out of my depth, but listening to folks that know this stuff better than I ever will was one of the highlights of that conference
Post reply on HN