If you are on AWS anyway, I am curious why not just use Aurora Postgres?
PlanetScale for Postgres is now GA
41–50 of 196 posts
Re: PlanetScale for Postgres is now GA
#42I don't know why but I can almost never understand American commercial software websites. "what is PlanetScale".....blah, blah blah....WHOOOOSH! No more enlightened than before. Even for products I've worked on - I read the page and can't recognise the thing I'm working on from the description..... Postgres is involved somehow. I get that.
i'll take the opposite side. i was very impressed with their website. the very first line: > The world’s fastest and most scalable cloud databases the second line: > PlanetScale brings you the fastest databases available in the cloud. Both our Postgres and Vitess databases deliver exceptional speed and reliability, with Vitess adding ultra scalability through horizontal sharding. i know exactly what they do. zero flu…
How is this different than Aurora Postgres or RDS Postgres?
Re: PlanetScale for Postgres is now GA
#43We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty smooth. Post-migration we hit a few issues (turned out it wasn't an issue with PlanetScale), and the PlanetScale team jumped in immediately to help us out, even on a Saturday morning so support's been amazing. The Insights tab also surfaced missing indexes we added, which sped thin…
Would you mind sharing what you were migrating from, and what kind of issues you ran into?
Re: PlanetScale for Postgres is now GA
#44We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty smooth. Post-migration we hit a few issues (turned out it wasn't an issue with PlanetScale), and the PlanetScale team jumped in immediately to help us out, even on a Saturday morning so support's been amazing. The Insights tab also surfaced missing indexes we added, which sped thin…
Care to elaborate what kind of issues? Looking into migrating as well.
Re: PlanetScale for Postgres is now GA
#45We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty smooth. Post-migration we hit a few issues (turned out it wasn't an issue with PlanetScale), and the PlanetScale team jumped in immediately to help us out, even on a Saturday morning so support's been amazing. The Insights tab also surfaced missing indexes we added, which sped thin…
Out of curiosity: how do you connect your databases to external services that are consuming these data? In places I do similar work, databases are usually in the same private network as the instances which are reading and writing data to them. If you put them somewhere on the internet, apart from security, doesn't it affect latency?
PlanetScale runs in AWS/GCP, so not really “somewhere on the internet” if your workload is already there.
Re: PlanetScale for Postgres is now GA
#46The way I understood NVMe drives to work on Google Cloud is that they are ephemeral and your data will be lost if the vm reboots. How do they work in this case?
Re: PlanetScale for Postgres is now GA
#47The way I understood NVMe drives to work on Google Cloud is that they are ephemeral and your data will be lost if the vm reboots. How do they work in this case?
can't speak to GCP specifically but usually the issue is they are host-attached and can't be migrated, so need to be wiped on VM termination or migration -- that's when you lose data.
Reboots typically don't otherwise do anything special unless they also trigger a host migration. GCP live migration has some mention of support though
GCP mentions data persists across reboots here https://cloud.google.com/compute/docs/disks/local-ssd#data_p...
note that stop/terminate via cloud APIs usually releases host capacity for other customers and would trigger data wipe, a guest initiated reboot typically will not.
Re: PlanetScale for Postgres is now GA
#48We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty smooth. Post-migration we hit a few issues (turned out it wasn't an issue with PlanetScale), and the PlanetScale team jumped in immediately to help us out, even on a Saturday morning so support's been amazing. The Insights tab also surfaced missing indexes we added, which sped thin…
Care to elaborate what kind of issues? Looking into migrating as well.
The issues weren't PlanetScale related. We use Hasura and when we did the cutover, we connected to the DB via PGBouncer and some features don't work right. Started seeing a lot of errors so paged them and they helped out. We were connecting directly to PG previously but when we cutover we missed that.
Re: PlanetScale for Postgres is now GA
#49We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty smooth. Post-migration we hit a few issues (turned out it wasn't an issue with PlanetScale), and the PlanetScale team jumped in immediately to help us out, even on a Saturday morning so support's been amazing. The Insights tab also surfaced missing indexes we added, which sped thin…
Out of curiosity: how do you connect your databases to external services that are consuming these data? In places I do similar work, databases are usually in the same private network as the instances which are reading and writing data to them. If you put them somewhere on the internet, apart from security, doesn't it affect latency?
Their databases are hosted on AWS and GCP so latency isn't much of an issue. They also have AWS Private Link and if configured it won't go over the internet.
Re: PlanetScale for Postgres is now GA
#50The way I understood NVMe drives to work on Google Cloud is that they are ephemeral and your data will be lost if the vm reboots. How do they work in this case?
We deal with this by always running 3 nodes in a cluster, one per AZ, and strong backup/restore processes.
So yes, the data per-node is ephemeral, but it is redundant and durable for the whole cluster.