I'm having bad experiences with offline cache of Firebase in an app made with Flutter.

• Local cache is not updated after its backend data is modified if the data is filtered out by the modification. ¹
  • e.g. If documents are fetched with the filter for only "status: pending" and then the status field of some of the docs is changed to "done" via an operation outside the app, the next fetch still contains the same documents including "status: done".
• The same thing happens for documents against security rules.
• The app still uses local cache even if it is set to limit the source to "server".
  • Setting persistenceEnabled to false resolves the issue.

This unexpected behaviours are dangerous and have made me scary. It is like a dream feature that we can use Supabase offline, but it easily becomes a nightmare unless it is implemented extremely carefully.

I'm really worried that I may have to go through the similar bad experiences with Supabase too. I'd prefer it optional (i.e. disabled by default, or a separate package only for those who want it).

FYI @kiwicopple just added an update to his original comment above

Thanks for the update.

I don't see the problem with having to have an "updated_at" column. It seems like a small obstacle and is something that I think has also been asked for for some time, and could be a default like the "created_at" column.

Databases that would like to switch on "offline-first", could automatically have the column added after confirmation.

(You might also want to add @marceljuenemann 's rxdb-supabase to the list, and note the difference between supabase's example and his module.)

@marceljuenemann 's rxdb-supabase 🙏 worked well for me, I haven't encountered any major bumps (yet) - though to be fair my application is fairly simple: https://github.com/visiongeist/hayati-journal

The way I see it, it's impossible for Supabase to implement offline support correctly. The reason is that Supabase basically exposes all of Postgres' API surface, and it's impossible to implement all those features like stored procedures, triggers, constraints etc. in an offline version. The reason Firebase can work offline is because it has a lot less functionality and the API surface was designed with offline support in mind from the beginning.

Obviously you can try to not use all the features that Supabase offers and then work with libraries like the rxdb-supabase I built. But IMO for Supabase to say "here's an offline mode, but make sure you don't use our features X, Y, Z" would be a horrible product that would lead to so much confusion.

What I would love to see though is a new offline-first product that is built on top of Supabase, but has a more limited API (like Firebase). I don't think this would be too hard to implement for Supabase or a third party

@ciriousjoker Você pode ser mais específico, com relação a gdpr ?

FWIW firebase does essentially what you describe, but includes a flag in future queries indicating whether the result is coming from the local cache or the real database

Yes, I will implement the INSERT, DELETE and UPDATE sync. I will create 3 hive's boxes with that SQL instruction. When modify the database without internet, it will add the map to one of three boxes. After, the internet has restored we going to send the change to supabase.

@seel-channel how is that working these days? do you have a link to a repo to check out?
thx

@raywalz ICYMI: PowerSync-Supabase integration is now available, which provides offline-first for Supabase with initial support for Flutter: https://docs.powersync.co/integration-guides/supabase-+-powersync

@cahofmeyr Powersync isn't a great option. It forces us to sign up and comply with their free limits (or pay), while all we want is to cache data on the user's device

@agordeev PowerSync keeps a local copy of (a subset of) the database in sync continuously, allowing you to do all your queries and updates offline - that's why it needs the additional service.

If all you need is some data caching, PowerSync may be overkill, and you can cache data manually in a local SQLite or similar database.

Totally agree and I'm currently evaluating a dozen solutions, Replicache looks like the best so far. If only it was open source/free, but at the same time, a man needs to put food on the table.

FYI for future readers Replicache has gone open source

Hasura has a few articles about using RxDB to achieve offline capabilities, and it seems to work nicely.

• https://hasura.io/learn/graphql/react-rxdb-offline-first/introduction/ - especially https://hasura.io/learn/graphql/react-rxdb-offline-first/syncing-rxdb-with-hasura/3-trigger-replication-on-changes/ where GraphQL will notify on changes to trigger a pull.
• https://hasura.io/blog/design-guide-to-offline-first-apps/

This setup (push/pull) should be the same for supabase, or am I missing something?

Yes, those are good references and the setup should be very similar.

Thx for the extensive research @audiBookning ! @dahmc great find! Based on this, it would be awesome if we had an adapted Go-to-Guide for supabase!

rxdb 13 beta adds a new replication engine that should be better suited to supabase

Replication with RxDB works very well for me. I created a new rxdb-supabase package with my implementation, any feedback and pull requests welcome! https://github.com/marceljuenemann/rxdb-supabase

Seconded! I made a similar comment re: optimistic updates, it would be wonderful to get a rough roadmap to v1 from the supabase team with rough eta’s/priorities for these bigger features. Like you said it’s the difference between punting on Supabase during MVP with plans for full support as it matures, or using Firebase et al

IMO even if they were to give a time estimate, it would probably just be a well-intentioned guess at best (and likely wrong). Especially because it seems like there’s no clear technical solution yet. Agile software etc etc.

Probably best to choose tools based on the features they already have unfortunately.

This looks really promessing! Thanks for sharing that out 🙂
If you have a chance to test it out please let us know how it goes (will do the same if I have time this week).

Out of interest, one of the advantages of PowerSync is that it is schemaless, so you don't need to worry about migrations on the client side. This is not to be underestimated, as you have discovered.

https://docs.powersync.com/usage/lifecycle-maintenance/implementing-schema-changes

second this

electric "pulled the plug" on the flutter/supabase project

no. supabase makes a bold claim of being the firebase alternative. we should hold them accountable. i want first party support for something so critical. you don't?

I agree that it fits with them positioning themselves as the firebase alternative, but we all know that's just marketing and would never be 1 to 1. Otherwise we need supabase analytics, a/b testing, push messaging etc.

One benefit Powersync will always have is that offline-first is their entire focus, whereas Supabase will always treat it as a second class citizen. Besides, it's nice to diversify the systems you rely on.

I do want first party support, sure, but more than that I want first class support. I don't think Supabase will offer that for offline, if they ever do build it.

Another thing is that firebase started as a mobile app backend. Whereas I think supabase prioritises AI and web, where offline is less important.

yeah but i don't want to have to think or pay for another thing that should be built right into the core system. it's about the dataBASE. they got into realtime late in the game and they still can't do offline or sync. what's so SUPA about that?

yeah everyone is rushing to the shiny AI which is fine as long as you don't neglect the original mission/vision. they could and should just buy/acquire brick or powersync. problem solved. you hear that @tshedor @dshukertjr ?? how is offline and sync not a top priority? i'm just annoyed that all these solutions are sprouting up around supabase that are doing supabase better than supabase is. there is nothing firebase about anything other than free tiers that offer auth/db/storage.

i don't mean to beat up on them but i am just frustrated that i made the assumption offline/sync would only be a matter of months...and it's been years.

I want to be clear that I think Supabase is an outstanding product. Those of us that used Firebase for years can recognize just how many improvements they made to an unchanging product. Of course there are frustrations (why is the JS storage client limited to 100 by default? why do all of my SQL editor queries save immediately? isn't there another way to test this Postgres policy?), but that doesn't detract from the hugely feature-rich offering, even on their free tier.

As someone who's admined an open source repo for five years, everyone always wants your software to work their way. Anticipating their needs is a Sisyphean task. If I'm ever missing a feature from a product, I think about the reasons why it hasn't been built yet.

Offline is extremely complicated - there are so many things that could go wrong. Brick has only survived this long because it's not a paid product; if it was, I'd surely have lost the trust of hundreds of paying customers. Supabase, however, has to get this right the first time because of their wide, existing, paying customer base. It's helpful to have some sympathy.

Also, @dshukertjr if Supabase does approach an offline feature and wants to use Brick as a starting point, or wanted to fork it in their own client, or simply wants to talk about offline architecture and pitfalls, I'd be happy to work with the team.

brick
powersync

What he said ^^

https://github.com/GetDutchie/brick

Yeah, honestly I kinda feel "tricked/fooled" into thinking this would be an A1 priority feature coming out any day now for years. The Open Source Firebase Alternative(Reality)

Yeah, honestly I kinda feel "tricked/fooled" into thinking this would be an A1 priority feature coming out any day now for years. The Open Source Firebase Alternative(Reality)

I have to go back to Firebase with tails between my leg. Offline support is kinda a big deal for the app we wanted to use Supabase for. In a developing country like mine, you just cannot ignore offline support.
Hopefully, I can find a project that would be a good fit for Supabase because I really like it.

I'm hoping they officially support Electric SQL like they did with pgvector

hey @dshukertjr and supabase... i hope you are well and i hope you are listenting to people who bought into your ecosystem upon good faith on the promises you made about truly being the open source firebase alternative. there is no denying the expectation that offline should just work as default feature of your platform. nobody cares about the logging or vector db crap... we just want what we were promised...AN OPEN SOURCE FIREBASE ALTERNATIVE

I'm hoping they officially support Electric SQL like they did with pgvector

It's a bit strange that they didn't implement it internally, as they partner for PGLite

This issue is about different type of using supabase offline, example:

Your users computer goes offline/has no connection, they can still use your app, save data, etc, and it will then be saved once they are online. This also would be taking care of caching data locally.

Yes, and importantly Supabase is claiming to be a Firebase alternative. Firebase automatically handles offline sync without you, the developer, ever having to think about it or even enable it. It just works by default. Granted, that's much easier to do with a document database than it is with a relational one, but still.

As I outlined here, it's impossible for Supabase to build offline support properly because their API surface includes lots of Postgres features (triggers, stored procedures...) that you can't make work offline. I think they would have to offer a whole new product with a more reduced API surface similiar to Fireabse to make offline support work properly. So I wouldn't hope for an official solution that works out of the box with your existing projects.

it's impossible for Supabase to build offline support properly

I mean the "2021 update" at the top of this thread literally says that they're "working on it".

I think people just desperately want to know if supabase are actually working on it or not, and if they are, then some indication of when it will be ready. "Not this year" or "not anytime soon" would be much better than silence.

I've been holding off implementing offline mode in my app because supabase said they are "working on it".

I don't know how much longer I can wait, and lots of people are clearly in the same boat. We just want to know.

"here's an offline mode, but make sure you don't use our features X, Y, Z" would be a horrible product that would lead to so much confusion

I personally disagree. Offline mode is super valuable and implementing it is such a pain that even limited out-the-box support would be a game changer.

I think they would have to offer a whole new product with a more reduced API surface similiar to Firebase to make offline support work properly.

Limitations in software engineering are everywhere. Even Supabase itself releases products and features with limitations:

• Edge functions didn't have file system support until some months ago.
• Dart SDK didn't have most of the APIs of the TypeScript SDK.
• Queues are limited to database functions for now.
• Broadcast was limited to tables only, until days ago.

I don't understand why offline mode is the only area where releasing a limited product seems to be considered unacceptable, unlike their approach with other features.

Limitations in software engineering are everywhere. Even Supabase itself releases products and features with limitations:

There's a big difference between not being able to use an API in a specific case because it doesn't exist or it gives you an error at compile time (or at least when you're first testing it), and being able to use an API, but it failing in hard to explain and hard to predict ways at runtime / only in edge cases. I assume your examples fall into the former category, whereas Supabase introducing offline support would result in the later. I'm not saying it's impossible for them to do it, but I do think it would be a bad developer experience unless they make major changes to their product.

I don't understand why offline mode is the only area where releasing a limited product seems to be considered unacceptable, unlike their approach with other features.

I think getting offline support right is just very hard unless you design for it from the begining. Unlike the other things you mentioned, it's not something you can easily add on top later.

@marceljuenemann, I think you're being too idealistic here. The common criticism here is Supabase isn't a Firebase replacement regarding offline capabilities. Firebase's limited offline mode is already sufficient for the majority – ME INCLUDED.
Focusing on a perfect 1:1 feature match with the online mode is unnecessary as starting point.

@msickpaler Co-Founder at PowerSync here, thanks for the recommendation 😄

Out of interest, which Evolu article / room for optimization are you referring to?

With PowerSync we're aiming to avoid vendor lock-in as far as possible by sticking to standard technologies, such as Postgres and SQLite. For example, you can use Drizzle with our JS SDK, and switch to another Drizzle SQLite library at any point. The actual sync part is more tricky since there are the options in this space are still limited, but in theory you could replace PowerSync with your own sync layer.

Me I am using https://github.com/GetDutchie/brick/tree/main and it work just fine with supabase and for other extra sync stuff I built a layer on top to do things like peer to peer data sync.

for other extra sync stuff I built a layer on top to do things like peer to peer data sync

any some snippet code for this idea? Thanks

you can check our repo here https://github.com/yegobox/flipper

you can check our repo here https://github.com/yegobox/flipper

cool project! Thanks for sharing

I don't know, guys.
They already contributed to PGLite, which is even backed by ElectricSQL, and still nothing.

Why did it take four years and an acquisition to get here? You’re trying to “solve sync right” (partial replication, RLS-safe, conflict handling) before you’ve delivered the 80/20 that many apps would accept today.