3 ms·
With MongoDB's license there is another reason to migrate away from it. I migrated an app from MongoDB to postgres. I ended up just using a varchar to store the
by benatkin 7y ago
With MongoDB's license there is another reason to migrate away from it. I migrated an app from MongoDB to postgres. I ended up just using a varchar to store the IDs. The Mongo style IDs are in addition to an integer primary key, so joins happen with integers, but every time a user is shown the IDs, in the URLs, it's a BSON ID. It hasn't caused any issues, performance or otherwise, but there are thousands rather than millions of records. It's because of Django, not postgres, that I decided to use varchars to store the IDs rather than bytes or integers. Django is flexible but there are always tradeoffs from going outside the framework. Finally, and this is my favorite thing about how I went about it: all BSON ids have the column name of "id" and all integer primary keys have the column name of "pk", whether or not they have a BSON ID (through tables don't need their IDs exposed to the API).
- ldng 7y agoPostgreSQL do have a variable unlimited length datatype : text. AFAIK, Varchar is internally a subtype that bound the text type. So in extreme situations you might even get a very slight performance advantage using text instead of varchar.
- pkrefta 7y agoThis is exactly how it is. You can find confirmation in Postgres docs [1] [1] https://www.postgresql.org/docs/9.1/datatype-character.html https://www.postgresql.org/docs/9.1/datatype-character.html
- benatkin 7y agoInteresting. When is there an advantage of using varchar in postgres, other than limiting the field length?
- nicoburns 7y agoI think never, except if you want your SQL to be portable to other dbs.