As we discussed, PostgreSQL's streaming replication is asynchronous; this has the potential of data loss. If a transaction commits on the primary server and crashes before committing to the standby server, it causes data loss. This is because of transaction delay: the more the transaction delays, the more the data loss. But in case of synchronous replication commits, wait till commits have been written on the primary and standby servers. This technique reduces the chance of data loss if both standalone and primary servers crash at the same time, because it is waiting for confirmation from both the primary and standby server. This provides a high level of durability but introduces response time delay, because of confirmation from both servers. But this response time delay happens only in the case of write only top--level transactions and is not applicable on read-only and sub-transactions. Therefore, it requires planning to avoid such delays, even if it's only for write transactions. It's a bad plan to specify a synchronous replication option for each and every transaction. Admin should categorize the data and specify the synchronous replication option only for the most important information.