realtime VS absurd-sql

You can LISTEN/NOTIFY. Or you can use logical replication and a custom subscriber.[1] Supabase uses the latter.[2]

[1]: https://www.postgresql.org/docs/current/logical-replication....

[2]: https://github.com/supabase/realtime

Supabase Realtime is great for building collaborative applications. You can receive database changes over websockets, store and synchronize data about user presence, and broadcast any data to clients via "channels".

We use :telemetry to collect usage data per tenant for Supabase Realtime.

We do this for rate limiting but it also makes it very easy for us to attach a listener (https://github.com/supabase/realtime/blob/main/lib/realtime/...) which ships these (per second) aggregates to BigQuery (via Logflare), which then the billing team can aggregate further to display and actually bill people with.

Yo :D This is what Supabase Realtime does!

https://github.com/supabase/realtime

Spin up a Supabase database and then subscribe to changes with WebSockets.

You can play with it here once you have a db: https://realtime.supabase.com/inspector/new

Every project is a Postgres database, wrapped in a suite of tools like Auth, Storage, Edge Functions, Realtime and Vectors, and encompassed by API middleware and logs.

Where can I learn more about this? I've been thinking of trying to integrate Supabase Realtime (https://github.com/supabase/realtime) into my Django app (without the rest of Supabase), but I'd also like to keep things even simpler if possible.

Also, what was the reason not to go with Gevent?

I believe #2 was the main driver for the supabase team to build their real-time component: https://github.com/supabase/realtime

Background/announcement: https://supabase.com/blog/supabase-realtime-multiplayer-gene...

As a minor note, one of the linked articles talks about having used RethinkDB for its changefeeds and I made a mental note a bit back that if I ever want that supabase's realtime ( https://github.com/supabase/realtime ) provides something rather like that atop Postgres and I should try that before doing anything clever.

Not really, but I'm aware of absurd-sql. Note that this requires IndexedDB and thus a browser environment.

I don't need SQL capabilities, so I didn't look into those options (there's also absurd-sql, which ports sqlite to the browser on top of IndexedDB).

Ironically I was just about to drop in absurd-sql [1] to a project, which uses indexeddb to back SQLite. This seems better.

[1] https://github.com/jlongster/absurd-sql

There is also absurd-sql that is sqlite3 in wasm using IndexDB as storage and it’s faster than IndexDB itself

[1]: https://github.com/jlongster/absurd-sql

Offline data: running it in the browser for an offline cache, similar to sql.js or absurd-sql.

We are very close to having WASM SQLite with persistence in the web platform. Until now SQLite compiled to WASM was in memory and you had to write the whole database out as a binary array to save changes. There is absurd-sql (https://github.com/jlongster/absurd-sql), which builds a virtual file system on top of IndexedDB for sqlite, its incredible, but a bit of an ugly hack.

However, the new file-access apis (https://developer.mozilla.org/en-US/docs/Web/API/File_System...) that are landing in browsers will fix this. One of the things it does is enable very efficient block level read/write access to a privet sandboxed filesystem for the websites origin, perfect for persistent sqlite. There is more here: https://web.dev/file-system-access/#accessing-files-optimize...