Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
greg-m
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
5 ms
·
1.
▲
by
greg-m
3mo ago
Agreed - we've made this copy change to the free usage email now, and the change to add a toggle for preventing runs when you run out of credits is going through CI.
2.
▲
by
greg-m
3mo ago
Thank you for engaging! Yeah, I hear you on the inversion of expectations and I think you're exactly right about how this affects perceptions of the product. Candidly, right now, we're more likely to land on an opt-out rather than
3.
▲
by
greg-m
3mo ago
I'd push back a little, the whole problem is that our flow let someone get to a surprising bill without it being obvious along the way. Looking back at support cases we have typically seen this at much lower spend too, so it's def
4.
▲
by
greg-m
3mo ago
Hey there - I partially disagree! We issue an invoice because the customer did consume the services - a lot of folks appreciate that, since it gives their AP team a real cost to work from instead of a ballpark of us vs. GitHub. My "we
5.
▲
by
greg-m
3mo ago
Hey - First off, fair point on the free tier email. This fits in the same theme of clarity vs. trust for me: if we say disruption, but then leave your account enabled, that still feels deceptive even if it seems generous to us. We will fix.
6.
▲
by
greg-m
3mo ago
Hey folks - Greg here, I do product at Blacksmith. I want to say upfront - we've never pursued these invoices. If someone feels they didn't get value from the service, we've eaten that cost and always will. There's a bit
7.
▲
by
greg-m
4y ago
We work with supabase - so your DB still deploys out to them, but we cache queries in memory so they're significantly lower latency. Since we're offloading reads, we also help handling traffic spikes, lower costs, etc.
8.
▲
by
greg-m
4y ago
yes! shoot me an email - greg@readyset.io - we're in the process of building binaries for more platforms, lmk which you need.
9.
▲
by
greg-m
4y ago
ReadySet (readyset.io) supports the same style of caching and works with Supabase, if you want to check us out :) I have a few extra cloud invites: greg@readyset.io
10.
▲
The Curse of the Enum – MySQL vs. Postgres
(readyset.io)
14 points
by
greg-m
4y ago
|
0 comments
11.
▲
by
greg-m
4y ago
ReadySet | Full-Time | Software Engineering & Product Design | Remote US https://readyset.io/about#open-roles ReadySet is a new database cache engine that speaks SQL and automatically handles cache eviction by listening
12.
▲
by
greg-m
4y ago
https://join.slack.com/t/readysetcommunity/shared_invite/zt-... should work!
13.
▲
by
greg-m
4y ago
Hey, PM @ ReadySet - fair points, and thanks for checking us out. We've been in pretty heavy development and have been heads down on getting ReadySet into your hands as quickly as we could. We'll be doing a major documentation pas
14.
▲
by
greg-m
4y ago
ReadySet PM here - depends on if there are writes to the table or not! For example, MySQL deprecated their query cache, but previously it would only cache until there were any writes to the tables that the queries were referencing https:&#
15.
▲
by
greg-m
4y ago
Hey, PM @ ReadySet here. Shoot an email to greg@readyset.io and we can see what we can do :)
16.
▲
by
greg-m
4y ago
Yes! We've thought about this in depth and have some ideas but I'd love to chat more. Shoot me an email: greg@readyset.io
17.
▲
by
greg-m
4y ago
PM at ReadySet here - that's the idea! We think sub ms reads while still using SQL are pretty cool :) If you want to dig-in more, hop into our community slack: https://readysetcommunity.slack.com/
18.
▲
by
greg-m
4y ago
Yes, still in the cards. Hoping to release this before GA - it'll be a part of our migrator.
19.
▲
by
greg-m
4y ago
This is what we live for :)
20.
▲
by
greg-m
4y ago
Just clarifying - D1 without read replicas is strongly consistent. If you add read replicas, those can have replication lag and will not be strongly consistent. Disclaimer: I work at Cloudflare :)
21.
▲
by
greg-m
5y ago
Hey! I’m the PM for DO. 1) A Durable Object is a global singleton instance of a Cloudflare Worker that is addressed by an ID. You define that Worker’s behavior via a JavaScript class. That Worker can then write to a persistent storage API,
22.
▲
by
greg-m
5y ago
Hey, I'm on the PM team at Cloudflare. I think this is exactly right, but the truth is that developers are slow to adopt new databases and databases are slow to support a broad array of use-cases. While we're also working on that
23.
▲
by
greg-m
5y ago
Hey, R2 PM here - there's no question that the product will have 0 egress charges, regardless of destination. For archival use-cases, you do still pay us for data storage. We're referring to not charging for operations for infrequ
24.
▲
by
greg-m
5y ago
We've heard this a few times and will support it :). Also, shameless plug for Cloudflare Pages to host on CF today.
25.
▲
by
greg-m
5y ago
Durable Objects is as close as we come today, but we still have two innovation weeks left this year.
26.
▲
by
greg-m
5y ago
we will :) we're working to reach 5 GB per upload, with multi-part support.
27.
▲
by
greg-m
5y ago
Sure, you could just setup a Worker in front of a bucket. This is very similar to how the original Workers Sites worked.
28.
▲
by
greg-m
5y ago
Yes. We have an in-Worker API to start, but will also make R2 available outside of Workers as an API endpoint.
29.
▲
by
greg-m
5y ago
Yes, we have read after write consistency across regions today. We're considering relaxing that if we need to reduce latency (one of the things to be worked out in beta!).
30.
▲
by
greg-m
5y ago
Hey, I'm the PM for R2. We support per-object TTLs, so this should work!
More ›