rubydb 0.1.3 → 0.1.5

data/docs/rails/database-yml.md

@@ -1,92 +1,92 @@
-# Rails database configuration
-
-Embedded single-owner configuration:
-
-```yaml
-development:
-  adapter: rubydb
-  database: tmp/development.rdb
-  embedded: true
-```
-
-For multiple web or worker processes, use a managed RubyDB server and configure
-the host, port, credentials, timeout, pool size, TLS, and database name through
-protected deployment configuration. Do not put passwords, replication tokens,
-or private keys in `database.yml` committed to source control.
-
-Match the total Rails pool size to the server connection limit and leave headroom
-for migrations, monitoring, and replication. Test the exact configuration with
-the Rails matrix before release.
-
-## Production server/client configuration
-
-For a multi-process Rails deployment, keep the server private and put only
-non-secret connection settings in source control. This is a complete example;
-the `RUBYDB_*` values are supplied by the deployment environment or secret
-manager:
-
-```yaml
-production:
-  adapter: rubydb
-  embedded: false
-  host: <%= ENV.fetch("RUBYDB_HOST") %>
-  port: <%= ENV.fetch("RUBYDB_PORT", "7432") %>
-  database: <%= ENV.fetch("RUBYDB_DATABASE", "rubydb") %>
-  username: <%= ENV.fetch("RUBYDB_USERNAME") %>
-  password: <%= ENV.fetch("RUBYDB_PASSWORD") %>
-  timeout: <%= ENV.fetch("RUBYDB_TIMEOUT", "30") %>
-  pool: <%= ENV.fetch("RAILS_MAX_THREADS", "5") %>
-  ssl:
-    enabled: <%= ENV.fetch("RUBYDB_SSL_ENABLED", "true") == "true" %>
-    ca_file: <%= ENV.fetch("RUBYDB_SSL_CA_FILE") %>
-    verify_peer: <%= ENV.fetch("RUBYDB_SSL_VERIFY_PEER", "true") == "true" %>
-```
-
-Deploy the application with values similar to:
-
-```sh
-RUBYDB_HOST=db.internal.example
-RUBYDB_PORT=7432
-RUBYDB_DATABASE=app
-RUBYDB_USERNAME=app_rw
-RUBYDB_PASSWORD='provided-by-secret-manager'
-RUBYDB_SSL_ENABLED=true
-RUBYDB_SSL_CA_FILE=/etc/rubydb/tls/ca.crt
-RUBYDB_SSL_VERIFY_PEER=true
-```
-
-The exact variable names are application conventions; Rails reads them because
-`database.yml` maps them into adapter settings. Do not put the password in a
-committed YAML file, Docker image, URL, shell history, or log. The server must
-be configured separately with its own data directory, authentication, TLS
-certificate/key, and resource limits; see [server configuration](../server/configuration.md).
-
-## One connection URL
-
-The adapter also accepts a RubyDB-specific URL through `url`. This is useful
-when a hosting provider gives the application one connection string:
-
-```yaml
-production:
-  adapter: rubydb
-  embedded: false
-  url: <%= ENV.fetch("RUBYDB_URL") %>
-  pool: <%= ENV.fetch("RAILS_MAX_THREADS", "5") %>
-```
-
-Example URL with TLS verification:
-
-```text
-rubydbs://app_user:password@db.example.com:7432/app?verify_peer=true&ca_file=%2Fetc%2Frubydb%2Fca.crt
-```
-
-Supported schemes are `rubydb://` and `rubydbs://`; `rubydbs` enables TLS.
-The URL supports percent-encoded username/password/database values and query
-options including `ssl`, `sslmode`, `verify_peer`, `ca_file`, `cert_file`,
-`key_file`, `min_version`, `timeout`, `pool_size`, `compress`, and `format`.
-Use a secret manager to inject `RUBYDB_URL`; URLs containing passwords must not
-be committed, printed, or placed in public issue reports. This is RubyDB’s
-URL format, not a PostgreSQL wire-protocol or generic `DATABASE_URL` promise.
-
-Use the documented mapping above and run a real migration plus smoke query
-through the network path before production.
+# Rails database configuration
+
+Embedded single-owner configuration:
+
+```yaml
+development:
+  adapter: rubydb
+  database: tmp/development.rdb
+  embedded: true
+```
+
+For multiple web or worker processes, use a managed RubyDB server and configure
+the host, port, credentials, timeout, pool size, TLS, and database name through
+protected deployment configuration. Do not put passwords, replication tokens,
+or private keys in `database.yml` committed to source control.
+
+Match the total Rails pool size to the server connection limit and leave headroom
+for migrations, monitoring, and replication. Test the exact configuration with
+the Rails matrix before release.
+
+## Production server/client configuration
+
+For a multi-process Rails deployment, keep the server private and put only
+non-secret connection settings in source control. This is a complete example;
+the `RUBYDB_*` values are supplied by the deployment environment or secret
+manager:
+
+```yaml
+production:
+  adapter: rubydb
+  embedded: false
+  host: <%= ENV.fetch("RUBYDB_HOST") %>
+  port: <%= ENV.fetch("RUBYDB_PORT", "7432") %>
+  database: <%= ENV.fetch("RUBYDB_DATABASE", "rubydb") %>
+  username: <%= ENV.fetch("RUBYDB_USERNAME") %>
+  password: <%= ENV.fetch("RUBYDB_PASSWORD") %>
+  timeout: <%= ENV.fetch("RUBYDB_TIMEOUT", "30") %>
+  pool: <%= ENV.fetch("RAILS_MAX_THREADS", "5") %>
+  ssl:
+    enabled: <%= ENV.fetch("RUBYDB_SSL_ENABLED", "true") == "true" %>
+    ca_file: <%= ENV.fetch("RUBYDB_SSL_CA_FILE") %>
+    verify_peer: <%= ENV.fetch("RUBYDB_SSL_VERIFY_PEER", "true") == "true" %>
+```
+
+Deploy the application with values similar to:
+
+```sh
+RUBYDB_HOST=db.internal.example
+RUBYDB_PORT=7432
+RUBYDB_DATABASE=app
+RUBYDB_USERNAME=app_rw
+RUBYDB_PASSWORD='provided-by-secret-manager'
+RUBYDB_SSL_ENABLED=true
+RUBYDB_SSL_CA_FILE=/etc/rubydb/tls/ca.crt
+RUBYDB_SSL_VERIFY_PEER=true
+```
+
+The exact variable names are application conventions; Rails reads them because
+`database.yml` maps them into adapter settings. Do not put the password in a
+committed YAML file, Docker image, URL, shell history, or log. The server must
+be configured separately with its own data directory, authentication, TLS
+certificate/key, and resource limits; see [server configuration](../server/configuration.md).
+
+## One connection URL
+
+The adapter also accepts a RubyDB-specific URL through `url`. This is useful
+when a hosting provider gives the application one connection string:
+
+```yaml
+production:
+  adapter: rubydb
+  embedded: false
+  url: <%= ENV.fetch("RUBYDB_URL") %>
+  pool: <%= ENV.fetch("RAILS_MAX_THREADS", "5") %>
+```
+
+Example URL with TLS verification:
+
+```text
+rubydbs://app_user:password@db.example.com:7432/app?verify_peer=true&ca_file=%2Fetc%2Frubydb%2Fca.crt
+```
+
+Supported schemes are `rubydb://` and `rubydbs://`; `rubydbs` enables TLS.
+The URL supports percent-encoded username/password/database values and query
+options including `ssl`, `sslmode`, `verify_peer`, `ca_file`, `cert_file`,
+`key_file`, `min_version`, `timeout`, `pool_size`, `compress`, and `format`.
+Use a secret manager to inject `RUBYDB_URL`; URLs containing passwords must not
+be committed, printed, or placed in public issue reports. This is RubyDB’s
+URL format, not a PostgreSQL wire-protocol or generic `DATABASE_URL` promise.
+
+Use the documented mapping above and run a real migration plus smoke query
+through the network path before production.

data/docs/rails/installation.md

@@ -1,17 +1,17 @@
-# Rails adapter installation
-
-From the repository adapter directory:
-
-```sh
-cd adapters/activerecord
-bundle install
-bundle exec rspec
-```
-
-Add the adapter gem to the application bundle according to the release being
-tested. Configure `adapter: rubydb` and a database path or server endpoint. Run
-`db:migrate`, schema dump/load, representative joins, eager loading, nested
-associations, and rollback tests before deployment.
-
-The CI matrix currently exercises Rails 7.1, 7.2, and 8.0 with the supported
-Ruby versions. Hosted results are the release evidence for a combination.
+# Rails adapter installation
+
+From the repository adapter directory:
+
+```sh
+cd adapters/activerecord
+bundle install
+bundle exec rspec
+```
+
+Add the adapter gem to the application bundle according to the release being
+tested. Configure `adapter: rubydb` and a database path or server endpoint. Run
+`db:migrate`, schema dump/load, representative joins, eager loading, nested
+associations, and rollback tests before deployment.
+
+The CI matrix currently exercises Rails 7.1, 7.2, and 8.0 with the supported
+Ruby versions. Hosted results are the release evidence for a combination.

data/docs/rails/migrations.md

@@ -1,17 +1,17 @@
-# Rails migrations
-
-RubyDB supports the documented ActiveRecord migration surface, including table
-creation, integer primary keys, columns, defaults, indexes, constraints, and
-populated-table round trips covered by the adapter suite.
-
-Before production migration:
-
-1. verify a full backup and WAL chain;
-2. restore into a new staging directory with representative data;
-3. run the migration, schema dump/load, application queries, and rollback path;
-4. confirm the migration checksum and schema status;
-5. retain the pre-migration directory until rollback is no longer needed.
-
-RubyDB fails closed when an applied migration changes or disappears. Unsupported
-table rebuilds, generated columns, polymorphic references, and dialect-specific
-extensions require explicit validation.
+# Rails migrations
+
+RubyDB supports the documented ActiveRecord migration surface, including table
+creation, integer primary keys, columns, defaults, indexes, constraints, and
+populated-table round trips covered by the adapter suite.
+
+Before production migration:
+
+1. verify a full backup and WAL chain;
+2. restore into a new staging directory with representative data;
+3. run the migration, schema dump/load, application queries, and rollback path;
+4. confirm the migration checksum and schema status;
+5. retain the pre-migration directory until rollback is no longer needed.
+
+RubyDB fails closed when an applied migration changes or disappears. Unsupported
+table rebuilds, generated columns, polymorphic references, and dialect-specific
+extensions require explicit validation.

data/docs/rails/production.md

@@ -1,82 +1,82 @@
-# Rails production guidance
-
-RubyDB can serve Rails applications that stay within the documented RubyDB SQL
-and ActiveRecord adapter surface. Validate the exact Rails, Ruby, operating
-system, schema, workload, and deployment topology before handling important
-data. The compatibility workflow currently exercises Rails 7.1, 7.2, and 8.0
-with Ruby 3.3; hosted workflow results are required before declaring a release
-combination supported.
-
-## Choose the topology
-
-An embedded database path has exclusive ownership. Use it only when one Rails
-process owns the database, such as a single-process development or controlled
-worker deployment. Do not point multiple independent Rails processes at the
-same embedded path.
-
-For multiple web/worker processes, run a separately managed RubyDB server and
-configure clients to use its network endpoint. Size the server connection
-limit for the Rails pool total, keep application and replication traffic on
-private networks, and enable TLS and authentication. A Rails connection pool
-does not make an embedded file safe for concurrent process ownership.
-
-## Migrations and releases
-
-Before a migration:
-
-1. Run the complete test suite and the adapter suite for the target Rails
-   version.
-2. Create and verify a full backup, including the WAL chain when applicable.
-3. Restore the backup into a separate staging directory and run the migration
-   against the restored copy with a representative populated dataset.
-4. Test schema dump/load, indexes, defaults, foreign keys, eager loading,
-   nested associations, joins, and application write/read smoke queries.
-
-Stop writes or use the deployment's migration lock. RubyDB fails closed when an
-already-applied migration changes checksum or disappears. Keep the pre-release
-backup and old data directory until the rollback window closes; do not delete
-or overwrite the live directory during rollback.
-
-## Operations
-
-Collect request rate/error rate/latency, active connections, WAL and checkpoint
-health, filesystem space, recovery-required acknowledgements, and replication
-received/replayed LSNs. Alert on readiness failure, repeated errors, failed
-flush/checkpoint, low disk space, excessive pool wait, authentication failures,
-and replication lag beyond the application RPO.
-
-Run `scripts/restore_drill`, the threaded and multi-process workloads, and
-`scripts/replication_failover_drill` on target-like staging infrastructure.
-Archive the Ruby version, RubyDB commit, Rails version, host resources, result
-JSON, and recovery time with the release record.
-
-## Current boundaries
-
-The adapter is not a complete PostgreSQL, MySQL, or SQLite compatibility layer.
-The tested common SQLite-style profile is documented in
-[`docs/sql/sqlite-compatibility.md`](../sql/sqlite-compatibility.md). Complex
-table rebuilds, generated columns, polymorphic references, adapter-specific
-schema features, and dialect-specific SQL require explicit validation before
-use. Automatic high-availability election is disabled; failover is an
-operator-controlled, fenced procedure described in
-[`docs/operations/failover.md`](../operations/failover.md).
-
-## Environment-based deployment
-
-The Rails application normally points at RubyDB through `config/database.yml`.
-For a production server, set `embedded: false` and map protected environment
-values to `host`, `port`, `database`, `username`, `password`, `timeout`, and
-the `ssl` hash. See the copy-paste example in
-[Rails database configuration](database-yml.md). The application connects to
-the RubyDB server endpoint; it does not open the server’s data directory.
-
-If the deployment platform provides one connection string, set
-`RUBYDB_URL` to the documented `rubydb://` or `rubydbs://` format and use the
-`url:` form in `database.yml`. Do not assume a PostgreSQL `DATABASE_URL` will
-work; RubyDB uses its own protocol and URL scheme.
-
-Deploy the RubyDB server separately with its own persistent volume and
-`config/production.yml`. Verify TLS hostname/CA validation, authentication,
-readiness, migration status, and a read/write smoke query from the same network
-path as the Rails application. Use a secret manager for credentials and never
-commit or print them.
+# Rails production guidance
+
+RubyDB can serve Rails applications that stay within the documented RubyDB SQL
+and ActiveRecord adapter surface. Validate the exact Rails, Ruby, operating
+system, schema, workload, and deployment topology before handling important
+data. The compatibility workflow currently exercises Rails 7.1, 7.2, and 8.0
+with Ruby 3.3; hosted workflow results are required before declaring a release
+combination supported.
+
+## Choose the topology
+
+An embedded database path has exclusive ownership. Use it only when one Rails
+process owns the database, such as a single-process development or controlled
+worker deployment. Do not point multiple independent Rails processes at the
+same embedded path.
+
+For multiple web/worker processes, run a separately managed RubyDB server and
+configure clients to use its network endpoint. Size the server connection
+limit for the Rails pool total, keep application and replication traffic on
+private networks, and enable TLS and authentication. A Rails connection pool
+does not make an embedded file safe for concurrent process ownership.
+
+## Migrations and releases
+
+Before a migration:
+
+1. Run the complete test suite and the adapter suite for the target Rails
+   version.
+2. Create and verify a full backup, including the WAL chain when applicable.
+3. Restore the backup into a separate staging directory and run the migration
+   against the restored copy with a representative populated dataset.
+4. Test schema dump/load, indexes, defaults, foreign keys, eager loading,
+   nested associations, joins, and application write/read smoke queries.
+
+Stop writes or use the deployment's migration lock. RubyDB fails closed when an
+already-applied migration changes checksum or disappears. Keep the pre-release
+backup and old data directory until the rollback window closes; do not delete
+or overwrite the live directory during rollback.
+
+## Operations
+
+Collect request rate/error rate/latency, active connections, WAL and checkpoint
+health, filesystem space, recovery-required acknowledgements, and replication
+received/replayed LSNs. Alert on readiness failure, repeated errors, failed
+flush/checkpoint, low disk space, excessive pool wait, authentication failures,
+and replication lag beyond the application RPO.
+
+Run `scripts/restore_drill`, the threaded and multi-process workloads, and
+`scripts/replication_failover_drill` on target-like staging infrastructure.
+Archive the Ruby version, RubyDB commit, Rails version, host resources, result
+JSON, and recovery time with the release record.
+
+## Current boundaries
+
+The adapter is not a complete PostgreSQL, MySQL, or SQLite compatibility layer.
+The tested common SQLite-style profile is documented in
+[`docs/sql/sqlite-compatibility.md`](../sql/sqlite-compatibility.md). Complex
+table rebuilds, generated columns, polymorphic references, adapter-specific
+schema features, and dialect-specific SQL require explicit validation before
+use. Automatic high-availability election is disabled; failover is an
+operator-controlled, fenced procedure described in
+[`docs/operations/failover.md`](../operations/failover.md).
+
+## Environment-based deployment
+
+The Rails application normally points at RubyDB through `config/database.yml`.
+For a production server, set `embedded: false` and map protected environment
+values to `host`, `port`, `database`, `username`, `password`, `timeout`, and
+the `ssl` hash. See the copy-paste example in
+[Rails database configuration](database-yml.md). The application connects to
+the RubyDB server endpoint; it does not open the server’s data directory.
+
+If the deployment platform provides one connection string, set
+`RUBYDB_URL` to the documented `rubydb://` or `rubydbs://` format and use the
+`url:` form in `database.yml`. Do not assume a PostgreSQL `DATABASE_URL` will
+work; RubyDB uses its own protocol and URL scheme.
+
+Deploy the RubyDB server separately with its own persistent volume and
+`config/production.yml`. Verify TLS hostname/CA validation, authentication,
+readiness, migration status, and a read/write smoke query from the same network
+path as the Rails application. Use a secret manager for credentials and never
+commit or print them.

data/docs/rails/troubleshooting.md

@@ -1,18 +1,18 @@
-# Rails troubleshooting
-
-## Connection or ownership errors
-
-Confirm the database path exists, the process has permission, and no second
-embedded owner is using it. Multiple Rails processes must use server mode.
-
-## Migration failures
-
-Stop writes, preserve the database and WAL, inspect migration status and
-checksums, and retry only after restoring a verified staging copy. Do not delete
-WAL or overwrite the original directory.
-
-## Query failures
-
-Capture the RubyDB version, Rails/Ruby versions, generated SQL without secrets,
-and a minimal schema/query reproduction. Check the documented SQL and adapter
-compatibility surface before changing application behavior.
+# Rails troubleshooting
+
+## Connection or ownership errors
+
+Confirm the database path exists, the process has permission, and no second
+embedded owner is using it. Multiple Rails processes must use server mode.
+
+## Migration failures
+
+Stop writes, preserve the database and WAL, inspect migration status and
+checksums, and retry only after restoring a verified staging copy. Do not delete
+WAL or overwrite the original directory.
+
+## Query failures
+
+Capture the RubyDB version, Rails/Ruby versions, generated SQL without secrets,
+and a minimal schema/query reproduction. Check the documented SQL and adapter
+compatibility surface before changing application behavior.

data/docs/release.md

@@ -1,26 +1,26 @@
-# RubyDB release checklist
-
-The release workflow is intentionally fail-closed. A maintainer must configure
-these protected GitHub Actions secrets:
-
-- `RUBYGEMS_API_KEY`: a RubyGems API key scoped to the gem
-- `RUBYDB_GEM_SIGNING_KEY_B64`: base64-encoded private signing key
-- `RUBYDB_GEM_CERT_B64`: base64-encoded certificate chain
-
-Create the signing key and certificate outside the repository, store them in a
-secret manager, and rotate them according to the organization's key policy.
-Never commit the private key or write it to a persistent workspace.
-
-To publish, review `CHANGELOG.md`, commit the version, create a matching tag,
-and let `.github/workflows/release.yml` run the full suite, build the gem,
-verify its SHA-512 checksum, attest provenance, sign it, and publish it. A
-local artifact check is:
-
-```sh
-ruby scripts/release_check
-ruby scripts/release
-```
-
+# RubyDB release checklist
+
+The release workflow is intentionally fail-closed. A maintainer must configure
+these protected GitHub Actions secrets:
+
+- `RUBYGEMS_API_KEY`: a RubyGems API key scoped to the gem
+- `RUBYDB_GEM_SIGNING_KEY_B64`: base64-encoded private signing key
+- `RUBYDB_GEM_CERT_B64`: base64-encoded certificate chain
+
+Create the signing key and certificate outside the repository, store them in a
+secret manager, and rotate them according to the organization's key policy.
+Never commit the private key or write it to a persistent workspace.
+
+To publish, review `CHANGELOG.md`, commit the version, create a matching tag,
+and let `.github/workflows/release.yml` run the full suite, build the gem,
+verify its SHA-512 checksum, attest provenance, sign it, and publish it. A
+local artifact check is:
+
+```sh
+ruby scripts/release_check
+ruby scripts/release
+```
+
 The local command does not publish unless `RUBYDB_PUBLISH=1` and
 `GEM_HOST_API_KEY` are explicitly set. Publishing also requires the release
 version to be supplied when you are not running from a matching Git tag.
@@ -28,7 +28,7 @@ version to be supplied when you are not running from a matching Git tag.
 On Windows PowerShell, run this from the repository root:
 
 ```powershell
-$env:RUBYDB_RELEASE_VERSION = "0.1.0"
+$env:RUBYDB_RELEASE_VERSION = "0.1.5"
 $env:RUBYDB_PUBLISH = "1"
 $env:GEM_HOST_API_KEY = "YOUR_RUBYGEMS_API_KEY"
 ruby scripts/release
@@ -49,7 +49,7 @@ file automatically. Keep the file private and never commit it.
 On macOS/Linux, use:
 
 ```sh
-RUBYDB_RELEASE_VERSION=0.1.0 \
+RUBYDB_RELEASE_VERSION=0.1.5 \
 RUBYDB_PUBLISH=1 \
 GEM_HOST_API_KEY="YOUR_RUBYGEMS_API_KEY" \
 ruby scripts/release

data/docs/server/architecture.md

@@ -1,10 +1,10 @@
-# Server architecture
-
-The server owns one embedded engine and exposes client sessions over the RubyDB
-protocol. A listener accepts bounded connections, a connection pool tracks
-active sessions, and a worker pool handles requests under configured limits.
-
-Lifecycle shutdown stops acceptance, closes connections, joins workers, flushes
-the engine, and removes the PID file. Multiple application processes should
-share the server, not the embedded path. Use health/readiness and Prometheus
-metrics to decide whether to route traffic.
+# Server architecture
+
+The server owns one embedded engine and exposes client sessions over the RubyDB
+protocol. A listener accepts bounded connections, a connection pool tracks
+active sessions, and a worker pool handles requests under configured limits.
+
+Lifecycle shutdown stops acceptance, closes connections, joins workers, flushes
+the engine, and removes the PID file. Multiple application processes should
+share the server, not the embedded path. Use health/readiness and Prometheus
+metrics to decide whether to route traffic.

data/docs/server/authentication.md

@@ -1,10 +1,10 @@
-# Server authentication
-
-Configure authentication explicitly for production. Password/SCRAM-SHA-256,
-authorization, peer replication tokens, bounded frames, TLS, and server
-signature verification are covered by the security suite.
-
-Use high-entropy credentials from a secret manager. Bind to a private address,
-enable TLS 1.2 or newer, validate the CA and hostname, and rotate credentials
-through a drain/reconnect procedure. Missing or incomplete authentication
-configuration must fail startup rather than silently downgrade security.
+# Server authentication
+
+Configure authentication explicitly for production. Password/SCRAM-SHA-256,
+authorization, peer replication tokens, bounded frames, TLS, and server
+signature verification are covered by the security suite.
+
+Use high-entropy credentials from a secret manager. Bind to a private address,
+enable TLS 1.2 or newer, validate the CA and hostname, and rotate credentials
+through a drain/reconnect procedure. Missing or incomplete authentication
+configuration must fail startup rather than silently downgrade security.

data/docs/server/configuration.md

@@ -1,16 +1,16 @@
-# Server configuration
-
-Run with an explicit database and resource limits:
-
-```sh
-rubydb-server --host 127.0.0.1 --port 7432 --database /var/lib/rubydb/app.rdb
-```
-
-Production configuration should set host/port, data and log directories, PID
-file, max connections, worker and queue limits, request/frame size, read/write
-and idle timeouts, authentication, and TLS. Keep configuration outside source
-control when it contains secrets.
-
-Validate configuration before startup and monitor readiness, active/rejected
-connections, request errors, disk space, WAL/checkpoint state, and recovery-
-required acknowledgements.
+# Server configuration
+
+Run with an explicit database and resource limits:
+
+```sh
+rubydb-server --host 127.0.0.1 --port 7432 --database /var/lib/rubydb/app.rdb
+```
+
+Production configuration should set host/port, data and log directories, PID
+file, max connections, worker and queue limits, request/frame size, read/write
+and idle timeouts, authentication, and TLS. Keep configuration outside source
+control when it contains secrets.
+
+Validate configuration before startup and monitor readiness, active/rejected
+connections, request errors, disk space, WAL/checkpoint state, and recovery-
+required acknowledgements.

data/docs/server/connection-pooling.md

@@ -1,10 +1,10 @@
-# Connection pooling
-
-The server limits active connections and queues work through its connection and
-worker pools. Rails/client pool totals must fit below the server limit with
-headroom for administrative and replication traffic.
-
-Set finite acquisition, read, write, idle, and query timeouts. Alert on pool
-wait, rejected connections, request failures, and saturation. Load-test pool
-behavior with the multi-process and production soak harness; a successful local
-connection does not prove capacity under application traffic.
+# Connection pooling
+
+The server limits active connections and queues work through its connection and
+worker pools. Rails/client pool totals must fit below the server limit with
+headroom for administrative and replication traffic.
+
+Set finite acquisition, read, write, idle, and query timeouts. Alert on pool
+wait, rejected connections, request failures, and saturation. Load-test pool
+behavior with the multi-process and production soak harness; a successful local
+connection does not prove capacity under application traffic.

data/docs/server/deployment.md

@@ -1,10 +1,10 @@
-# Server deployment
-
-Run RubyDB under a dedicated least-privilege service account with protected
-data, WAL, logs, TLS, and backup paths. Use the packaged systemd unit or the
-non-root Docker image, private networking, TLS, authentication, resource
-limits, health checks, and persistent storage.
-
-Before accepting traffic, run status/readiness, smoke queries, backup/restore,
-workload, and recovery checks. Keep one writable primary, fence before
-promotion, and retain the previous data directory during upgrades.
+# Server deployment
+
+Run RubyDB under a dedicated least-privilege service account with protected
+data, WAL, logs, TLS, and backup paths. Use the packaged systemd unit or the
+non-root Docker image, private networking, TLS, authentication, resource
+limits, health checks, and persistent storage.
+
+Before accepting traffic, run status/readiness, smoke queries, backup/restore,
+workload, and recovery checks. Keep one writable primary, fence before
+promotion, and retain the previous data directory during upgrades.