---
title: Rationalizing User Data
description: "Like how do I approach storing sensitive user data in Bubble?"
date: 2025-01-07T21:34:12-08:00
draft: false
category: article
---


This is a stream of concious post where I go through the process of figuring out 
how I am going to store user data in my [bubble project](https://git.shockrah.xyz/shockrah/bubble)

Schema for the users can be found here: [link](https://git.shockrah.xyz/shockrah/bubble/src/branch/main/db/setup-tables.sql)


# Pre-requisites

* Using Postgres 
* Hashed and salted passwords

# User ID's

By default I was going to use regular ID's that increment on each insertion.
Considering using some form of UUID's for the sake of a slight increase in sec.
Even though this isn't a major form of security, every layer towards
better security counts, and I see this as one more layer to add.


UUID's tend to suffer from indexing issues but later versions of UUID seem to
have this figured out.

After some reading v7 seems like the move.

* Time based meaning sorting ( and thus searching ) is reasonably performant
* Sufficient entropy for this case ( 74 bits ). We want ****some* entropy but also
don't want to nuke performance
* While we want to make it harder to guess, aiming for "unguessable" is just not
reasonable. UUIDv4 is best for that but compromises performance so hard it's not
worth it in the grand scheme of things


IDK v7 feels like a good middle ground for security + performance for the **user id**

