5 ms·

> CRDT It's definitely something we'll support (we mention it briefly in the blog post). We'll extend this service so that it works well with WebRTC, and we ha

> CRDT It's definitely something we'll support (we mention it briefly in the blog post). We'll extend this service so that it works well with WebRTC, and we have a few ideas for making it easy for development. > Maybe the WASM Postgres yesterday This was mind-blowing! Very cool what the crunchy team have done there. It would be awesome to replicate from a remote Postgres database to a "per-user" database to the browser. I think WASM support needs to improve before it can become generally useful for offline-sync, but the tech seems withing reach. We're working on various ideas for offline-sync, but the Realtime server will be central to whatever implementation we land on.

samwillis 4y ago
Both of those sound super exiting! I previously experimented with building an offline syncing CRDT db using Pouch/CouchDB and combining it with Yjs for automatic conflict resolution. But Postgres would be so much better as the foundation. If only I had time it is something I would love to work on…
- kiwicopple 4y ago
  perhaps we can help you find some time (contact details are in my profile)
pcthrowaway 4y ago
Any idea if Realtime might support Postgres streaming replication in the future? We were incredibly excited to use Realtime with TimescaleDB, but couldn't get it working. I assumed it was related to https://docs.timescale.com/timescaledb/latest/how-to-guides/replication-and-ha/about-ha/#replication https://docs.timescale.com/timescaledb/latest/how-to-guides/... (even though we were only running it single-node, my understanding is that Realtime works by tapping into the replication feed)
- kiwicopple 4y ago
  Realtime uses logical replication, and from your link it looks like it should work with Timescale (although not recommended): > Using logical replication with TimescaleDB is not recommended, as it requires schema synchronization between the primary and replica nodes and replicating partition root tables, which are not currently supported. As long as logical replication is supported, this won't be an issue for Realtime because the purpose is to receive data changes (which come in a JSON format) and the end-user doesn't need to persist schema modifications. > but couldn't get it working If you send me some error logs, I can take a look or forward to one of the team. > support Postgres streaming replication This is the first time I've heard it requested - I don't think it's something we'd do unless there was a good reason and strong demand. If we were to do any work in this direction we'd prefer to try contribute DDL streaming to PostgreSQL's logical streaming. We've been thinking about this for a while (Michel has built metagration - https://github.com/michelp/metagration https://github.com/michelp/metagration which has prompted a few ideas for core patches)
  - pcthrowaway 4y ago
    > If you send me some error logs, I can take a look or forward to one of the team. I really appreciate the offer. I don't have the logs handy unfortunately and haven't been interacting with the Timescale instance in a few months. If I move back to that side of things I most definitely will take you up on that. For what it's worth, I don't think the error was in running or connecting to Realtime; rather, I think what happened is there were duplicate, missing, or truncated messages. Thinking on it some more, I think TimescaleDB is using multiple tables under the hood for the tables they expose. Unfortunately, it's out of my depth of Postgres knowledge right now, so I can't tell you more
lagrange77 4y ago
> We're working on various ideas for offline-sync, but the Realtime server will be central to whatever implementation we land on. Are you also working on optimistic updates (which may be related to offline-sync)?
- kiwicopple 4y ago
  I should have been more clear - when I say "working on", it means "debating internally what would be the best long-term strategy" (from a technical POV). But yes, optimistic updates is one of the requirements. In the meantime, if you need something great, I can recommend Replicache and WatermelonDB - both are excellent.
  - lagrange77 4y ago
    > Replicache and WatermelonDB - both are excellent. Nice, thank you.

samwillis 4y ago

Both of those sound super exiting! I previously experimented with building an offline syncing CRDT db using Pouch/CouchDB and combining it with Yjs for automatic conflict resolution. But Postgres would be so much better as the foundation. If only I had time it is something I would love to work on…

kiwicopple 4y ago
perhaps we can help you find some time (contact details are in my profile)

pcthrowaway 4y ago

Any idea if Realtime might support Postgres streaming replication in the future? We were incredibly excited to use Realtime with TimescaleDB, but couldn't get it working. I assumed it was related to https://docs.timescale.com/timescaledb/latest/how-to-guides/replication-and-ha/about-ha/#replication https://docs.timescale.com/timescaledb/latest/how-to-guides/... (even though we were only running it single-node, my understanding is that Realtime works by tapping into the replication feed)

kiwicopple 4y ago
Realtime uses logical replication, and from your link it looks like it should work with Timescale (although not recommended): > Using logical replication with TimescaleDB is not recommended, as it requires schema synchronization between the primary and replica nodes and replicating partition root tables, which are not currently supported. As long as logical replication is supported, this won't be an issue for Realtime because the purpose is to receive data changes (which come in a JSON format) and the end-user doesn't need to persist schema modifications. > but couldn't get it working If you send me some error logs, I can take a look or forward to one of the team. > support Postgres streaming replication This is the first time I've heard it requested - I don't think it's something we'd do unless there was a good reason and strong demand. If we were to do any work in this direction we'd prefer to try contribute DDL streaming to PostgreSQL's logical streaming. We've been thinking about this for a while (Michel has built metagration - https://github.com/michelp/metagration https://github.com/michelp/metagration which has prompted a few ideas for core patches)
- pcthrowaway 4y ago
  > If you send me some error logs, I can take a look or forward to one of the team. I really appreciate the offer. I don't have the logs handy unfortunately and haven't been interacting with the Timescale instance in a few months. If I move back to that side of things I most definitely will take you up on that. For what it's worth, I don't think the error was in running or connecting to Realtime; rather, I think what happened is there were duplicate, missing, or truncated messages. Thinking on it some more, I think TimescaleDB is using multiple tables under the hood for the tables they expose. Unfortunately, it's out of my depth of Postgres knowledge right now, so I can't tell you more

lagrange77 4y ago

> We're working on various ideas for offline-sync, but the Realtime server will be central to whatever implementation we land on. Are you also working on optimistic updates (which may be related to offline-sync)?

kiwicopple 4y ago
I should have been more clear - when I say "working on", it means "debating internally what would be the best long-term strategy" (from a technical POV). But yes, optimistic updates is one of the requirements. In the meantime, if you need something great, I can recommend Replicache and WatermelonDB - both are excellent.
- lagrange77 4y ago
  > Replicache and WatermelonDB - both are excellent. Nice, thank you.