PgDog is funded and coming to a database near you

Good thing we support HA as well: https://docs.pgdog.dev/features/load-balancer/

Load balancer with health checks and failover, works out of the box. :) Battle-tested at this point too, so could be worth a look.

Patroni 1.0 was released in 2016, i.e ~10 years ago.

https://github.com/patroni/patroni

Have you looked into things like CloudnativePG? https://cloudnative-pg.io/

Patroni serves this niche pretty well at this point.

Have you tried cnpg? Worked amazingly well for my usecases

~1600 TPS is not 'high scale'.

Yeah good callout. We'll add rendezvous soon enough. Until then, being compatible with Postgres partitions has been advantageous -- while we build everything out, people were able to migrate to PgDog for the query routing layer while doing the resharding in Postgres.

Adding a sharding function in our architecture is relatively straightforward. We also support plugins which can control the flow (and direction) for queries, so our users can add their own (and they do!).

Is 100k order per minute a lot? Even a single Postgres instance should serve that fine?

why did we switch to per minute? A modern quality enterprise SSD can do 35K +/- legit fsyncs per second.

I’ve always found Instacart to be extremely slow with giant latencies. Of course I don’t know if that’s due to Postgres or some other design flaw…

Legends

> 8 smaller boxes handling ~500GB each and then one medium box for the proxy?

That's exactly right. Get in touch (lev@pgdog.dev), happy to help or at the very least tell you what current works (or doesn't) so you know what your options are.

That's the idea of sharding. If you read the pgdog docs, you'll notice you need to tell it which shard server to route your request to - it doesn't just magically work. It's still providing value by reusing connections, which are particularly expensive in postgres.

Because it's not magic, you do still have to know what's going on under the hood, e.g. no cross-shard transactions.

I'd see if my application can benefit from read replicas before doing sharding, because sharding is difficult (if you care about data consistency). With replicas, each replica does have a full copy of the data and you only write to the master - you have to decide which transactions are suitable for running against replicas, which can lag slightly behind realtime. E.g. reading data to build a webpage is probably safe to do from a replica - any read-modify-write is not.

We use logical replication and a pause / swap in pgbouncer for ~5s of paused (but not failed) writes.

This is for DBs that are ~1-1.5TB but doesnt have a huge amount of churn/qps

Effectively what is described here https://www.pgedge.com/blog/always-online-or-bust-zero-downt...

Logical replication is how this is typically done. If you have some infra-as-code setup, you create a new cluster with identical settings except for the major version, import the schema, start copying data from a read-replica running the old version, stop accepting writes from the old version (downtime starts), sync the sequence numbers, and point your services to the new cluster (downtime ends).

If you use something like CloudNativePG they automate parts of the process with cli tools and declarative syntax. Otherwise you take the time to figure it out by hand. It might sound complicated, but just practice on your staging DB, and if all goes well you do the same procedure in prod.

Edit: Apparently Postgres 19 has a patch for one-shot logical replication of sequences! https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...

Seconded. Coming from MySQL this is a huge regression that makes Postgres look like something from the 80s. I still wonder why this isn't seen as the absolutely highest priority.

It's weird that PostgreSQL still doesn't have a proper, open source, general multi-master implementation.

At this point i wonder if i'll ever see that.

Logical replication solves this. You roll the cluster, downtime is minimal. like 60s maybe.

Don't forget the original PgBouncer. Hard to setup, but with the help of AI these days it's easier to configure.

The pg_hint_plan extension isn't in core, yet is pretty competent when you need to override planner.

If you think 20TB "isn't that big" I want to know what size of DBs you're working with 0_0

For a vast majority of use cases 20TB is positively enormous.

If your working set is 20 TB, then it's pretty big. Each database has its own mix of hot/cold data, so it's impossible to compare without more information. A better measure might be IOPS. RDS has fairly low maximum IOPS unless you spend a lot more for provisioned IOPS or use Aurora.

You are correct. As a point of comparison: almost ten years ago at Segment we had a single Aurora PostgreSQL instance with ~50T of data, it was used to index potential identity data in a much larger corpus of files stored in S3.

Two big ones:

1. Control plane to manage multi-node deployments; "works out of the box" experience to make PgDog easy to deploy and use

2. QoS (quality of service): automatically block bad queries from taking down the database

Last but not least, you get SLA-backed support from us (up to P0).

New features are broken down into two categories:

1. Sharding / running Postgres at scale: always open source.

2. Infra management / making it easy to run PgDog at scale: enterprise.

Old benchmark, but still good: https://pgdog.dev/blog/pgbouncer-vs-pgdog

Awesome, glad it worked!

Thanks!

Not the place and not the time, but we are building an enterprise edition that "just works" out of the box. Not saying that the open source experience cannot be better - it always can and we'll keep improving. What you've experienced is definitely a known issue with our specific implementation of passthrough auth. Scram made things a bit harder, since we can't validate user's passwords at login time anymore (that's what makes scram secure fwiw).

We'll get there.

Happy to chat about this, but we use the AWS secrets manager flowing into External Secrets Operator to generate a pgdog_users.toml. We then kick off a workflow to refresh things, but our rate of change here is much smaller than a super dynamic multi-tenant system.

You could also build a watcher side car that watches for changes of the pgdog_users.toml and have pgdog refresh itself then too with this combination. We thought about that but prefer to control the reloads for our needs.

We successfully did this with pgdog at $JOB using our own "controller" -- the same service that handles deploying new instances of our application (instancing an argoCD Application that fires Crossplane DB creation, making new Deployments of bricks, etc) will also, at the end of that process, scan the cluster for Database CRDs, use those to generate a new pgdog.toml + users.toml, update the Secrets in the cluster, enable maintenance mode on all pgdog pods, do a live config reload on each of them, then disable maintenance mode (this is to make the change atomic between all the pgdog instances). Downtime there is about 2-3 seconds and all it does is make new SQL requests from existing clients wait, it doesn't break the connection or anything.

OLAP means different things to different people. For us, it's just making sure your admin dashboard keeps working basically:

  SELECT tenant_id, COUNT(clicks)
  FROM users
  GROUP BY tenant_id
  ORDER BY 2 DESC
  LIMIT 25;

Performance is a side effect - definitely needed and we'll do everything we can, but we are not competing with ClickHouse or Snowflake - just trying to make sharded Postgres work with your app.

Tomas Vondra, a major Postgres contributor recently revived a thread on using Bloom filters - https://www.postgresql.org/message-id/flat/5cd8c20c-14b5-4b0...

So there is more core work happening on support OLAP but I do think it will take some time.

In the meantime, I think we have all the pieces (storage, query engine, table format) to set up a true OLAP. For instance, I created https://github.com/viggy28/streambed to pressure test this idea.

Re OLAP: It's probably ~good enough~ for a lean team that's trying to keep the tech stack standard and/or doesn't have a dedicated data person to take advantage of a columnar store.

There's multiple solutions coming up in this space:

1. Neki as you mentioned 2. PgDog 3. Multigres, headed by original creator of Vitesse

Thanks! Glad we made it relatively easy to migrate!

#1 is a problem with the client's code, I don't know any easy workaround. Usually a long-running transaction means you're accidentally waiting on stuff like RPCs in the middle, or maybe doing something that doesn't really need to be in a xact.

#2, shouldn't the client<->PgBouncer connections stay open?

#3 is why I just use client-side pools instead of PgBouncer, but that gets annoying when you have a replicated service so you have to think about the sum of connections across all pools, so I get why people use PgBouncer.

SQLA async is a bit of a struggle with pgbouncer.

I had to disable application pooling as it was causing read only transactions I could couldnt pin down the cause.

Not quite. The performance gain is to bring those features to Postgres!

Edit:

Performance gains are from having the ability to load balance reads (horizontal scaling for read queries) and scale out writes (with sharding). Once instance bottleneck in Postgres has many faces:

1. Behind schedule vacuums because of too many dead tuples (too many writes)

2. The WALWriter is single-threaded and IO-bound - Postgres can only do about 200-300MB/sec in writes per instance (real prod numbers on EC2 with NVMes and ZFS, basically best case scenario).

3. Bulkheading: single primary is a single point of failure. With 12 primaries, if one fails, 91% of your customers don't notice.

The list goes on. Rust is just a side effect. We love it because it's fast and correct - the perfect match for a database product.

Presumably enterprise sales will bring in revenue on its own

[dead]

We should add it to brew/apt/etc for sure. Also, we could add it to crates.io so you could do something like `cargo install pgdog`. Distribution, distribution, distribution.

In addition - the docker compose example doesn't set up any data volumes for the postgres instances - that might be considered a bug?

Then again, sharding on a single host probably isn't very useful anyway - but it might work with docker in swarm mode?

[dead]

Like what? I've never had problems related to PgBouncer, but apparently we have different use cases. I'd love to hear where the rough edges are so I can avoid them, or at least plan for them in advance.

This is not an extension, it's a proxy! Very different. You can deploy it anywhere already without having to wait for upstreaming or your cloud provider adding support for it. It's one of the two reasons why we built it this way, the other being performance (it's much faster to do this in the proxy than inside Postgres).

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.

We do, just buried deep in our blog: https://pgdog.dev/blog/pgdog-vs-citus

The same old processes vs. threads debate, plus having the ability to scale the coordinator past a single machine. So, if you're OLTP, definitely consider PgDog. OLAP - Citus still wins because of its advanced query engine. We'll get there.

> all drivers natively support secondary/primary writes/reads and topological changes.

Expanding on that a bit, mongo drivers even have a shared specification of the state machine for monitoring topology changes[1] and algorithm for selecting the server to send an operation to[2] (along with various declarative test cases that the drivers use to validate them alongside the specs in the repo). I think people sometimes underestimate how important the client-side work is to this sort of experience; for all of the faults mongo has had over the years, the amount of investment that they put into the client libraries is something I've never seen anywhere else (although having spent several years working on some of these libraries, my take is likely very biased).

[1]: https://github.com/mongodb/specifications/blob/master/source... [2]: https://github.com/mongodb/specifications/blob/master/source...

once mongo rewrote their engine - it's performant, scales & easy to run. seems a lot of devs got burnt by the early issues don't consider it all together.

its probably the easiest database to run at scale. run & forget. you just have to do a little more work on the data modeling part before you write your application i.e consider your query patterns.

The creator of pgdog is also the creator of pgcat, so I think they probably don't need to do this.

> you should own that layer yourself inside of your infrastructure

Unless you have millions of users, you don't really need this. It would be nice to have but its not a pressing need. So why invest into developing something that you only need once you are at massive scale? At this point you might as well switch away from Postgres because you'll surely have the manpower to do it.

Even with a proxy like PgDog the Postgres sharding story isn't solved. Resharding with logical replication is unlikely to work with databases which are already TBs in size. I never got it to catch up, I had to sync data at the filesystem level which is terrible. Tools like pg_repack also fall apart at scale.

For those that get to a point where a sharding proxy is required, switching databases is a very appealing solution.

And for those that are almost there, application side sharding is more flexible than building a query routing proxy.

The founder is the author of both...

Yup. We support schema-based sharding: https://docs.pgdog.dev/configuration/pgdog.toml/sharded_sche...

Getting there! Cross-shard writes do because of 2pc. Reads are eventually consistent.

Given that they implement connection pooling and sharding, I'm going to say "not at all".

You _could_ make that ACID, but it's not going to be faster than a single machine.

Thanks! Yup...to be expected. If you know, you know, and have the scars to prove it :)

I didn't realize there are _any_ managed providers of PgDog out there...do tell!

Not yet, but actively working on this as we speak.

Depends. Only pooling, very little. Load balancing/sharding needs to parse queries, so a bit more. Could go up to a GB per pod, sometimes more if you have a lot of unique SQL queries (unique by text, not by parameters). We cache query ASTs to avoid parsing them on each request - that's the bulk of memory usage.

I am odd, yes. I also care deeply about supply chain security and focused on it when I led the crates.io team as well as during my time at the Rust Foundation. You can rest assured that my occasional shitposts are not opening an attack avenue for your supply chain.

- Sage

I see you met Sage, our newest founding engineer :) If you're not having fun at your job...

In all seriousness, we review every single line of code that goes in and only people who work for PgDog Inc are allowed to merge.

Crap! Missed opportunity.

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.

Each connection is a process on the server, that takes up both CPU and RAM, it will run out.

This solves the thousands of clients case for read in a way that is transparent to the clients.

Yes it's required at large scale, especially if you want to distribute reads or shard to a particular geographical area.

Always is. Marketing is not our strong suit (only engineers here). We'll get better at it.

How are 3 developers going to sell that to any company? Procurement will have a field day.

They are not just some random 3 have decades of real db experience behind them. They also just got funded which gives them the ability to expand and stay longer in the game.

[dead]

No

PgDog is GalaxyScale </joke>

Dynamo definitely scales better than anything else at the tradeoff of not guaranteeing durability in the case of enough node failures and (like most distributed databases) not allowing interaction between different pieces of data.