Live data from Hacker News

Show HN: Bi-directional sync between Postgres and SQLite

powersync.com

91–100 of 107 posts

Re: Show HN: Bi-directional sync between Postgres and SQLite

#91

Let me throw SymmetricDS into the ring: https://symmetricds.org/ In my opinion it is quite underestimated giving its various cross platform and cross product sync capabilities. My first experiences with it are quite promising.

Thanks for sharing. Sometimes I feel had it not been for discussion and community at HN, I wouldn't find such stuff.

Re: Show HN: Bi-directional sync between Postgres and SQLite

#92
post #53

Earlier quoted context omitted.

I'm reminded of RealmDB, which I think Mongo bought at some point

We have been using realm in production for a while and it seems to have steadily improved since moving to MongoDB (surprisingly for an acquisition). It is definitely best of class when it come to doing live sync between a backend and a local database. Realm itself is amazing, fast and intuitive, and the bidirectional sync to MongoDB just works. The only downside is the messy and confusing web admin interface.

Out of curiosity, what kind of use case is yours?

Re: Show HN: Bi-directional sync between Postgres and SQLite

#93
post #24

Earlier quoted context omitted.

Ah thanks. Out of curiosity, will the self-hostable version be a paid product, or free to use? (No judgement, just want to understand the business model).

The initial self-hostable version will be available as part of the paid service, but there is also a free open-source self-hostable version planned for next year: The PowerSync Service will move to an open-core model in 2024: An open-source version will be available (self-hosted) as well as a non-open-source version with premium features (available as both self-hosted and hosted cloud service) The client SDKs are cur…

So that means the pricing of powersync cloud solution will be just a bit higher or similar to cost of self-host, just with extra features, correct?

I'm asking in terms of ease of hosting & restrictions, whether it would be super hard like supabase self hosting + a lack of features or like appwrite where self hosting is very easy and you get most things in self hosted version as well?

Re: Show HN: Bi-directional sync between Postgres and SQLite

#94
post #72

Earlier quoted context omitted.

Not sure I follow. What's the difference between `new Date(ts).getDay()` when ts is an ISO8601 string or a ms since UNIX epoch value. Pretty sure the result is the same and whether you need to use `getDay` or `getUTCDay` is a display issue that affects both variants. I could see it being more convenient if you're just dumping the raw values without any transformation or you don't know what data type is stored in a co…

when you do that, it will give you different days depending on your timezone. 1701388800 is 2023-12-01 in london, but still 2023-11-30 on new york.

Sure, but that’s also true for an iso8601 string unless you’re extracting things directly. But also you’re assuming that your iso8601 string is in local time which it may not be (eg string generated in London but accessed in New York). Localizing things to be time zone aware in a way that meets user expectations is hard because it’s a squishy domain specific UX problem, not a technical one so arguing about it like a technical issue feels like a wrong approach.

Re: Show HN: Bi-directional sync between Postgres and SQLite

#95
post #80

Earlier quoted context omitted.

Why would you want a local first weather app? It's not very useful to have yesterday's weather or even from one hour ago.

Great question and that's what you'd think. I spend a lot of time in the outdoors though, and on day 3 of a camping trip into an area with no signal, I'd rather have a stale prediction for the day 4 weather than no prediction.

Got it, thanks.

Re: Show HN: Bi-directional sync between Postgres and SQLite

#96
post #34
post #30

I am looking for something like this. We develop IoT devices, thousand of linux computer running behind customer routers and have a central server with web admin, all in python. I wish i could have "syncronized objects", something were a change in a device would be reflected back to the server, web interface even better and in the other direction too, a way to see the whole system as one thing, not a hodge podge of a…

This is an interesting use case and sounds like it could be a fit. What stack is the software that runs on the Linux devices? Also feel free to shoot me an email if you'd like to discuss the use case privately (email in bio) or chat on Discord https://discord.gg/powersync

on the linux devices we have a web admin (made with node-red) that control the linux machine, network, config, updates.

Then the web admin run docker container, we have a python backend on the device with fastapi as the base and another with vue.js for the frontend (touchscreen)

Then the server is fastapi/mongodb/vue.js.

We have a continuous websocket from the python program to server and another one from web dashboard to our server admin.

Lot's of moving parts, lot's of problems, not a lot of cohesion and structure.

Re: Show HN: Bi-directional sync between Postgres and SQLite

#97

Earlier quoted context omitted.

Not sure I follow. What's the difference between `new Date(ts).getDay()` when ts is an ISO8601 string or a ms since UNIX epoch value. Pretty sure the result is the same and whether you need to use `getDay` or `getUTCDay` is a display issue that affects both variants. I could see it being more convenient if you're just dumping the raw values without any transformation or you don't know what data type is stored in a co…

You're right that you'll have exactly the same issues if you use Date with a string. However, with a string date you can bypass the Date class completely in many use cases. My experience with this is anecdotal, but I've ran into many bugs due to conversion between day-precision values and Date objects. One example was a date picker library that returned values at 00:00 in the local timezone instead of UTC, which were…

> My experience with this is anecdotal, but I've ran into many bugs due to conversion between day-precision values and Date objects. One example was a date picker library that returned values at 00:00 in the local timezone instead of UTC, which were then not correctly converted to UTC-based values before being persisted.

Oh man, that sounds ugly, and an invitation for disaster. Lots of off-by-ones.

In my project's case, I also need to do math with them for analytical purposes. It's a game collection manager, so it's tracking the day you bought, beat, and 100%d a game.

I derive how long it took to beat a game by subtracting the UNIX timestamp of the purchase date from the beaten date's timestamp, then divide by (60*60*24) to measure days. It's handy to show games in the backlog and sort by purchase date, too, so you can target the games that've been sitting the longest. There are plans to graph out a collection in terms of its path from new to beaten to completed in a Gantt-style chart or something else fun.

But yeah, I just thought to ask because in JSON I and others can read `2023-12-01`, but not `1701417600`. SQLite and Python can do conversions for the calculations, and Python even has the timedelta module that might make my comparisons easier to do or slightly more accurate.

Edit: asterisks

Re: Show HN: Bi-directional sync between Postgres and SQLite

#98

Let me throw SymmetricDS into the ring: https://symmetricds.org/ In my opinion it is quite underestimated giving its various cross platform and cross product sync capabilities. My first experiences with it are quite promising.

Thanks for sharing. Sometimes I feel had it not been for discussion and community at HN, I wouldn't find such stuff.

You stole my words! Thank you again for sharing this option. I just knew about big brands OracleGate , Qlik, IBM IIDR etc but this is interesting. I hope somebody shares the experience with the Pro version and how was the support experience.?

Re: Show HN: Bi-directional sync between Postgres and SQLite

#99
post #96
post #34

Earlier quoted context omitted.

This is an interesting use case and sounds like it could be a fit. What stack is the software that runs on the Linux devices? Also feel free to shoot me an email if you'd like to discuss the use case privately (email in bio) or chat on Discord https://discord.gg/powersync

on the linux devices we have a web admin (made with node-red) that control the linux machine, network, config, updates. Then the web admin run docker container, we have a python backend on the device with fastapi as the base and another with vue.js for the frontend (touchscreen) Then the server is fastapi/mongodb/vue.js. We have a continuous websocket from the python program to server and another one from web dashboa…

Thanks for the additional info. As another commenter mentioned, since you are using MongoDB, it may be worth looking into MongoDB Realm / Atlas Device Sync.

Re: Show HN: Bi-directional sync between Postgres and SQLite

#100
post #24

Earlier quoted context omitted.

The initial self-hostable version will be available as part of the paid service, but there is also a free open-source self-hostable version planned for next year: The PowerSync Service will move to an open-core model in 2024: An open-source version will be available (self-hosted) as well as a non-open-source version with premium features (available as both self-hosted and hosted cloud service) The client SDKs are cur…

So that means the pricing of powersync cloud solution will be just a bit higher or similar to cost of self-host, just with extra features, correct? I'm asking in terms of ease of hosting & restrictions, whether it would be super hard like supabase self hosting + a lack of features or like appwrite where self hosting is very easy and you get most things in self hosted version as well?

To clarify, there will be two self-hostable versions:

- A paid self-hosted version, full-featured: This will be released in the next couple of months.

- An free open-source self-hosted version, with core features: This will be released within 2024.

We will aim to make the open-source version easy to self-host and want to make sure that it has a valuable set of core features.

Post reply on HN