We have thought about that! It's a nice approach for some use cases but having just a read-only copy ends up being pretty limiting. Often people using internal tools (particularly customer success) needs to modify some fields in a record but shouldn't have unrestricted access to everything. We've found that being able to protect specific fields instead of the entire database gives a lot more flexibility.

That's exactly what we're doing at https://www.snaplet.dev, I would love to chat with the founders about offering generated production accurate snapshots for developers to code against for users of their proxy!

Are you looking for investment? Happy to close the deal, love that idea so much and trust the co-founders redwoodjs ;-)

Unfortunately not anymore, we have a great set of people backing us, but thanks for the vote of confidence.

As an aside: Not exactly sure why the parent is getting down voted.

Yeah, that's wierd. I just upvoted you to compensate.

Ha, thanks! Can I send you some Snaplet swag? Also would love to show you what we've built!

It's common for startups to hijack competitors' launch threads. Some readers find that distasteful; perhaps that's why there were downvotes.

I'm not saying that your post was such a hijack, but it's difficult to interpret these things accurately, so any post of this kind will always land on a spectrum of responses.

Indeed, but IMHO they're very different products if you understand the positioning, which I guess is hard to guage.

Happy to chat anytime! You can reach me by email (ryan at [ourdomain]) or book directly on my cal - https://calendly.com/ryan-jump/yc-founder-meeting

We've peeked at Snaplet in the past, and :heart: your design aesthetic

Thanks! I'm just about to catch a flight, but will reach out when I get back to the land of the living!

Sounds good, travel safe

Tonic.ai seemed to fit that bill, but we ended up rolling our own ETL job due to cost concerns, and some security preferences for a simple to audit tool to do this. tonic.ai does it on-the-fly, which was merely a nice-to-have for this use case.