backtest-kit PostgreSQL + Redis + Pgpool replaces the default file-basedDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/theonetrade/backtest-kit-redis-postgres-pgpool-docker/llms.txt
Use this file to discover all available pages before exploring further.
./dump/ persistence of backtest-kit with a robust dual-store architecture — PostgreSQL as the source of truth and Redis as an O(1) lookup cache — packaged with Docker Compose for one-command deploys. It ships 16 fully atomic persist adapters that implement the complete IPersist*Instance contract, ensuring every writeXData call is immediately visible to the next readXData even on a replicated cluster.
Quickstart
Spin up the infrastructure and run your first backtest in minutes.
Architecture Overview
Understand how PostgreSQL, Redis, and Pgpool-II work together.
Persist Adapters
Explore all 16 adapter implementations and their table schemas.
Configuration
Reference for all environment variables and Docker Compose options.
Why this project?
backtest-kit’s default persistence writes to local files. This works on a single machine, but breaks down when you need durability, concurrent access, or a replicated read tier. This project solves all three:Atomic Upserts
Every write uses
INSERT … ON CONFLICT … DO UPDATE … RETURNING * — no separate read-then-write race condition.O(1) Redis Cache
Redis stores only the UUID primary key per context. Steady-state reads hit Redis + a PK lookup — constant time.
Replica Cluster in Dev
A real Pgpool-II cluster (1 primary + 2 replicas) catches stale-read bugs before they reach production.
Get started
Configure environment
Copy
.env.example to .env and adjust the connection strings if your services run on different hosts:First boot of the Pgpool cluster takes 60–90 seconds while the two streaming replicas clone from the primary. The healthcheck retries for up to 2 minutes — wait for all containers to report healthy before running strategies.