When you restore a database you have all the information on it packed, with no empty space between rows (or in indices), unless some specific settings are in place (basically:
FILLFACTOR for tables and
FILLFACTOR for indices).
On the other hand, when your database has been in use for some time, and you've had your share of inserts, updates and deletes, free unused space will appear. This is because of the way PostgreSQL and Multiversion Concurrency Control, a.k.a. MVCC work. MVCC allows for less lockings, which basically means you save time. But you pay a price in terms of space:
UPDATE is equivalent to an
INSERT together with a
DELETE, with the overhead (at least in terms of space used) associated to both.
- When you have several transactions running, and every one is
DELETEing, you have simultaneously several copies of every row involved.
- The space allocated to these row versions won't be freed immediately after commit, and for a while, will be unused space within the files where your table data (and indexes) is being stored.
Autovacuum takes care of this space being made reusable by default, or you could have some specific procedure for routine vacuuming.
This fact already can explain the size change.
Optimizations between versions probably also took place; and can explain further improvements. Optimizations could also have been made for speed and not for size, and the actual size could actually grow from one version to the next. I really don't know the specifics to be able to tell; although the comment from @Erwin states that both changes making your tables shrink and changes making your tables bloat (grow) have taken place since version 8.3.
To distinguish between the two effects, if you're curious, you could just, as @Jack Douglas suggests, restore your database on 8.3. It will most probably shrink in size. If it shrinks to less than 151 MB (a size smaller that what you get with 9.4 version), then the removal of unused space made your DB shrink, and the version change actually made your DB grow.
For a better understanding of MVCC, look at Bruce Momjian's presentation.