[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-73300":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":25,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":32,"readmeContent":33,"aiSummary":34,"trendingCount":16,"starSnapshotCount":16,"syncStatus":35,"lastSyncTime":36,"discoverSource":37},73300,"pgdog","pgdogdev\u002Fpgdog","pgdogdev","PostgreSQL connection pooler, load balancer and database sharder.","https:\u002F\u002Fpgdog.dev",null,"Rust",4854,193,23,77,0,463,485,522,1389,28.86,"GNU Affero General Public License v3.0",false,"main",true,[27,28,29,30,31],"load-balancer","pooler","postgresql","rust","sharding","2026-06-12 02:03:11","\u003Cp align=\"center\">\n    \u003Cpicture>\n      \u003Csource media=\"(prefers-color-scheme: dark)\" srcset=\"\u002F.github\u002Flogo2-white.png\" height=\"128\" width=\"auto\">\n      \u003Csource media=\"(prefers-color-scheme: light)\" srcset=\"\u002F.github\u002Flogo2_wide.png\" height=\"128\" width=\"auto\">\n      \u003Cimg alt=\"Fallback image description\" src=\"\u002F.github\u002Flogo2-white.png\" height=\"128\" width=\"auto\">\n    \u003C\u002Fpicture>\n\u003C\u002Fp>\n\n[![CI](https:\u002F\u002Fgithub.com\u002Flevkk\u002Fpgdog\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Flevkk\u002Fpgdog\u002Factions\u002Fworkflows\u002Fci.yml)\n\nPgDog is a proxy for scaling PostgreSQL. It supports connection pooling, load balancing queries and sharding entire databases. Written in Rust, PgDog is fast, secure and can manage thousands of connections on commodity hardware.\n\n## Documentation\n\n📘 PgDog documentation can be **[found here](https:\u002F\u002Fdocs.pgdog.dev\u002F)**. Any questions? Chat with us on **[Discord](https:\u002F\u002Fdiscord.com\u002Finvite\u002FCcBZkjSJdd)**.\n\n## Quick start\n\n### Kubernetes\n\nHelm chart is **[here](https:\u002F\u002Fgithub.com\u002Fpgdogdev\u002Fhelm)**. To install it, run:\n\n```bash\nhelm repo add pgdogdev https:\u002F\u002Fhelm.pgdog.dev\nhelm install pgdog pgdogdev\u002Fpgdog\n```\n\n### AWS\n\nIf you're using AWS RDS, you can deploy PgDog using one of two supported methods:\n\n1. [Helm chart](https:\u002F\u002Fgithub.com\u002Fpgdogdev\u002Fhelm) with [EKS](https:\u002F\u002Faws.amazon.com\u002Feks\u002F), or a self-hosted Kubernetes cluster\n2. [Terraform module](https:\u002F\u002Fgithub.com\u002Fpgdogdev\u002Fpgdog-ecs-terraform) to deploy PgDog on [ECS](https:\u002F\u002Faws.amazon.com\u002Fecs\u002F)\n\n### Try in Docker\n\nYou can try PgDog quickly using Docker. Install [Docker Compose](https:\u002F\u002Fdocs.docker.com\u002Fcompose\u002F) and run:\n\n```\ndocker-compose up\n```\n\nOnce started, you can connect to PgDog with psql or any other PostgreSQL client:\n\n```\nPGPASSWORD=postgres psql -h 127.0.0.1 -p 6432 -U postgres\n```\n\nThe demo comes with 3 shards and 2 sharded tables:\n\n```sql\nINSERT INTO users (id, email) VALUES (1, 'admin@acme.com');\nINSERT INTO payments (id, user_id, amount) VALUES (1, 1, 100.0);\n\nSELECT * FROM users WHERE id = 1;\nSELECT * FROM payments WHERE user_id = 1;\n```\n\n## Features\n\n📘 **[Configuration](https:\u002F\u002Fdocs.pgdog.dev\u002Fconfiguration\u002F)**\n\nAll PgDog features are configurable and can be turned on and off. PgDog requires 2 configuration files to operate:\n\n1. `pgdog.toml`: hosts, sharding configuration, and other settings\n2. `users.toml`: usernames and passwords\n\n### Example\n\nMost options have reasonable defaults, so a basic configuration for a single user\nand database running on the same machine is pretty short:\n\n**`pgdog.toml`**\n\n```toml\n[general]\nport = 6432\ndefault_pool_size = 10\n\n[[databases]]\nname = \"pgdog\"\nhost = \"127.0.0.1\"\n```\n\n**`users.toml`**\n\n```toml\n[[users]]\nname = \"alice\"\ndatabase = \"pgdog\"\npassword = \"hunter2\"\n```\n\nIf a database in `pgdog.toml` doesn't have a user in `users.toml`, the connection pool for that database will not be created and users won't be able to connect.\n\nIf you'd like to try it out locally, create the database and user like so:\n\n```sql\nCREATE DATABASE pgdog;\nCREATE USER pgdog PASSWORD 'pgdog' LOGIN;\n```\n\n### Transaction pooling\n\n📘 **[Transactions](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Ftransaction-mode)**\n\nLike PgBouncer, PgDog supports transaction (and session) pooling, allowing\nthousands of clients to use just a few PostgreSQL server connections.\n\nUnlike PgBouncer, PgDog can parse and handle `SET` statements and startup options, ensuring session state is set correctly when sharing server connections between clients with different parameters.\n\nPgDog also has more advanced connection recovery options, like automatic abandoned transaction rollbacks and connection re-synchronization to avoid churning server connections during an application crash.\n\n### Load balancer\n\n📘 **[Load balancer](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fload-balancer\u002F)**\n\nPgDog is an application layer (OSI Level 7) load balancer for PostgreSQL. It understands the Postgres protocol, can proxy multiple replicas (and primary) and distributes transactions evenly between databases. The load balancer supports 3 strategies: round robin, random and least active connections.\n\n\n**Example**\n\nThe load balancer is enabled automatically when a database has more than one host:\n\n```toml\n[[databases]]\nname = \"prod\"\nhost = \"10.0.0.1\"\nrole = \"primary\"\n\n[[databases]]\nname = \"prod\"\nhost = \"10.0.0.2\"\nrole = \"replica\"\n```\n\n#### Health checks\n\n📘 **[Healthchecks](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fload-balancer\u002Fhealthchecks\u002F)**\n\n\nPgDog maintains a real-time list of healthy hosts. When a database fails a health check, it's removed from the active rotation and queries are re-routed to other replicas. This works like an HTTP load balancer, except it's for your database.\n\nHealth checks maximize database availability and protect against bad network connections, temporary hardware failures or misconfiguration.\n\n\n#### Single endpoint\n\n📘 **[Single endpoint](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fload-balancer\u002F#single-endpoint)**\n\n\nPgDog uses [`pg_query`](https:\u002F\u002Fgithub.com\u002Fpganalyze\u002Fpg_query.rs), which includes the PostgreSQL native parser. By parsing queries, PgDog can detect writes (e.g. `INSERT`, `UPDATE`, `CREATE TABLE`, etc.) and send them to the primary, leaving the replicas to serve reads (`SELECT`). This allows applications to connect to the same PgDog deployment for both reads and writes.\n\n\n##### Transactions\n\n📘 **[Load balancer & transactions](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fload-balancer\u002Ftransactions\u002F)**\n\n\nTransactions can execute multiple statements, so in a primary & replica configuration, PgDog routes them to the primary. Clients can indicate a transaction is read-only, in which case PgDog will send it to a replica:\n\n```sql\nBEGIN READ ONLY;\n-- This goes to a replica.\nSELECT * FROM users LIMIT 1;\nCOMMIT;\n```\n\n\n#### Failover\n\n📘 **[Failover](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fload-balancer\u002Freplication-failover\u002F)**\n\n\nPgDog monitors Postgres replication state and can automatically redirect writes to a different database if a replica is promoted. This doesn't replace tools like Patroni that actually orchestrate failovers. You can use PgDog alongside Patroni (or AWS RDS or other managed Postgres host), to gracefully failover live traffic.\n\n\n**Example**\n\nTo enable failover, set all database `role` attributes to `auto` and enable replication monitoring (`lsn_check_delay` setting):\n\n```toml\n[general]\nlsn_check_delay = 0\n\n[[databases]]\nname = \"prod\"\nhost = \"10.0.0.1\"\nrole = \"auto\"\n\n[[databases]]\nname = \"prod\"\nhost = \"10.0.0.2\"\nrole = \"auto\"\n```\n\n### Authentication\n\n📘 **[Authentication](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fauthentication\u002F)**\n\nPgDog supports three authentication methods:\n\n1. Password-based\n2. AWS RDS IAM\n3. Azure Workload Identity\n\n#### Password-based authentication\n\nPassword-based authentication allows for clients to authenticate to PgDog and for PgDog to authenticate to PostgreSQL. It currently supports the following password hashing algorithms:\n\n- SCRAM-SHA-256\n- MD5\n- Plain\n\n#### RDS IAM backend authentication\n\nPgDog can keep client-to-PgDog authentication unchanged while using AWS RDS IAM tokens for PgDog-to-PostgreSQL authentication on a per-user basis.\n\n**Example**\n\n```toml\n[[users]]\nname = \"alice\"\ndatabase = \"pgdog\"\npassword = \"client-password\"\nserver_auth = \"rds_iam\"\n# Optional; PgDog infers region from *.region.rds.amazonaws.com(.cn) hostnames when omitted.\n# server_iam_region = \"us-east-1\"\n```\n\nWhen any user has `server_auth = \"rds_iam\"`, the following settings must be configured as well:\n\n- `tls_verify` must **not** be `\"disabled\"`.\n- `passthrough_auth` must be `\"disabled\"`.\n\n#### Azure Workload Identity authentication\n\nPgDog can also use Azure Workload Identity for PgDog-to-PostgreSQL authentication, while keeping client-to-PgDog authentication unchanged. This is configured on a per-user basis, similarly to RDS IAM:\n\n**Example**\n\n```toml\n[[users]]\nname = \"alice\"\ndatabase = \"pgdog\"\npassword = \"client-password\"\nserver_auth = \"azure_workload_identity\"\n```\n\nWhen any user has `server_auth = \"azure_workload_identity\"`, the following settings must be configured as well:\n\n- `tls_verify` must **not** be `\"disabled\"`.\n- `passthrough_auth` must be `\"disabled\"`.\n\n### Sharding\n\n📘 **[Sharding](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002F)**\n\nPgDog is able to manage databases with multiple shards. By using the PostgreSQL parser, PgDog extracts sharding keys and determines the best routing strategy for each query.\n\nFor cross-shard queries, PgDog assembles and transforms results in memory, sending all rows to the client as if they are coming from a single database.\n\n**Example**\n\nConfiguring multiple hosts for the same database with different shard numbers (`shard` setting) enables sharding:\n\n```toml\n[[databases]]\nname = \"prod\"\nhost = \"10.0.0.1\"\nshard = 0\n\n[[databases]]\nname = \"prod\"\nhost = \"10.0.0.2\"\nshard = 1\n```\n\nNote: read below for how to configure query routing. At least one sharded table is required for sharding to work as expected.\n\n#### Sharding functions\n\n📘 **[Sharding functions](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fsharding-functions\u002F)**\n\nPgDog has two main sharding algorithms:\n\n1. PostgreSQL partition functions (`HASH`, `LIST`, `RANGE`)\n2. Using schemas\n\n##### Partition-based sharding\n\nPartition-based sharding functions are taken directly from Postgres source code. This choice intentionally allows to shard data both with PgDog and with Postgres [foreign tables](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fsql-createforeigntable.html) and [`postgres_fdw`](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fpostgres-fdw.html).\n\n**Examples**\n\nThe `PARTITION BY HASH` algorithm is used by default when configuring sharded tables:\n\n```toml\n[[sharded_tables]]\ndatabase = \"prod\"\ncolumn = \"user_id\"\n```\n\nList-based sharding (same as `PARTITION BY LIST` in Postgres) can be configured as follows:\n\n```toml\n# Sharded table definition still required.\n[[sharded_tables]]\ndatabase = \"prod\"\ncolumn = \"user_id\"\n\n# Value-specific shard mappings.\n[[sharded_mapping]]\ndatabase = \"prod\"\ncolumn = \"user_id\"\nvalues = [1, 2, 3, 4]\nshard = 0\n\n[[sharded_mapping]]\ndatabase = \"prod\"\ncolumn = \"user_id\"\nvalues = [5, 6, 7, 8]\nshard = 1\n```\n\nFor range-based sharding, replace the `values` setting with a range, for example:\n\n```toml\nstart = 0 # include\nend = 5 # exclusive\n```\n\n##### Schema-based sharding\n\n📘 **[Schema-based sharding](https:\u002F\u002Fdocs.pgdog.dev\u002Fconfiguration\u002Fpgdog.toml\u002Fsharded_schemas\u002F)**\n\nSchema-based sharding works on the basis of PostgreSQL schemas. Tables under the same schema are placed on the same shard and all queries that refer to those tables are routed to that shard automatically.\n\n**Example**\n\nConfiguring sharded schemas uses a different configuration from sharded tables:\n\n```toml\n[[sharded_schemas]]\ndatabase = \"prod\"\nname = \"customer_a\"\nshard = 0\n\n[[sharded_schemas]]\ndatabase = \"prod\"\nname = \"customer_b\"\nshard = 1\n```\n\nQueries that refer tables in schema `customer_a` will be sent to shard 0. For example, a query that refers to a table by its fully-qualified name will be sent to one shard only:\n\n```sql\nINSERT INTO customer_a.orders (id, user_id, amount)\nVALUES ($1, $2, $3);\n```\n\nAlternatively, the schema name can be specified in the `search_path` session variable:\n\n```sql\nSET search_path TO public, customer_a;\n-- All subsequent queries will be sent to shard 0.\nSELECT * FROM orders LIMIT 1;\n```\n\nYou can also set the `search_path` for the duration of a single transaction, using `SET LOCAL`, ensuring only that transaction is sent to the desired shard:\n\n```sql\n-- The entire transaction will be sent to shard 1.\nBEGIN;\nSET LOCAL search_path TO public, customer_b;\nSELECT * FROM orders LIMIT 1;\nCOMMIT;\n```\n\n#### Direct-to-shard queries\n\n📘 **[Direct-to-shard queries](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fquery-routing\u002F)**\n\n\nQueries that contain a sharding key are sent to one database only. This is the best case scenario for sharded databases, since the load is uniformly distributed across the cluster.\n\n**Example**:\n\n```sql\n-- user_id is the sharding key.\nSELECT * FROM users WHERE user_id = $1;\n```\n\n#### Cross-shard queries\n\n- 📘 **[Cross-shard queries](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fcross-shard-queries\u002F)**\n- 📘 **[SELECT](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fcross-shard-queries\u002Fselect\u002F)**\n- 📘 **[INSERT](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fcross-shard-queries\u002Finsert\u002F)**\n- 📘 **[UPDATE and DELETE](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fcross-shard-queries\u002Fupdate\u002F)**\n- 📘 **[DDL](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fcross-shard-queries\u002Fddl\u002F)**\n\nQueries with multiple sharding keys or without one are sent to all databases and results are post-processed and assembled in memory. PgDog then sends the final result to the client.\n\nCurrently, support for certain SQL features in cross-shard queries is limited. However, the list of supported ones keeps growing:\n\n| Feature | Supported | Notes |\n|-|-|-|\n| Aggregates | Partial | `count`, `min`, `max`, `stddev`, `variance`, `sum`, `avg` are supported. |\n| `ORDER BY` | Partial | Column in `ORDER BY` clause must be present in the result set. |\n| `GROUP BY` | Partial | Same as `ORDER BY`, referenced columns must be present in result set. |\n| Multi-tuple `INSERT` | Supported | PgDog generates one statement per tuple and executes them automatically. |\n| Sharding key `UPDATE` | Supported | PgDog generates a `SELECT`, `INSERT` and `DELETE` statements and execute them automatically. |\n| Subqueries | No | The same subquery is executed on all shards. |\n| CTEs | No | The same CTE is executed on all shards. |\n\n\n#### Using `COPY`\n\n📘 **[Copy](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fcross-shard-queries\u002Fcopy\u002F)**\n\nPgDog has a text, CSV & binary parser and can split rows sent via `COPY` command between all shards automatically. This allows clients to ingest data into sharded PostgreSQL without preprocessing\n\n**Example**\n\n```sql\nCOPY orders (id, user_id, amount) FROM STDIN CSV HEADER;\n```\n\nColumns must be specified in the `COPY` statement, so PgDog can infer the sharding key automatically, but are optional in the data file.\n\n\n#### Consistency (two-phase commit)\n\n📘 **[Two-phase commit](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002F2pc\u002F)**\n\nTo make sure cross-shard writes are atomic, PgDog supports Postgres' [two-phase transactions](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Ftwo-phase.html). When enabled, PgDog handles `COMMIT` statements sent by clients by executing the 2pc exchange on their behalf:\n\n```sql\nPREPARE TRANSACTION '__pgdog_unique_id';\nCOMMIT PREPARED '__pgdog_unique_id';\n```\n\nIn case the client disconnects or Postgres crashes, PgDog will automatically rollback the transaction if it's in phase I and commit it if it's in phase II.\n\n#### Unique identifiers\n\n📘 **[Unique IDs](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Funique-ids\u002F)**\n\nWhile applications can use `UUID` (v4 and now v7) to generate unique primary keys, PgDog supports creating unique `BIGINT` identifiers, without using a sequence:\n\n```sql\nSELECT pgdog.unique_id();\n```\n\nThis uses a timestamp-based algorithm, can produce millions of unique numbers per second and doesn't require an expensive cross-shard index to guarantee uniqueness.\n\n#### Shard key updates\n\nPgDog supports changing the sharding key for a row online. Under the hood, it will execute 3 statements to make it happen:\n\n1. `SELECT` to get the entire row from its original shard\n2. `INSERT` to write the new, changed row to the new shard\n3. `DELETE` to remove it from the old shard\n\nThis happens automatically, and the client can retrieve the new row as normal:\n\n```sql\nUPDATE orders SET user_id = 5 WHERE user_id = 1 RETURNING *;\n-- This will return the new row\n```\n\nNote: Only one row can be updated at a time and if a query attempts to update multiple, PgDog will abort the transaction.\n\nTo enable shard key updates, add this to `pgdog.toml`:\n\n```toml\n[rewrite]\nenabled = true\nshard_key = \"rewrite\" # options: ignore (possible data loss), error (block shard key update)\n```\n\n#### Multi-tuple inserts\n\nPgDog can handle multi-tuple `INSERT` queries by sending each tuple to the right shard, e.g.:\n\n```sql\nINSERT INTO payments\n    (id, user_id, amount) -- user_id is the sharding key\nVALUES\n(pgdog.unique_id(), 1, 25.00), -- Tuples go to different shards\n(pgdog.unique_id(), 5, 55.0); -- Each tuple gets a unique primary key because unique ID function is invoked twice\n```\n\nThis happens automatically, if enabled:\n\n```toml\n[rewrite]\nenabled = true\nsplit_inserts = \"rewrite\" # other options: ignore, error\n```\n\n#### Re-sharding\n\n- 📘 **[Re-sharding](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fresharding\u002F)**\n- 📘 **[Schema sync](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fresharding\u002Fschema\u002F)**\n- 📘 **[Data sync](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fsharding\u002Fresharding\u002Fhash\u002F)**\n\nPgDog understands the PostgreSQL logical replication protocol and can orchestrate data splits between databases, in the background and without downtime. This allows to shard existing databases and add more shards to existing clusters in production, without impacting database operations.\n\nThe re-sharding process is done in 5 steps:\n\n1. Create new empty cluster with the desired number of shards\n2. Configure it in `pgdog.toml` and run `schema-sync` command to copy table schemas to the new databases\n3. Run `data-sync` command to copy and re-shard table data with logical replication (tables are copied in parallel)\n4. While keeping previous command running (it streams row updates in real-time), run `schema-sync --data-sync-complete` to create secondary indexes on the new databases (much faster to do this after data is copied)\n5. Cutover traffic to new cluster with `MAINTENANCE ON`, `RELOAD`, `MAINTENANCE OFF` command sequence\n\nCutover can be done atomically with multiple PgDog containers because `RELOAD` doesn't resume traffic, `MAINTENANCE OFF` does, so the config is the same in all containers before queries are resumed. No complex synchronization tooling like etcd or  Zookeeper is required.\n\n### Monitoring\n\n📘 **[Metrics](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002Fmetrics\u002F)**\n\nPgDog exposes both the standard PgBouncer-style admin database, an OpenMetrics endpoint and can push metrics to an OTEL endpoint. The admin database isn't 100% compatible,\nso we recommend you use either OpenMetrics or OTEL ingestion for monitoring. Example Datadog configuration and dashboard are [included](examples\u002Fdatadog).\n\n\n## Running PgDog locally\n\nInstall the latest version of the Rust compiler from [rust-lang.org](https:\u002F\u002Frust-lang.org).\nClone this repository and build the project in release mode:\n\n```bash\ncargo build --release\n```\n\nIt's important to use the release profile if you're deploying to production or want to run\nperformance benchmarks.\n\n#### Try sharding\n\nSharded database clusters are set in the config. For example, to set up a 2 shard cluster, you can:\n\n**`pgdog.toml`**\n\n```toml\n[[databases]]\nname = \"pgdog_sharded\"\nhost = \"127.0.0.1\"\ndatabase_name = \"shard_0\"\nshard = 0\n\n[[databases]]\nname = \"pgdog_sharded\"\nhost = \"127.0.0.1\"\ndatabase_name = \"shard_1\"\nshard = 1\n\n[[sharded_tables]]\ndatabase = \"pgdog_sharded\"\ncolumn = \"user_id\"\n```\n\nDon't forget to configure a user:\n\n**`users.toml`**\n\n```toml\n[[users]]\ndatabase = \"pgdog_sharded\"\nname = \"pgdog\"\npassword = \"pgdog\"\n```\n\nAnd finally, to make it work locally, create the required databases:\n\n```sql\nCREATE DATABASE shard_0;\nCREATE DATABASE shard_1;\n\nGRANT ALL ON DATABASE shard_0 TO pgdog;\nGRANT ALL ON DATABASE shard_1 TO pgdog;\n```\n\n### Start PgDog\n\nRunning PgDog can be done with Cargo:\n\n```bash\ncargo run --release\n```\n\n#### Command-line options\n\nPgDog supports several command-line options:\n\n- `-c, --config \u003CCONFIG>`: Path to the configuration file (default: `\"pgdog.toml\"`)\n- `-u, --users \u003CUSERS>`: Path to the users.toml file (default: `\"users.toml\"`)\n- `-d, --database_url \u003CDATABASE_URL>`: Connection URL(s). Can be specified multiple times to add multiple database connections. When provided, these URLs override database configurations from the config file.\n\nExample using database URLs directly:\n\n```bash\ncargo run --release -- -d postgres:\u002F\u002Fuser:pass@localhost:5432\u002Fdb1 -d postgres:\u002F\u002Fuser:pass@localhost:5433\u002Fdb2\n```\n\nYou can connect to PgDog with `psql` or any other PostgreSQL client:\n\n```bash\npsql postgres:\u002F\u002Fpgdog:pgdog@127.0.0.1:6432\u002Fpgdog\n```\n\n## 🚦 Status 🚦\n\nPgDog is used in production and at scale. Most features are stable, while some are experimental. Check [documentation](https:\u002F\u002Fdocs.pgdog.dev\u002Ffeatures\u002F) for more details. New sharding features are added almost weekly.\n\n## Performance\n\n📘 **[Architecture & benchmarks](https:\u002F\u002Fdocs.pgdog.dev\u002Farchitecture\u002F)**\n\nPgDog is heavily optimized for performance. We use Rust, [Tokio](https:\u002F\u002Ftokio.rs\u002F), [bytes crate](https:\u002F\u002Fdocs.rs\u002Fbytes\u002Flatest\u002Fbytes\u002F) to avoid unnecessary memory allocations, and profile for performance regressions on a regular basis.\n\n## License\n\nPgDog is free and open source software, licensed under the AGPL v3. While often misunderstood, this license is very permissive\nand allows the following without any additional requirements from you or your organization:\n\n* Internal use\n* Private modifications for internal use without sharing any source code\n\nYou can freely use PgDog to power your PostgreSQL databases without having to\nshare any source code, including proprietary work product or any PgDog modifications you make.\n\nAGPL was written specifically for organizations that offer PgDog _as a public service_ (e.g. database cloud providers) and require\nthose organizations to share any modifications they make to PgDog, including new features and bug fixes.\n\n## Contributions\n\nPlease read our [Contribution Guidelines](CONTRIBUTING.md).\n","PgDog 是一个用于扩展 PostgreSQL 的代理工具，支持连接池管理、负载均衡和数据库分片。该项目使用 Rust 语言编写，确保了高性能与安全性，即使在普通硬件上也能处理数千个并发连接。PgDog 适用于需要提高 PostgreSQL 数据库性能和可用性的场景，比如高流量网站或大规模数据处理应用。它通过提供灵活的配置选项来满足不同需求，并且支持 Docker、Kubernetes 和 AWS 等多种部署方式，便于集成到现有基础设施中。",2,"2026-06-11 03:44:54","high_star"]