Live data from Hacker News

Show HN: Bi-directional sync between Postgres and SQLite

powersync.com

61–70 of 107 posts

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

#61

Earlier quoted context omitted.

I think he's referring to behavior that some software has when it encounters raw UNIX timestamps without TZ information. I recall seeing a change like that in Python's datetime module as of late, so that even if UNIX timestamps are UTC by default, it's more explicit. In the case of my project, the goal is to have UTC-only timestamps/dates, and since the resolution I'm using it for is a calendar day, time zone doesn't…

By definition unix timestamps are UTC. Python's datetime module has a lot of footguns because naive timestamps can represent UTC, local time, or even a non-standard application-specific time. Python's aware timestamps just carry the tzinfo information along with the naive timestamp so that you can get to UTC from the abstract naive timestamp. It's a really overdesigned footgun of Python's datetime module more than an…

Cool, thanks for the clarification!

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

#62

Thank you - it’s great to have an alternative to electric-sql. I actually need a local first, disconnected framework. What many people don’t realize is that even in the US, there are many parts without any network connectivity like our parks and preserves. Rangers still need to make queries in those areas.

You can find more alternatives here: https://localfirstweb.dev/

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

#64
post #48

It is amazing how often I sit with crappy or no connectivity, even in today's day and age, and so if it were easier for more apps to be designed to work offline first that would truly be amazing. Exciting development PowerSync team, good luck and Godspeed!

Yeah it's a shocker that even major apps like Apple's Weather aren't local first. Lots of room for improvement.

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.

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

#65
How do you handle primary keys? Wouldn't auto-incrementing integers lead to duplicate keys since clients are not aware of each other?

For the To Do app example, let's say two clients start with an empty database and each creates a new todo:

Client A creates [id:1, todo:"Buy milk"]

Client B creates [id:1, todo:"Buy cheese"]

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

#66
Well done on the launch! I have been using PowerSync for several months already ( although our own app hasn't quite reached production yet, due to other reasons).

Very happy with PowerSync. The docs are detailed and well thought out, and the technology is solid. One can see it builds on a decade of sync experience from the Journey team.

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

#67
post #66

Well done on the launch! I have been using PowerSync for several months already ( although our own app hasn't quite reached production yet, due to other reasons). Very happy with PowerSync. The docs are detailed and well thought out, and the technology is solid. One can see it builds on a decade of sync experience from the Journey team.

Thanks for the feedback! Along with the docs we also have an active Discord that anyone is welcome to join for any queries, requests, discussions etc https://discord.gg/powersync

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

#68
post #65

How do you handle primary keys? Wouldn't auto-incrementing integers lead to duplicate keys since clients are not aware of each other? For the To Do app example, let's say two clients start with an empty database and each creates a new todo: Client A creates [id:1, todo:"Buy milk"] Client B creates [id:1, todo:"Buy cheese"]

Hi ricg thanks for the great question! We have a docs page that speaks to this https://docs.powersync.com/usage/sync-rules/client-id:

"PowerSync does not perform any validation that IDs are unique. Duplicate IDs on a client could occur in any of these scenarios:

- A non-unique column is used for the ID.

- Multiple table partitions are used, with the same ID present in different partitions.

- Multiple data queries returning the same record. This is typically not an issue if the queries return the same values (same transformations used in each query)."

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

#69
post #65

How do you handle primary keys? Wouldn't auto-incrementing integers lead to duplicate keys since clients are not aware of each other? For the To Do app example, let's say two clients start with an empty database and each creates a new todo: Client A creates [id:1, todo:"Buy milk"] Client B creates [id:1, todo:"Buy cheese"]

To expand on what prawnstar said - it's exactly because of this that we recommend using uuids as the primary key (uuid v4 specifically). While you can use integer ids, you need some workarounds such as pre-generating sets of unique ids per device.
Post reply on HN