Hello. Appreciate your question. I think that this is a good use case for the Repository Pattern.

In your case, this might look something like this:

• TicketRepository, ScheduleRepository and TimerRepository interfaces which have their functions like create(), read(), update(), delete(), complexQueryByManyParams() etc. All your domain code should expect and operate on these interfaces.
• FirebaseTicketStore, FirebaseScheduleStore, FirebaseTimerStore classes which implement the respective interfaces. All your logic that relates to Firebase should be encapsulated here.
• You can later safely do things like swap out a FirebaseTicketStore with a MysqlTicketStore

You can consult the Design Patterns / Gang of Four book for more details

Off topic, but personally I don't feel you should worry too much about having to change the database in the future. I have rarely seen it happen in my career.

I would generally say to stick to approach 1, as much as that stinks. Your observation about approach 2 especially compounds once you start to look at more complex operations that need to be optimized based on how the underlying DB works. Care still needs to be taken in approach 1 to avoid non-optimal operations, but at least you have the freedom to rework individual methods on your DatabaseProxy instead of all FirebaseProxy methods using your underlying CRUD operations.

One of the fastest ways I get people thinking about this is asking

How would you implement a listTimers or listTickets API with cursors?

Generally that's complex enough to bring out pain points.

Look into "Hexagonal Architecture", similar/synonymous to clean/ports&adapters/onion. As someone else said, combine it with "Repository" pattern.

I use hex arch in front end and back end. It adds a couple of layers, but it makes apps much easier to test and maintain.