Syncing > Querying.

Anywhere you query for data you should consider syncing data instead.

CDN-backed syncing means your data loads faster you get real-time updates for free.

It's like having mini PG read replicas scattered across your system.

What is fundamentally interesting about the shift from query -> sync?

Both answer the question: "how do I copy data from the database?"

Sync gives you two huge advantages:

1. built-in caching so cheap distribution of data via CDNs
2. real-time updates so no stale data

Tech entrepreneur. Founder @electricsql. Founder @gatsbyjs (acquired by Netlify). @kylemathews on Twitter

fortune cookie casts, memes, parenting, building frames, /framedl & /framedl-pro

syncing is copying data continuously from a source to a destination — so filtering can be part of the config of the syncing but querying or transforming the copied data is a separate concern.

Queries are point in time so immediately start getting out-of-date where syncing implies updates are pushed.

are these comparable though? in some contexts yes, but in many querying is orthogonal to syncs (you effectively query from syncs) - how would you approach "syncs" that handle real-time filtering and aggregations?

also, re 2. - aren't queries real-time too? or do you mean push vs pull?

I stopped using `cp` and started using `rsync` years ago.

Wait...

What is your favourite specifics in a stack to pull off this strategy?