Content pfp
Content
@
https://warpcast.com/~/channel/pg
0 reply
0 recast
0 reaction
Ryan pfp
Ryan
@ryansmith
initial thoughts on AWS DSQL 1. PG compatible (pg is dominant at this point) 2. Most of the article talked about HA 3. AWS has a proprietary, internal distributed transaction log service that is supposedly the most important piece of AWS and everything in AWS depends on it. Hope that teams makes 10M annual tc each. 4. It depresses me to think that the future of compute and storage is: run it on aws It's really neat to think about having a network storage layer that can support many database frontends. this seems like the future. Neon et al. are moving in this direction. Also something that Stonebraker has been talking about for a while now. https://aws.amazon.com/blogs/database/introducing-amazon-aurora-dsql/
4 replies
4 recasts
33 reactions
Fucory pfp
Fucory
@fucory
Have you ever looked at pglite from the electricsql team?
1 reply
0 recast
1 reaction
Ryan pfp
Ryan
@ryansmith
I have. I'm not sure how I'd use it.
1 reply
0 recast
1 reaction
Samuel ツ pfp
Samuel ツ
@samuellhuber.eth
Been thinking about it as embedded database into clients
1 reply
0 recast
0 reaction
Ryan pfp
Ryan
@ryansmith
What does client mean in this context?
1 reply
0 recast
0 reaction
Samuel ツ pfp
Samuel ツ
@samuellhuber.eth
Enduser client Where the interaction happens, frontend is etc
1 reply
0 recast
0 reaction
Ryan pfp
Ryan
@ryansmith
Got it. Maybe it is good for that? I'm not so sure.
1 reply
0 recast
0 reaction
Samuel ツ pfp
Samuel ツ
@samuellhuber.eth
Intended use is as embedded db in that sense to be an alternative to SQLite that can sync through electric with the backend Postgres so dev does sync local db queries
1 reply
0 recast
0 reaction
Fucory pfp
Fucory
@fucory
Yea exact use case I'm considering using it for. You stick your indexer on the client via tauri app or in browser and user syncs their local data. Then the data gets synced with a larger postgres instance on backend server
1 reply
0 recast
0 reaction
Ryan pfp
Ryan
@ryansmith
I guess I don't see the problem with querying for data when you need it. Or issuing a batch of queries if you want to amortize networking costs. As far as databases go, disk is usually the bottleneck (not processing a query) and I don't see how this solution addresses that problem in a fundamentally better way than the status quo. What specific problem is being solved with "sync"?
1 reply
0 recast
1 reaction
Fucory pfp
Fucory
@fucory
When you stick the database on the client you have 0 loading spinners and native app ux. The app will work offline. If you have ever used Linear that is currently considered the absolute best UX possible to build. A good website to explore this architecture is here https://localfirstweb.dev/
1 reply
0 recast
0 reaction
Fucory pfp
Fucory
@fucory
Works well for decentralized apps because you remove a trust assumption on an operator and instead the operator becomes just a way to enhance the ux but not necessary for basic functionality
1 reply
0 recast
0 reaction
Ryan pfp
Ryan
@ryansmith
Too long of a conversation to have online but I’m familiar with local first and I hear what you are saying and I still don’t think it’s an interesting idea. ¯\_(ツ)_/¯
1 reply
0 recast
0 reaction
Fucory pfp
Fucory
@fucory
I generally don’t think of it as “why put the data locally” I look at it the other direction and ask “why put data on a server” because the default simplistic architecture is to just stick the data in the same process as the program The answer to why stick it on a server is 1. It is easier to multiclient until tech like replicache showed up 2. The server is more durable But server comes with ux tradeoffs So generally the only reason we don’t make things local first is because it’s hard from programmers pov to do otherwise. Anyone who needs significantly better ux to compete in the marketplace like linear did has the opportunity to do so via eating glass with local first and it’s inevitable as the abstractions close the gap in how much it “costs” in developer effort drops
1 reply
0 recast
0 reaction
Ryan pfp
Ryan
@ryansmith
I think your reasoning makes 100% sense for some apps but not for all
1 reply
0 recast
1 reaction
Fucory pfp
Fucory
@fucory
No doubt. The cannonical app it makes the most sense is Google docs. The cannonical app where it makes the least sense is open ai and etherscan. In the long run apps end up being a mix of local first and server first depending more on features than app but we aren’t there yet
1 reply
0 recast
0 reaction
Fucory pfp
Fucory
@fucory
Forgot to mention onchain apps are already local first and that lends them to being more local first than most other apps The wallet doesn’t exist on the server and it’s not even possible to server render most data This becomes even more true once light clients and full nodes on the client become more common
0 reply
0 recast
0 reaction