I’m going to try and answer this as best I can, piece by piece:
What is the reason databaseId field is deprecated?
In the world of GraphQL,
databaseId represents an internal concern that we’d prefer not to expose.
databaseIds are not used for query lookups, nor do we ever intend them to be (again, I’m referring just to the world of GraphQL ). We’d prefer for our users to not depend on them always being present, because ideally, they won’t be. Instead, we’d like to make every GraphQL object accessible by its Relay ID or a vanity field like a Pull Request’s
But that gets us to reality . Large parts of the GitHub application rely on
databaseIds for references, and as you mentioned, it’s hugely beneficial in order to map the REST API to the GraphQL API with these IDs. That’s why they’re currently present. In the future we may take an inverse approach and expose the Relay IDs in the REST API.
I’d like to use the databaseId (numeric ID) when storing a local reference of a GitHub user in my own RDBMs.
I see no problem with that for now, but as the GraphQL API gets closer to production, I think it would be wise to also store the Relay ID as that field is a core concept to our GraphQL implementation and will never be deprecated.
I hope this helps answer your original question.