# Pros and Cons of UUID
> Note: [uuid_v7][1] is time based uuid instead of random. So you can
> use it to order by creation date and solve [some performance issues
> with db inserts][2] if you do really many of them.
**Pros**:
- can be generated on api level (good for distributed systems)
- hides count information about entity
- doesn't have limit 2,147,483,647 as 32-bit int
- removes layer of errors related to passing one entity id `userId: 25` to get another `bookId: 25` accidently
- more friendly graphql usage as `ID` key
**Cons**:
- 128-bit instead 32-bit int (slightly bigger size in db and ~40% bigger index, around ~30MB for 1 million rows), should be a minor concern
- can't be sorted by creation (**can be solved with uuid_v7**)
- [non-time-ordered UUID versions such as UUIDv4 have poor database index locality][3] (**can be solved with uuid_v7**)
---
# URL usage
Depending on app you may care or not care about url. If you don't care, just use `uuid` as is, it's fine.
If you care, then you will need to decide on url format.
Best case scenario is a use of unique slug if you ok with never changing it:
```
[To see links please register here]
```
If your url is generated from title and you want to change slug on title change there is a few options. Use it as is and query by uuid (slug is just decoration):
```
[To see links please register here]
```
Convert it to base64url:
- you can get uuid back from `AYEWXcsicACGA6PT7v_h3A`
- `AYEWXcsicACGA6PT7v_h3A` - 22 characters
- `035a46e0-6550-11dd-ad8b-0800200c9a66` - 36 characters
```
[To see links please register here]
```
Generate a unique [short 11 chars][4] length string just for slug usage:
```
[To see links please register here]
[To see links please register here]
```
If you don't want uuid or short id in url and want only slug, but do care about seo and user bookmarks, you will need to redirect all request from
```
[To see links please register here]
```
to
```
[To see links please register here]
```
this will add additional complexity of managing slug history, adding fallback to history for all queries where slug is used and redirects if slugs doesn't match
[1]:
[To see links please register here]
[2]:
[To see links please register here]
[3]:
[To see links please register here]
[4]:
[To see links please register here]