Generalized snapshot isolation extends snapshot isolation as used in Oracle and other databases in a manner suitable for replicated databases. While (conventional) snapshot isolation requires that transactions observe the ``latest'' snapshot of the database, generalized snapshot isolation allows the use of ``older'' snapshots, facilitating a replicated implementation. We show that many of the desirable properties of snapshot isolation remain. In particular, under certain assumptions on the transaction workload the execution is serializable. An implementation of generalized snapshot isolation can choose which past snapshot it uses. An interesting choice for a replicated database is prefix-consistent snapshot isolation, in which the snapshot contains at least all the writes of locally committed transactions. As an instance of generalized snapshot isolation, it inherits all of its properties. In addition, read-only transactions never block, and consecutive transactions submitted in a single workflow on a particular replica observe the updates of their predecessors in the workflow. We present two implementation strategies of prefix-consistent snapshot isolation. We conclude with an analytical performance model of one of the implementations, bringing out the benefits, in particular reduced latency for read-only transactions, and showing that the potential downsides, in particular the change in abort rate of update transactions, are limited.