Skip to content

Generate uuids optimized for use as primary keys in relational databases.

License

Notifications You must be signed in to change notification settings

pckilgore/combuuid

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

12 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

combuuid

status tests

Generates v4 github.com/google/uuids optimized for use as primary keys in relational databases like PostgreSQL, MySQL, MariaDB, and SQLite.

These combuuids sacrifice two bytes of collision resistance to improve insertion speed and avoid WAL-amplification by adding a 2 bytes of sequential data as the most significant bits of the uuid. These bits increase monotonically every 60 seconds (default) until wrapping over after 65535 periods have elapsed, which greatly improves insertion speed into an index b-tree over random ids.

See Sequential UUID Generators by Tomas Vondra for more details, explaination, and benchmarks of insertion performance and WAL sizes. See also The Cost of GUIDs as Primary Keys by Jimmy Nilsson from which the name COMBs originates.

Small, optimized, fuzz tested and benchmarked for minimal overhead over uuid (only a few ns overhead beyond retreiving system time):

combuuid benchmarks vs. google/uuid

Stop. Do you need this?

This is an optimization that incurs a small time cost over generating regular v4 uuids. You should use regular uuids if:

  • You're using a read-heavy workload.
  • You're not using relational database.
  • You're not storing UUIDs as your primary key in that relational database.
  • You absolutely need to rely on collision resistance of universally unique ID generation, not just application unique ID generation.
    • For example, you're interacting with another UUID-generating system that you do not have control over, and your application cannot reasonably recover from errors due to UNIQUE contraint violations when coordinating between systems that expect to share UUIDs.
    • In general:
      • Monolith: Probably fine.
      • Serverless: Avoid (and you're probably using a NoSQL database anyways).

Contributing

Contributions welcome. So is just copying the whole damn thing into your codebase and tweaking. I only would say that I appreciate a star or comment in thanks.

About

Generate uuids optimized for use as primary keys in relational databases.

Resources

License

Code of conduct

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages