Scale pragmatically. Understand your data, choose technologies wisely, and design for future growth without overengineering. Keep services stateless, use NoSQL only when truly needed, and prioritize solving current problems while preparing for future scaling. The goal is to delay scaling as long as possible while staying ready for when it becomes necessary.
TBD: diagram 1. Create replication slot This way, you preserve WAL (new changes) from being deleted. This would also create a snapshot of a current state. Snapshot can be exported, or reused in current transaction. 2. Import existing data. In replication only changes are streamed. Current state needs to be backuped manually. Physical replication: There is a mechanism to make a backup of a running server, called “base backup”. You need to specify snapshot name, to avoid data races....
Write-Ahead Log docs As it states in name, it’s log that’s written BEFORE any actual changes are made. The most important thing, WAL can be replayed and will always give same result. Being compact binary representation of operations and minimal data used in them, gives us few functions: Ability to restore after crash Replicate data by transfering log segments and replaying them in replica nodes. Replacing multiple random writes with single sequential write....
The power of sequential WAL decoding.