consider huge database refactor to postgres

[chase-moskal]

okay, the nature of this issue changed

here were my reasons i thought of switching to postgres, and why i decided not

• postgres will be generally faster
  • we're not having problems with speed
• postgres has transactions, that will prevent data corruption and race conditions
  • yes, but mongo@4 is soon to introduce transactions
• we need to launch xiome with the right database stuff, because migrations=scary
  • we weren't able to find a suitable system to automate or systematize postgres schema migrations (i can't quite figure out how to integrate prisma with our cicd, though maybe its possible), which means we'll have to do them manually anyways, which means a future migration from mongodb isn't really any more painful than any schema refactors we'll need

so that pretty much negates the urgency of any reason to refactor for postgres

plus, a sql refactor would require tons of big-brain energy over how we're going to declaratively specify schema structure in harmony with our typescript types, we'd have to create some sophisticated schema tooling. too much effort for too little value at this time

[chase-moskal]

so i created the concept of damnedb which could be a successor to dbby

i intended to make damnedb now to leverage mongodb's new transactions, but it's a no-go, it requires mongodb@4 which isn't quite ready -- we'll wait

in the meantime, i made DamnedId which i could integrate into dbby for ids to work on #3

closing this issue