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

PlanetScale for Postgres is now GA

planetscale.com

Post reply on HN
Print view View original

181–190 of 196 posts

Re: PlanetScale for Postgres is now GA

#181

Post by hobofan »

sreekanth850 wrote: post #167
theanirudh wrote: post #49

Earlier quoted context omitted.

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.

No matter if its hosted on Azure GCP or AWS, latency is real. Cloud providers doesn't magically eliminates the Geography and phhysics. Private network don't eliminates latency magically. In general, Any small latency hike can potentially create performance bottlenecks for write operations in strong consistency DB like postgres or MySQL because each write operation go through a round trip from your server to remote pl…

> Hundreds of writes per second? Those extra milliseconds become a real bottleneck.

Of course it's nicer if the database can handle it, but if you are doing hundreds of sequential non-pipelined writes per second, there is a good chance that there is something wrong with your application logic.

Re: PlanetScale for Postgres is now GA

#182

Post by Imustaskforhelp »

samlambert wrote: post #137
Imustaskforhelp wrote: post #135

I really wish that the hobby tier hadn't gone but I also understand that planetscale is a b2b which imo I can respect yet still wish if I can try things in a hobby tier... I read the comments and it seems that in one of them they mention between supabase vs planetscale postgres that maybe they can use a project like supabase and then come to planetscale when their project grows enough to support that decision. How wo…

we've seen a number of Supabase -> PlanetScale migrations and it's been pretty simple with significant cost savings for the customer. The scale part of this is hard to answer because it really depends on the workload.

Congrats on the launch and thanks for responding!

I will try to create a product one day that will have a supabase -> planetscale migration one day to know that I have made it lol (jk)

have a nice day

Re: PlanetScale for Postgres is now GA

#185

Post by sreekanth850 »

hobofan wrote: post #181
sreekanth850 wrote: post #167

Earlier quoted context omitted.

No matter if its hosted on Azure GCP or AWS, latency is real. Cloud providers doesn't magically eliminates the Geography and phhysics. Private network don't eliminates latency magically. In general, Any small latency hike can potentially create performance bottlenecks for write operations in strong consistency DB like postgres or MySQL because each write operation go through a round trip from your server to remote pl…

> Hundreds of writes per second? Those extra milliseconds become a real bottleneck. Of course it's nicer if the database can handle it, but if you are doing hundreds of sequential non-pipelined writes per second, there is a good chance that there is something wrong with your application logic.

Not universal, there are systems that need high frequency, low latency, strong consistency, writes.

Re: PlanetScale for Postgres is now GA

#187

Post by tracker1 »

sgarland wrote: post #152
tracker1 wrote: post #126

Earlier quoted context omitted.

To me, every time I've touched MySQL, I've found an issue that just rubbed me the wrong way... starting with the fact that UTF8 isn't, and even across new major versions hasn't changed to an alias for the real UTF8. (VAR)BINARY does case sensitive collation based on db default, it shouldn't do any type of textual comparison even if the data is "text". You can't do foreign keys with ANSI quotes for the table/field nam…

> (VAR)BINARY Close [0]: (VAR)CHAR BINARY, which is its own type, uses the `_bin` collation for the column or table character set. (VAR)BINARY stores binary strings, and uses the `binary` character set and collation. In fairness, the amount of options, gotchas, and WTF involved with collations in any DB is mind-boggling. [0]: https://dev.mysql.com/doc/refman/8.4/en/binary-varbinary.htm...

I just know that I was sitting converted uuid and was getting collisions on different binary values. This was admittedly a couple decades ago though.

By converted it was legacy records where the original int value was injected to uuid format. This was then stored in a binary field as a primary key.

Re: PlanetScale for Postgres is now GA

#188

Post by ndriscoll »

mattrobenolt wrote: post #169
ndriscoll wrote: post #162

Earlier quoted context omitted.

Right, but as far as I know, the only instances that give you full bandwidth with NVMe drives are metal. Everything else gives you a proportional fraction based on VM size. So for most developers, yes it is hard to saturate an NVMe drive with e.g. 8-16 cores. Now how about the 100+ cores you actually need to rent to get that full bandwidth? I agree that EBS and the defaults RDS tries to push you into are awful for a…

Right, but I think you're kinda missing a lot of the tangible benefits here. This IMO is just reinforcing the idea of "unlimited" IOPS. You can't physically use the totality of IOPS available on the drives. Even if you can't saturate them, even with low CPU cores, latency is drastically better which is highly important for database performance. Having low latency is tangibly more important than throughput or number o…

How does "AWS limits IOPS. 'NVMe' drives are not as fast as the drives you're used to unless you rent the biggest possible servers" reinforce "unlimited" IOPS?

Yes there are benefits like lower latency, which is often measured in terms of qd1 IOPS.

Re: PlanetScale for Postgres is now GA

#189

Post by petergeoghegan »

jashmatthews wrote: post #171
petergeoghegan wrote: post #170

Earlier quoted context omitted.

> In a previous use case, when using postgres as a WAL-like append only store, I noticed that indexes would get massive. Then, after a while, they'd magically shrink. It's possible to recycle pages within indexes that have some churn (e.g., with workloads that use bulk range deletions). But it's not possible for indexes to shrink on their own, in a way that can be observed by monitoring the output of psql's "\di+" co…

Does vacuum not release free pages at the end of an index file in the same way it does for the heap?

No, it does not

Re: PlanetScale for Postgres is now GA

#190

Post by dangoodmanUT »

petergeoghegan wrote: post #170
dangoodmanUT wrote: post #165

Earlier quoted context omitted.

In a previous use case, when using postgres as a WAL-like append only store, I noticed that indexes would get massive. Then, after a while, they'd magically shrink. I had eventually switched to an API on top of Badger (golang KV), which afforded me an order of magnitude lower latency at ~30% of the resources IIRC. I'm sure there might have been some tuning I could have done to improve it. I've also heard similar beha…

> In a previous use case, when using postgres as a WAL-like append only store, I noticed that indexes would get massive. Then, after a while, they'd magically shrink. It's possible to recycle pages within indexes that have some churn (e.g., with workloads that use bulk range deletions). But it's not possible for indexes to shrink on their own, in a way that can be observed by monitoring the output of psql's "\di+" co…

I may not be remembering fully, maybe the indexes never shrunk but the tables did in size.

Is there no way to automatically clean up indexes then?

Post reply on HN