shorten readme

Author: levkk

README.md

@@ -36,84 +36,54 @@ SELECT * FROM payments WHERE user_id = 1;
 
 ## Features
 
+
 ### Load balancer
 
-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.
+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.
 
 📘 **[Load balancer](https://docs.pgdog.dev/features/load-balancer)**
 
 #### Healthchecks and failover
 
-PgDog maintains a real time list of healthy hosts in its database configuration.
-When a host fails a healthcheck, it's removed from active rotation
-and queries are rerouted to other replicas. This is analogous to modern HTTP
-load balancing, except it's at the database layer.
+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.
 
-Failover maximizes database availability and protects against intermittent issues like spotty network connectivity and temporary downtime.
+Failover maximizes database availability and protects against bad network connections, temporary hardware failures or misconfiguration.
 
 📘 **[Healthchecks](https://docs.pgdog.dev/features/healthchecks)**
 
 ### Transaction pooling
 
-Like pgbouncer, PgDog supports transaction-level connection pooling, allowing
-1000s (even 100,000s) of clients to reuse just a few PostgreSQL server connections.
+Like PgBouncer, PgDog supports transaction (and session) pooling, allowing
+100,000s of clients to use just a few PostgreSQL server connections.
 
 📘 **[Transactions](https://docs.pgdog.dev/features/transaction-mode)**
 
-### Plugins
-
-PgDog comes with its own plugin system that loads them at runtime using a shared library interface.
-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.
-
-Plugins can be used to route queries to specific databases in a sharded configuration, or to
-split traffic between writes and reads in a mixed (primary & replicas) deployment. The plugin
-interface allows code execution at multiple stages of the request/response lifecycle, and can
-go as far as block or intercept queries and return custom results to the client.
-
-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).
-
-📘 **[Plugins](https://docs.pgdog.dev/features/plugins/)**
-
 ### Sharding
 
-_This feature is a work in progress._
-
-PgDog is able to handle databases with multiple shards by routing queries automatically to one or more shards. The `pgdog-routing` plugin parses
-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
-a lot of common use cases are working.
+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.
 
-📘 **[Sharding](https://docs.pgdog.dev/features/sharding/)**
-
-#### Local testing
-
-The configuration files for a sharded database are provided in the repository. To make it work locally, create the required databases:
+#### Using `COPY`
 
-```postgresql
-CREATE DATABASE shard_0;
-CREATE DATABASE shard_1;
+PgDog come with a CSV parser and can split a COPY command between all shards automatically. This allows clients to ingest data into sharded PostgreSQL without preprocessing.
 
-GRANT CONNECT ON DATABASE shard_0 TO pgdog;
-GRANT CONNECT ON DATABASE shard_1 TO pgdog;
-```
+#### Logical replication
 
-You can launch PgDog with the sharded configuration using the files provided in the repository:
+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.
 
-```bash
-cargo run -- --config pgdog-sharded.toml --users users-sharded.toml
-```
+📘 **[Sharding](https://docs.pgdog.dev/features/sharding/)**
 
 ### Configuration
 
 PgDog is highly configurable and many aspects of its operation can be tweaked at runtime, without having
-to restart the process and break PostgreSQL connections. If you've used pgbouncer (or pgcat) before, the options
-will be familiar. If not, options are documented with examples.
+to restart the process and break PostgreSQL connections. If you've used PgBouncer (or PgCat) before, the options
+will be familiar. If not, they are documented with examples.
 
 📘 **[Configuration](https://docs.pgdog.dev/configuration/)**
 
 ## Running PgDog locally
 
 Install the latest version of the Rust compiler from [rust-lang.org](https://rust-lang.org).
-Once you have Rust installed, clone this repository and build the project in release mode:
+Clone this repository and build the project in release mode:
 
 ```bash
 cargo build --release
@@ -160,6 +130,18 @@ CREATE DATABASE pgdog;
 CREATE USER pgdog PASSWORD 'pgdog' LOGIN;
 ```
 
+#### Try sharding
+
+The configuration files for a sharded database are provided in the repository. To make it work locally, create the required databases:
+
+```postgresql
+CREATE DATABASE shard_0;
+CREATE DATABASE shard_1;
+
+GRANT ALL ON DATABASE shard_0 TO pgdog;
+GRANT ALL ON DATABASE shard_1 TO pgdog;
+```
+
 ### Start PgDog
 
 Running PgDog can be done with Cargo:
@@ -176,15 +158,11 @@ psql postgres://pgdog:[email protected]:6432/pgdog
 
 ## 🚦 Status 🚦
 
-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.
-
-Status on features stability will be [updated regularly](https://docs.pgdog.dev/features/).
+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.
 
 ## Performance
 
-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.
+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.
 
 📘 **[Architecture & benchmarks](https://docs.pgdog.dev/architecture/)**