Single-node RF=1 yugabyted or pinned three-node Docker Compose cluster for repeatable YugabyteDB development?

We are standardizing a local YugabyteDB development environment that every engineer can tear down and recreate identically. The goal is a scripted setup where schema migrations and seed data apply cleanly on every fresh start, and where the database version is pinned so upgrades never surprise us mid-sprint.

Two documented options are on the table. The first is a single-node yugabyted instance started with a dedicated --base_dir and replication factor 1, which boots fast and keeps state isolated in one directory we can wipe. The second is a three-node RF=3 cluster via the Docker Compose setup, with the release image tag pinned and per-node volumes either mounted or recreated per run. Our application connects over YSQL on port 5433 using a standard PostgreSQL driver.

The tension is parity versus cost: RF=1 never exercises replication, tablet placement, or node failover, so it may hide behavior our production RF=3 cluster exhibits, while RF=3 is slower to provision and heavier on laptops. We also need to decide whether mounted volumes help or hurt repeatability, since stale cluster metadata could survive between runs.

Which topology do teams typically pick for development when production runs RF=3, and what breaks in practice when testing only against RF=1? Should repeatability favor wiping data directories on every start, or preserving volumes? Does pinning the image tag fully protect against on-disk format changes across upgrades?