Skip to content

Commit a33cfc5

Browse files
authored
update readme (#38)
1 parent 2cf7d39 commit a33cfc5

File tree

1 file changed

+61
-98
lines changed

1 file changed

+61
-98
lines changed

README.md

+61-98
Original file line numberDiff line numberDiff line change
@@ -4,17 +4,15 @@
44

55
[![CI](https://github.com/levkk/pgdog/actions/workflows/ci.yml/badge.svg)](https://github.com/levkk/pgdog/actions/workflows/ci.yml)
66

7-
PgDog is a transaction pooler and logical replication manager that can shard PostgreSQL.
8-
Spiritual successor to [pgcat](https://github.com/levkk/pgcat) and written in Rust, PgDog comes with a lot of
9-
the same features, like load balancing, failover and connection pooling. In addition, PgDog improves performance and adds new features like cross-shard queries, async protocol support, and sharded `COPY`.
7+
PgDog is a transaction pooler and logical replication manager that can shard PostgreSQL. Written in Rust, PgDog is fast, secure and can manage hundreds of databases and hudreds of thousands of connections.
108

119
## Documentation
1210

13-
📘 PgDog documentation can be **[found here](https://docs.pgdog.dev/).**
11+
📘 PgDog documentation can be **[found here](https://docs.pgdog.dev/)**. Any questions? Join our **[Discord](https://discord.gg/jf5A6VES)**.
1412

1513
## Quick start
1614

17-
You can try PgDog by using Docker. Make sure to install [Docker Compose](https://docs.docker.com/compose/) and run the following:
15+
You can try PgDog using Docker. Install [Docker Compose](https://docs.docker.com/compose/) and run:
1816

1917
```
2018
docker-compose up
@@ -36,23 +34,56 @@ SELECT * FROM users WHERE id = 1;
3634
SELECT * FROM payments WHERE user_id = 1;
3735
```
3836

37+
## Features
38+
39+
40+
### Load balancer
41+
42+
PgDog is an application layer (OSI Level 7) load balancer for PostgreSQL. It can proxy multiple replicas (and primary) and distribute transactions evenly between databases. It supports multiple strategies, including round robin, random, least active connections, etc. PgDog can also inspect queries and send `SELECT` queries to replicas, and all others to the primary. This allows to proxy all databases behind a single PgDog deployment.
43+
44+
📘 **[Load balancer](https://docs.pgdog.dev/features/load-balancer)**
45+
46+
#### Healthchecks and failover
47+
48+
PgDog maintains a real-time list of healthy hosts. When a host fails a healthcheck, it's removed from active rotation and queries are rerouted to other databases. This is similar to HTTP load balancing, except it's at the database layer.
49+
50+
Failover maximizes database availability and protects against bad network connections, temporary hardware failures or misconfiguration.
51+
52+
📘 **[Healthchecks](https://docs.pgdog.dev/features/healthchecks)**
53+
54+
### Transaction pooling
55+
56+
Like PgBouncer, PgDog supports transaction (and session) pooling, allowing
57+
100,000s of clients to use just a few PostgreSQL server connections.
58+
59+
📘 **[Transactions](https://docs.pgdog.dev/features/transaction-mode)**
60+
61+
### Sharding
62+
63+
PgDog is able to handle databases with multiple shards by routing queries automatically to one or more shards. Using the native PostgreSQL parser, PgDog understands queries, extracts sharding keys and determines the best routing strategy. For cross-shard queries, PgDog assembles results in memory and sends them all to the client transparently.
64+
65+
#### Using `COPY`
3966

40-
## Features summary
67+
PgDog comes with a CSV parser and can split COPY commands between all shards automatically. This allows clients to ingest data into sharded PostgreSQL without preprocessing.
4168

42-
| Feature | Status | Summary |
43-
|---------|--------|---------|
44-
| [Load balancer](https://docs.pgdog.dev/features/load-balancer) | Operational | Spread `SELECT` queries across multiple replicas automatically, using algorithms like round robin. |
45-
| [Transaction pooling](https://docs.pgdog.dev/features/transaction-mode) | Operational | Identical to pgbouncer, allows for thousands of clients to reuse a handful of server connections. |
46-
| [Session pooling](https://docs.pgdog.dev/features/session-mode) | Operational | Exclusive use of server connections for clients needing session-level features. |
47-
| [Plugins](https://docs.pgdog.dev/features/docs/plugins/) | Operational | Control how PgDog routes queries and what results it sends to clients, through loading shared libraries at runtime. |
48-
| [Sharding](https://docs.pgdog.dev/features/sharding/) | Work in progress | Automatically split data and queries between multiple databases, scaling writes horizonally. |
49-
| [Authentication](https://docs.pgdog.dev/features/authentication/) | Supports `scram-sha-256` and `trust` | Suppport for various PostgreSQL authentication mechanisms, like SCRAM, MD5, and LDAP. |
50-
| [Configuration](https://docs.pgdog.dev/configuration/) | Operational | Configure PgDog without restarting the pooler or breaking connections. |
69+
#### Logical replication
5170

52-
## Getting started
71+
PgDog understands the PostgreSQL logical replication protocol and can split data 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.
72+
73+
📘 **[Sharding](https://docs.pgdog.dev/features/sharding/)**
74+
75+
### Configuration
76+
77+
PgDog is highly configurable and many aspects of its operation can be tweaked at runtime, without having
78+
to restart the process and break PostgreSQL connections. If you've used PgBouncer (or PgCat) before, the options
79+
will be familiar. If not, they are documented with examples.
80+
81+
📘 **[Configuration](https://docs.pgdog.dev/configuration/)**
82+
83+
## Running PgDog locally
5384

5485
Install the latest version of the Rust compiler from [rust-lang.org](https://rust-lang.org).
55-
Once you have Rust installed, clone this repository and build the project in release mode:
86+
Clone this repository and build the project in release mode:
5687

5788
```bash
5889
cargo build --release
@@ -99,107 +130,39 @@ CREATE DATABASE pgdog;
99130
CREATE USER pgdog PASSWORD 'pgdog' LOGIN;
100131
```
101132

102-
### Running PgDog
103-
104-
Running PgDog can be done with Cargo:
105-
106-
```bash
107-
cargo run --release
108-
```
109-
110-
You can connect to PgDog with psql or any other PostgreSQL client:
111-
112-
```bash
113-
psql postgres://pgdog:[email protected]:6432/pgdog
114-
```
115-
116-
## Features
117-
118-
### Load balancer
119-
120-
PgDog is an application layer (OSI Level 7) load balancer for PostgreSQL. It can proxy multiple replicas (and primary) and distribute transactions. It comes with support for multiple strategies, including round robin and random. Additionally, it can parse queries and send `SELECT` queries to replicas and all others to the primary. This allows to proxy all databases behind a single PgDog deployment.
121-
122-
📘 **[Load balancer](https://docs.pgdog.dev/features/load-balancer)**
123-
124-
#### Healthchecks and failover
125-
126-
PgDog maintains a real time list of healthy hosts in its database configuration.
127-
When a host fails a healthcheck, it's removed from active rotation
128-
and queries are rerouted to other replicas. This is analogous to modern HTTP
129-
load balancing, except it's at the database layer.
130-
131-
Failover maximizes database availability and protects against intermittent issues like spotty network connectivity and temporary downtime.
132-
133-
📘 **[Healthchecks](https://docs.pgdog.dev/features/healthchecks)**
134-
135-
### Transaction pooling
136-
137-
Like pgbouncer, PgDog supports transaction-level connection pooling, allowing
138-
1000s (even 100,000s) of clients to reuse just a few PostgreSQL server connections.
139-
140-
📘 **[Transactions](https://docs.pgdog.dev/features/transaction-mode)**
141-
142-
### Plugins
143-
144-
PgDog comes with its own plugin system that loads them at runtime using a shared library interface.
145-
If a plugin can expose a predefined C API, it can be written in any language, including C/C++, Rust, Zig, Go, Python, Ruby, Java, and many more.
146-
147-
Plugins can be used to route queries to specific databases in a sharded configuration, or to
148-
split traffic between writes and reads in a mixed (primary & replicas) deployment. The plugin
149-
interface allows code execution at multiple stages of the request/response lifecycle, and can
150-
go as far as block or intercept queries and return custom results to the client.
151-
152-
Examples of plugins can be found in [examples](https://github.com/levkk/pgdog/tree/main/examples) and [plugins](https://github.com/levkk/pgdog/tree/main/plugins).
153-
154-
📘 **[Plugins](https://docs.pgdog.dev/features/plugins/)**
155-
156-
### Sharding
157-
158-
_This feature is a work in progress._
159-
160-
PgDog is able to handle databases with multiple shards by routing queries automatically to one or more shards. The `pgdog-routing` plugin parses
161-
queries, extracts tables and columns information, and calculates which shard(s) the query should go to based on the parameters. Not all operations are supported, but
162-
a lot of common use cases are working.
163-
164-
📘 **[Sharding](https://docs.pgdog.dev/features/sharding/)**
165-
166-
#### Local testing
133+
#### Try sharding
167134

168135
The configuration files for a sharded database are provided in the repository. To make it work locally, create the required databases:
169136

170137
```postgresql
171138
CREATE DATABASE shard_0;
172139
CREATE DATABASE shard_1;
173140
174-
GRANT CONNECT ON DATABASE shard_0 TO pgdog;
175-
GRANT CONNECT ON DATABASE shard_1 TO pgdog;
141+
GRANT ALL ON DATABASE shard_0 TO pgdog;
142+
GRANT ALL ON DATABASE shard_1 TO pgdog;
176143
```
177144

178-
You can launch PgDog with the sharded configuration using the files provided in the repository:
145+
### Start PgDog
146+
147+
Running PgDog can be done with Cargo:
179148

180149
```bash
181-
cargo run -- --config pgdog-sharded.toml --users users-sharded.toml
150+
cargo run --release
182151
```
183152

184-
### Configuration
185-
186-
PgDog is highly configurable and many aspects of its operation can be tweaked at runtime, without having
187-
to restart the process and break PostgreSQL connections. If you've used pgbouncer (or pgcat) before, the options
188-
will be familiar. If not, options are documented with examples.
153+
You can connect to PgDog with psql or any other PostgreSQL client:
189154

190-
📘 **[Configuration](https://docs.pgdog.dev/configuration/)**
155+
```bash
156+
psql postgres://pgdog:[email protected]:6432/pgdog
157+
```
191158

192159
## 🚦 Status 🚦
193160

194-
While a lot of "classic" features of PgDog, like load balancing and healthchecks, have been well tested in production and at scale, the current codebase has not. This project is just getting started and early adopters are welcome to try PgDog internally.
195-
196-
Status on features stability will be [updated regularly](https://docs.pgdog.dev/features/).
161+
This project is just getting started and early adopters are welcome to try PgDog internally. Status on features stability will be [updated regularly](https://docs.pgdog.dev/features/). Most features have tests and are benchmarked regularly for performance regressions.
197162

198163
## Performance
199164

200-
PgDog does its best to minimize its impact on overall database performance. Using Rust and Tokio is a great start for a fast network proxy, but additional
201-
care is also taken to perform as few operations as possible while moving data between client and server sockets. Some benchmarks are provided
202-
to help set a baseline.
165+
PgDog does its best to minimize its impact on overall database performance. Using Rust and Tokio is a great start for a fast network proxy, but additional care is also taken to perform as few operations as possible while moving data between client and server sockets. Some benchmarks are provided to help set a baseline.
203166

204167
📘 **[Architecture & benchmarks](https://docs.pgdog.dev/architecture/)**
205168

0 commit comments

Comments
 (0)