Will UUID as primary key in PostgreSQL give bad index performance?

Question

I have created an app in Rails on Heroku using a PostgreSQL database.

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.

I realised after implementing the sync engine on the server side that this leads to performance issues when needing to map between uuid<->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).

I'm now thinking about switching to only using UUID as primary key making the writing and reading much simpler and faster.

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?

I already have a UUID column today so storage wise it will be better because I drop the regular id column.

Is the id field used as a foreign key by any other relation in the database? Are you only keeping this id field around because you believe that the PRIMARY KEY should be a serial type for the reasons you've described? — Joshua Berry
Clustering by synthetic primary key is only a benefit if you have a frequent access path that wants to query a range of these pkey values -- that's pretty rare in real world . UUID is a perfectly fine type for primary key, it is compact enough (16bytes) and faster in comparison op than text type. — dbenhur
@Joshua The id fields are used as foreign keys, the UUID fields are only used as regular fields used to reference relationships when communicating (thats the need to translate between them all the time) — thejaz
@dbenhur But is the primary key in PostgreSQL clustered by default? Will I experience any indexing performance issues if I just add a random UUID as primary key and go? Do you have any experience of using UUID as primary key in Rails? — thejaz

hgmnz hgmnz · Accepted Answer · 2012-10-30T19:54:28

(I work on Heroku Postgres)

We use UUIDs as primary keys on a few systems and it works great.

I recommend you use the uuid-ossp extension, and even have postgres generate UUIDs for you:

heroku pg:psql
psql (9.1.4, server 9.1.6)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.

dcvgo3fvfmbl44=> CREATE EXTENSION "uuid-ossp"; 
CREATE EXTENSION  
dcvgo3fvfmbl44=> CREATE TABLE test (id uuid primary key default uuid_generate_v4(), name text);  
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table "test"
CREATE TABLE  
dcvgo3fvfmbl44=> \d test
                 Table "public.test"  
Column | Type |              Modifiers              
--------+------+-------------------------------------  
id     | uuid | not null default uuid_generate_v4()  name   | text |  
Indexes:
    "test_pkey" PRIMARY KEY, btree (id)

dcvgo3fvfmbl44=> insert into test (name) values ('hgmnz'); 
INSERT 0 1 
dcvgo3fvfmbl44=> select * from test;
                  id                  | name  
--------------------------------------+-------   
 e535d271-91be-4291-832f-f7883a2d374f | hgmnz  
(1 row)

EDIT performance implications

It will always depend on your workload.

The integer primary key has the advantage of locality where like-data sits closer together. This can be helpful for eg: range type queries such as WHERE id between 1 and 10000 although lock contention is worse.

If your read workload is totally random in that you always make primary key lookups, there shouldn't be any measurable performance degradation: you only pay for the larger data type.

Do you write a lot to this table, and is this table very big? It's possible, although I haven't measured this, that there are implications in maintaining that index. For lots of datasets UUIDs are just fine though, and using UUIDs as identifiers has some nice properties.

Finally, I may not be the most qualified person to discuss or advice on this, as I have never run a table large enough with a UUID PK where it has become a problem. YMMV. (Having said that, I'd love to hear of people who run into problems with the approach!)

Will UUID as primary key in PostgreSQL give bad index performance?

2 Answers