Live data from Hacker News

PgDog is funded and coming to a database near you

pgdog.dev

231–240 of 275 posts

Re: PgDog is funded and coming to a database near you

#231
post #50

Earlier quoted context omitted.

They have funding. That's what it will be for. I wish them well and appreciate that people are still doing FOSS. As long as they don't get undercut by the equivalent of AWS https://aws.amazon.com/rds/proxy/ which is a managed pgbouncer.

The issue is if the DB layer fails your product is going to completely stop working. You’d need a ton of faith in these 3 people. Feels more like it would work better inside of a bigger organization. The QA tester in me is kinda risk adverse.

The source code is available for inspection as is the biographies of the people involved.

They rely on the libraries that are part of Postgres itself to ensure they are parsing the SQL etc "correctly" (where "correct" means "the same as Postgres itself).

Bigger organizations do not necessarily mean higher quality.

What bigger organization is testing PostgreSQL itself?

What are the relative quality measurements of Postgres vs MariaDB vs Oracle vs SQL Server?

Re: PgDog is funded and coming to a database near you

#232

I've seen a couple of these "distributed" postgres extensions. My question is, has any of them been talked about being upstreamed to postgres itself? Or, adding a custom built in feature to postgres itself?

It doesn't actually distribute postgres. It lets you use one connection to talk to multiple postgres databases by switching between them and if you're very careful you can sort of see it like a single database, ht it's not really.

Re: PgDog is funded and coming to a database near you

#233
post #129

I us pg. not that I know much about database internals, besides the 'b-tree' stuff we learned in college. I don't know how the pg scaling story gets fixed unless certain things are rewritten. that's my fear of going all in pg. mysql has vitess etc & even upgrades are easier. though pg is more extensible.

Any strongly consistent database is going to be limited by a single machine's throughput. That's just what you trade for strong consistency. You can shard it yourself but then the DBMS isn't giving you consistency so you'd better be very careful. You can use a tool like PgDog to aid with sharding but it's not doing magic, you still have to be aware how it works and the limitations of sharding.

However 95% of projects are going to be fine with a normal single-machine database and another 4% are going to be well served by upgrading the hell out of that machine. Only the absolute busiest projects actually need a distributed database and you can cross that bridge when you actually get to it.

They say Amazon processes 20k orders per second. That seems not unachievable for postgres with fast SSDs and careful query optimization, though they don't choose do it that way. You're not Amazon, you have at most 20 orders per second and that's nothing.

Re: PgDog is funded and coming to a database near you

#234
post #133

Earlier quoted context omitted.

I've extensively used Dynamo (internally at Amazon and externally) and even founded a DB startup with it at it's core. Boiling down scalability of Postgres vs Dynamo as it's written in blog is a bit terse. Dynamo scales writes horizontally with the keyspace, forever. Postgres simply can't, and no number of layers between the machines and the developer changes that. Sharding, pooling, Citus are all layered on top of a…

Dynamo DB isn’t even good at being a KV store. Almost every time we have to also back it with S3 because of size limitations.

If you know your access patterns really well and they are non-relational, then you can design the best possible tables for dyanmoDB. In such a case DynamoDB works and scales amazingly. Ofc, you cannot do multi table relationships etc shoehorning a relational scheme onto DynamoDB does not work.

Re: PgDog is funded and coming to a database near you

#236
I have mentioned this before, but here it goes again:

I'm really happy that there's more options for Postgres sharding and I applaud Pgdog and the team's efforts and energy.

Having said that, this makes it a no-go for me:

> shard_number = hash(data) % num_shards

https://docs.pgdog.dev/features/sharding/basics/#terminology

Most sharding solutions distribute the hash value over linear ranges, that then split across "virtual shards", that are then placed on the physical shards or worker. This allows for shard replacement when needed. For example, Citus works this way, and even adds convenience functions for shard migration (using logical migration) in an automated way. That's all I'd need.

Operationally, it's worlds apart. With modulo distribution the only way to replace data is to reshard everything --something you don't want to do however fast the operation may be.

Re: PgDog is funded and coming to a database near you

#237
> we don’t think you would use anything else.

This just seems like fanboyism to me. At the very least, you need to qualify what scenarios you think it's useful for.

I don't doubt that Postgres is good for all the projects you've ever worked on. Generalizing from that, though, is hubristic.

Re: PgDog is funded and coming to a database near you

#239

> With $5.5M from Basis Set, YC, Pioneer Fund and other great investors, we have years of runway, This is years of product development with a three person team. If Enterprise sales and support are a big part of your business plan it will suck up a lot more than that.

[dead]
Post reply on HN