> Bitcoin should be at least $150,000 right now and everyone knows it.
Based on what? I'm a fan of Bitcoin, but "should be" is utter nonsense. As is "everyone knows it". HN doesn't, for one.
> Every trading day at 10am Eastern, coinciding with the U.S. stock market open, Bitcoin experienced sudden and sharp sell-offs. The drops were precise, algorithmic, and wildly disproportionate to broader market conditions. They wiped out leveraged long positions, triggered cascading liquidations, and then reversed within hours.
> [...] This happened every day, day after day.
If these swings are so predictable, why isn't everyone else getting wildly rich off them at the expense of Jane Street?
> Selling into thin order books at the open would depress the price, trigger liquidation cascades among leveraged traders, and create buying opportunities at lower levels. The firm could then re-enter at the bottom of a move it had manufactured.
Yea well don't be overlevered on Bitcoin I guess?
> Simultaneously, the firm boosted its holdings of MicroStrategy stock by 473%, accumulating 951,187 shares worth roughly $121 million
> Basically, Jane Street has direct access to the pipe that connects the Bitcoin ETF to actual Bitcoin, and almost nobody else does.
You too can buy and sell MSTR and BTC.
> In either scenario, the firm has every incentive to use its privileged position as authorized participant to suppress the spot price, trigger liquidations, and harvest the spread.
Yea well don't be overlevered on Bitcoin I guess?
> In other words, the 21M cap only works if the market sitting on top of it is honest.
No. Hell no.
> It has been accused of running algorithmic sell programs that suppressed Bitcoin's price for months.
Cheap Bitcoin sponsored by Jane Street. Cry me a river.
It isn't good but I doubt the UK punishment would be nearly as harsh or expensive and the possibility of death isn't on the menu when the cops come to arrest them.
I suppose the only part the OP would need to look at is "Being able to form and execute queries in my backend" for the read path, since Sync Rules / Sync Streams need to define those queries. For the write path, you should be able to re-use the existing APIs / permission middleware for the most part.
Then: "Further, I wonder how such a system would work with connection pooling, sharding, replication etc."
These are all topics on their own, but briefly:
- Connection Pooling: Not supported in PowerSync Cloud atm, but supported in theory when self-hosting since pgbouncer 1.23 added WAL support. Having said that, clients connect to the PowerSync Service for sync operations, so you only need a single direct connection between the service and your postgres.
- Sharding: PowerSync can be used in a sharded setup [1], with better support planned
- Replication: PowerSync uses the Postgres WAL for replication [2]
PowerSync is a sync engine that keeps your backend database in sync with on-device SQLite. We support Postgres, MySQL, MongoDB and SQL Server as source databases and have a plethora of client SDKS, many of which are integrated with popular libraries and frameworks on the client-side like TanStack DB, Drizzle, GRDB, Room, etc
If you're a database enthusiast and have a solid track record of building, deploying and maintaining backend systems on modern cloud stacks at scale, please check us out.
Our team is small and polyglot, but experience with TypeScript is a must.
Experience with OSS projects is also a must - either you've made significant contributions to popular devtool projects or, better yet, you have your own.
Culture: We're agile and devops purists (before those terms got coopted)
Systems-focused backend engineer with deep experience in databases, sync/state management, and production infrastructure.
Hands-on with SQLite, relational databases, replication-like workflows, and reliability under real-world constraints.
Long-term open-source contributor, comfortable owning complex backend systems end-to-end.
Not sure if you're open to using tools for this, but PowerSync solves those tricky things you listed (and many more you didn't list (disclaimer I'm on the team))
I’m mostly interested in the architectural side rather than a specific tool:
how people separate domain state from transport,
where optimistic state lives,
and how retry / reconciliation is usually modeled without leaking everywhere.
Still useful to see how existing systems approach client IDs though.
Cool, makes sense. We still want to write a blog post about how we built powersync that will go into more detail on the points you raised.
The one thing I'll add is we found "keeping UI responsive while syncing in the background" is highly platform dependent since all platforms have their quirks, but for React Native we have a detailed blog post and code (admittedly tightly coupled to powersync, but should provide a starting point) https://www.powersync.com/blog/keep-background-apps-fresh-wi...
https://x.com/1914ad/status/2026757796390449382
Haven't read it yet but seems spicey
reply