←back to thread

637 points neilk | 9 comments | | HN request time: 1.936s | source | bottom
1. stavros ◴[] No.43554765[source]
I didn't go into the implementation details so I won't comment on that, but I will say that this is a really important problem to solve. I've long wanted/needed an agnostic sync layer that apps could use to sync my changes across clients and servers, and it would be great if app developers didn't have to put any work into it, they'd just point their database to a URL and the database would take care of all the syncing.

This means that the app developer could support private syncing without any effort, and I wouldn't have to pay a subscription just for sync, I could just run a sync server on my NAS and all apps would know to sync their data with it. Of course, app developers don't want this because subscriptions are a reliable income stream, but hopefully users would push for it.

replies(2): >>43554774 #>>43557829 #
2. Cthulhu_ ◴[] No.43554774[source]
~10 years ago, CouchDB was the answer to this problem. I don't know what the status of that is in 2025, but at the time it was used to e.g. sync airplane sales tablets with a central database once they were back on the ground and online.
replies(1): >>43554782 #
3. stavros ◴[] No.43554782[source]
Yeah, what happened to CouchDB? I thought it would be much more popular, but I haven't heard of it in years. Maybe this problem isn't actually important, or maybe people don't know they can solve it in this way?
replies(2): >>43554977 #>>43555031 #
4. bbrks ◴[] No.43554977{3}[source]
This space is very much alive and well and I'm really glad there's more competition cropping up from smaller projects like OP.

Disclaimer: I have worked on a sync backend for a company in this space for the last 8 years. You can probably find out where if you look, but this comment won't be a sales pitch.

Competition like this has incredible value for communities with poor internet access but reasonable development capabilities. Think about travelling doctors in the lesser developed countries and areas of Africa for instance. Quite often entire villages get medical checkups done, with data being recorded on a tablet. This can be synced once the doctor gets to a town with internet access for follow-up. Of course, projects like the above do not have big budgets. Unfortunately they are priced out of using a lot of tech to solve these problems (my company included in this statement)

On the more enterprise-y side, which is where I mostly sit, a lot of airlines, cruise ships, retail and field-based industry use these technologies, since they are prone to periods of being completely offline or in a P2P mesh only. Cloud databases or even regular replicated databases running in-situ are a non-starter, since there won't be anybody around to administer it. Replication is a difficult problem at the best of times, let alone in periods of comms downtime.

5. miramba ◴[] No.43555031{3}[source]
Not an expert on CouchDB, but used it recently in a project and loved the syncing with the corresponding pouchdb at the frontend. My main problem, what was missing imho was security: Interactions with couchdb where directly with the database, ie no intermediate API available. Maybe that was a good idea when couchDB was designed, but it made me feel uncomfortable in 2024. If anyone knows of an intermediate API-Layer for couchdb, please post.
replies(1): >>43556106 #
6. dotemacs ◴[] No.43556106{4}[source]
Interesting that you're seeing the lack of intermediate server/API as a drawback. InstantDB sees it as progress, see their essay on it:

https://www.instantdb.com/essays/sync_future

7. carlsverre ◴[] No.43557829[source]
Thank you! Glad we see the world the same way! I've also always wanted a general purpose sync layer that provided a simple consistency model to build on top of.

And I made Graft open source to enable exactly that! Deploy it anywhere! Just let me know so I can better support your use case :)

replies(1): >>43558037 #
8. stavros ◴[] No.43558037[source]
Thanks for building SQLSync! You might like Klepmann's "local-first" talks, though I'm sure you're already familiar.
replies(1): >>43558392 #
9. carlsverre ◴[] No.43558392{3}[source]
You're welcome! And yea, I'm a huge fan of Klepmann and his local first content :) Thanks for the reminder!