The guy is currently a micro-celebrity for the storage engine he wrote: https://cursor.com/blog/git-at-any-scale

Comments URL: https://news.ycombinator.com/item?id=49466282

Points: 7

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48226454

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47927568

Points: 2

# Comments: 0

The CDC stream option you flagged is more viable in my (admittedly biased) opinion. At my company (Prequel) our entire pitch is basically "you should give your customer's a live replica of their data in whatever data platform they want it in" (and let us handle the cross-platform compatibility & multi-tenant DB challenges).

I think this problem could also be a killer use case for Open Table Formats, where the read-replica architecture can be mirrored but the cost of reader compute can be assumed by the data consumer.

To your point, this is only going to be more important with what will likely be a dramatic increase in AI agent data consumption.

Maybe I can save you a headache: Snowflake is actively deprecating single-factor username/password auth in favor of key pair auth, so the faster you support that, the fewer mandatory migrations you'll be emailing users about.

Comments URL: https://news.ycombinator.com/item?id=37901692

Points: 17

# Comments: 0

We're a small team of five engineers based in NYC. We're solving a number of hard technical problems that come with syncing tens of billions of rows of data every day with perfect data integrity: building reliable & scalable infrastructure, making data pipelines manageable without domain expertise, and creating a UX that abstracts out the underlying complexity to let the user share or receive data. We're powering this feature at companies like LogRocket, Modern Treasury, Postscript, and Metronome.

Our stack is primarily K8s/Postgres/DuckDB/Golang/React/Typsecript and we support deployments in both our public cloud as well as our customers' clouds. Due to the nature of the product, we work with nearly every data warehouse product and most of the popular RDBMSs.

We're looking for a full stack engineer who can run the gamut from CI to UI. If you are interested in scaling infrastructure, distributed systems, developer tools, or relational databases, we have a lot of greenfield projects in these domains. We want someone who can humbly, but effectively, help us keep pushing our level of engineering excellence. We're open to those who don't already know our stack, but have the talent and drive to learn.

// Full job posting here -- https://prequelco.notion.site/Senior-Software-Engineer-Prequ...

// To apply -- email jobs at prequel.co and include [HN] in the subject line

Comments URL: https://news.ycombinator.com/item?id=36233889

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=36138920

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=36129273

Points: 2

# Comments: 0

Long term, we'd like to be the interoperable player focused purely on data sharing that plays nicely with any of the upstream sources, but also facilitates connecting to any data destination. (This also means we can spend more time building thoughtful interfaces – API and UI – for onboarding and managing source and destination connections)

Re: configuration – you would create a config file for each "source" table that you want to make available to customers, including which columns should be sent over. Then at the destination level, you can specify the subset of tables you'd like to sync. This could be a single common schema for all customers, or different schemas based on the products the customer uses.