Keeping Firebase Auth
Removing Firebase persistence left authentication in place, which made the migration smaller than an all-or-nothing platform move.
A retrospective from the development history. Published .
The December 8 change deleted Firebase persistence and snapshot services. Firebase Auth stayed in the application.
That small distinction is the useful part of the migration. “We moved off Firebase” would be an inaccurate description of the result. The application changed where it kept its content while retaining the service it used for signing people in.
Firebase had been involved in several jobs. Authentication was already present in the April 2025 history. Persistence work followed, including saving and loading canvas content. By December, the persistence direction had changed to Postgres and object storage, and the old Firebase persistence code could be removed.
Those dates show the code evolving. They don’t establish that the migration took one day or that production changed at the exact time of a commit. There are several December 8 changes around the work, followed by the explicit removal of the old persistence services.
Firebase Authentication provides sign-in capabilities. Cloud Firestore provides a document database. They are separate product capabilities even when an application adopts them together and they appear under the same console.
Treating that shared branding as one architectural decision would have made the move broader. Replacing a place to save documents already creates enough questions. Adding a new sign-in system would introduce a different set of questions about existing accounts, providers and recovery.
There is a useful way to make the scope concrete. Imagine an ordinary notes application with account sign-in, a collection of saved notes and a folder of attachments. A persistence migration can change how notes and attachments are stored while leaving the sign-in experience alone. The notes must still belong to the intended accounts, but the account provider needn’t change just because the storage does.
The same distinction matters to a person using the product. They care that they can return, sign in and find their work. A new database doesn’t become a successful migration merely because the application can write a fresh note to it.
Reading existing work deserves its own check. So does updating a previously saved document, reopening an attachment and deleting something that has data in more than one place. A blank account on a fresh install exercises a much easier path than an account that already has history.
Retaining authentication doesn’t make those checks automatic. It preserves one part of the experience while the data work changes underneath. The relationship between an account and its saved work still has to remain correct.
It also doesn’t mean authentication can answer every access question. Signing in identifies the person. Whether that person may read or change a particular document remains an application responsibility. Moving storage doesn’t remove that distinction, and keeping the auth provider doesn’t settle it.
The deletion commit was significant because it made the intended result visible in the codebase. Old persistence helpers and snapshot services were removed instead of being left as alternative-looking ways to save content. The Auth integration remained. That gave later maintenance a clearer starting point than a vague promise that some Firebase code was obsolete.
A platform can be useful for one job after another part has stopped fitting the application. Keeping that distinction visible made it possible to remove a substantial amount of persistence code without also turning the change into an account-system rewrite.