3 ms·

Just a quick precision, if I'm not mistaken: this project is not decoding the (version, architecture dependent) WAL stream as it seems to be implied by https://

Just a quick precision, if I'm not mistaken: this project is not decoding the (version, architecture dependent) WAL stream as it seems to be implied by https://news.ycombinator.com/item?id=22114603 https://news.ycombinator.com/item?id=22114603 But it rather uses logical decoding with the pgoutput plugin (which was introduced in Postgres 10, so I'm guessing it doesn't support out of the box earlier versions). This approach makes total sense, though. Apart from that, reading the documentation I don't see how app.supabase will interface with my source database. Does it need to be open for connections from supabase, or is supabase also a database hosting service, or an agent is installed alongside the source database?

kiwicopple 7y ago
Yes you're right about the logical decoding, thanks for clarifying and I'll make sure I update the docs. For Supabase (when we finally have sign ups), the idea is that you can BYO postgres, or we will host. If BYO, you would have to set wal_level = logical, and create a publication for us to listen to (eg: CREATE PUBLICATION supabase_realtime FOR ALL TABLES). We will host the middleware which will give realtime and restful api. The idea is that you focus on your database schema and we handle the rest. Still early days though. We are just trying to find our feet, including figuring out whether this is even something people would want
- ahachete 7y ago
  Great. May you ellaborate on the BYO concept? How do you bring it? Or you will just ask Postgres owners to install an agent which will then connect from customers' premises to your middleware? BTW hosting your own Postgres service is a huge project on its own. Take this into consideration.
  - kiwicopple 7y ago
    For the BYO - all we need is the database connection string. We will then host an elixir server + nginx. This doesn’t need any agent on the database itself. I’ll add a diagram to to website, I think I can make this a lot clearer. > hosting your own Postgres service is a huge project Yes, you’re right. We will only do it if it looks like our potential customers are leaving because they don’t know how to do it themselves. Even then, we will just wrap an existing managed service to start with. We’d like to make Postgres as simple to use as Firebase (for newbie database users)
    - ahachete 7y ago
      > For the BYO - all we need is the database connection string. Then this means that the database should be publicly accessible. Many would not accept this from a security perspective (regardless of the use of SSL and even certificate authentication only).
      - kiwicopple 7y ago
        We will also provide an IP address that the user can whitelist so they don’t have to make it completely public. But I would understand if even that is not enough for some. That’s the beauty of opensource though. If we end up just building a useful product that everyone hosts themselves, I’m happy with that. Btw, these are great questions. Thanks - they will really help me to improve how I have explained it on the website

kiwicopple 7y ago

Yes you're right about the logical decoding, thanks for clarifying and I'll make sure I update the docs. For Supabase (when we finally have sign ups), the idea is that you can BYO postgres, or we will host. If BYO, you would have to set wal_level = logical, and create a publication for us to listen to (eg: CREATE PUBLICATION supabase_realtime FOR ALL TABLES). We will host the middleware which will give realtime and restful api. The idea is that you focus on your database schema and we handle the rest. Still early days though. We are just trying to find our feet, including figuring out whether this is even something people would want

ahachete 7y ago
Great. May you ellaborate on the BYO concept? How do you bring it? Or you will just ask Postgres owners to install an agent which will then connect from customers' premises to your middleware? BTW hosting your own Postgres service is a huge project on its own. Take this into consideration.
- kiwicopple 7y ago
  For the BYO - all we need is the database connection string. We will then host an elixir server + nginx. This doesn’t need any agent on the database itself. I’ll add a diagram to to website, I think I can make this a lot clearer. > hosting your own Postgres service is a huge project Yes, you’re right. We will only do it if it looks like our potential customers are leaving because they don’t know how to do it themselves. Even then, we will just wrap an existing managed service to start with. We’d like to make Postgres as simple to use as Firebase (for newbie database users)
  - ahachete 7y ago
    > For the BYO - all we need is the database connection string. Then this means that the database should be publicly accessible. Many would not accept this from a security perspective (regardless of the use of SSL and even certificate authentication only).
    - kiwicopple 7y ago
      We will also provide an IP address that the user can whitelist so they don’t have to make it completely public. But I would understand if even that is not enough for some. That’s the beauty of opensource though. If we end up just building a useful product that everyone hosts themselves, I’m happy with that. Btw, these are great questions. Thanks - they will really help me to improve how I have explained it on the website