wal2json VS pg_net

To illustrate the above, let’s look at an example, using wal2json for convenience. An update event looks something like this:

You could also use tools in conjunction with logical replication to stream changes, like debezium or wal2json.

I've done CDC before for mysql and postgres, in both cases, rolled my own 200~ loc python scripts. No experience with DMS. Debezium, as I understand, needs a kafka topic to stream to, so wasn't workable for us. Rolling our own proved to be fairly trivial. For postgres, there's wal2json https://github.com/eulerto/wal2json

I was researching for the whole day and found out https://github.com/eulerto/wal2json and postgres bult-in `pgoutput` plugin help me to catch the changes.

I don't think this is something for "rails" to do per se, and more the underlying DB. replication tools to capture a "change log". I have use postgres Write Ahead Logs (WAL) shipped to s3 in json format https://github.com/eulerto/wal2json

[0] https://supabase.com [1] https://github.com/supabase/realtime [2] https://github.com/eulerto/wal2json [3] https://github.com/supabase/walrus [4] https://gsd.di.uminho.pt/members/cbm/ps/delta-crdt-draft16ma... [5] https://supabase.com/blog/2022/04/01/supabase-realtime-with-... [6] https://fly.io [7] https://github.com/supabase/realtime/tree/multiplayer [8] https://github.com/supabase/supabase/tree/master/docker

wal2json Output Plugin that converts WAL output to JSON objects [Open Source] pg_recvlogical Postgres app that can consume update stream [Out-of-the-box with Postgres] decoderbufs Output Plugin that delivers data as protobuf [Open Source, Used in Debezium]

> speaks a particular API over the network

it's a interesting idea, and one of the things that we were toying with in our pg_net extension (https://github.com/supabase/pg_net). This is a "generic" async network extension, so you can fetch/put/post. It works well for APIs.

I think the generic approach works for some things where the data is less "fixed" - for example, an OpenAI API endpoint.

But for "fixed" data (data warehouses), the wrapper usually needs some custom work for security, protocols, and "push down". I'll be interested to get HN's take on this - they might have some suggestions for us for this framework

> finding the building blocks of modern applications (database, auth, functions, presence, realtime subscriptions), making them easy to use, and then sharing the source code.

Great observation!

> I’ve learned a ton just from cruising around supabase GitHub.

Glad to hear it!

> Can you say which of these new components will be open sourced?

All of these components are open source and licensed under Apache License v2.0.

> There are some other features (e.g. function hooks) that are also closed-source at the moment.

I actually worked on the initial implementation of function hooks. We've actually already open sourced both the client (see: https://github.com/supabase/supabase/tree/88bcef911669595428...) and the pg_net extension it requires (see: https://github.com/supabase/pg_net).

> Is Supabase heading for an “open core” model?

I don't think so. We want to continue to open source our projects under either MIT (client libs) and Apache License v2.0 (server libs).

> The dream would be to have a great DX experience around using insert/update triggers to call Supabase functions to run background tasks

We have something for this: Function Hooks (soon to be renamed "Async Triggers")[0]. They are still in alpha, but the extension [1] is getting close. It was important to build something which works with PG background workers so that it's non-blocking. We'll make quick progress on this now that we've released Edge Functions.

> sending notifications or updating related rows

Tune in for tomorrow's announcement - it's related.

[0] Function Hooks / Async Triggers: https://supabase.com/blog/2021/07/30/supabase-functions-upda...

[1] https://github.com/supabase/pg_net