title: Will UUID as primary key in PostgreSQL give bad index performance?
body: <p>I have created an app in Rails on Heroku using a PostgreSQL database.</p>
  
  <p>It has a couple of tables designed to be able to sync with mobile devices where data can be created on different places. Therefor I have a uuid field that is a string storing a GUID in addition to an auto increment primary key. The uuid is the one that is communicated between the server and the clients.</p>
  
  <p>I realised after implementing the sync engine on the server side that this leads to performance issues when needing to map between uuid&lt;->id all the time (when writing objects, I need to query for the uuid to get the id before saving and the opposite when sending back data).</p>
  
  <p>I'm now thinking about switching to only using UUID as primary key making the writing and reading much simpler and faster.</p>
  
  <p>I've read that UUID as primary key can sometimes give bad index performance (index fragmentation) when using clustered primary key index. Does PostgreSQL suffer from this problem or is it OK to use UUID as primary key?</p>
  
  <p>I already have a UUID column today so storage wise it will be better because I drop the regular id column.</p>