This looks very interesting, letting people run these in any box they own. I very much agree with the sentiment that there are no proper tools that let you run any coding agent without being locked to a single provider. I just want to run opencode or pi somewhere in a box without having to spin up all of them in my machine, let alone being able to trigger them from within another prouduct as a background agent.

Would pi-pod allow me to standardize pi config on a team/project level so that other people in my org can also use them on the same private infra?

This is obviously a space we are very much interested in, so it is definitely nice to see approaches that attack the same problem. I haven't played with dbtcharts in depth yet but it looks very similar to DaC in principle, and also in the actual spec. I believe the industry definitely needs solutions like this to help get out of the legacy BI tools as Bİ is one of the biggest bottlenecks for AI adoption in large orgs.

Excited to see further competition in the space, nice launch!

I built it primarily for ourselves: we are building an AI data engineer, and we need a way to run many of them in parallel securely. An API for this seemed like the most obvious path forward. It makes it trivial to bring agentic capabilities into any product surface without having to deal with sandboxes, reliability issues, compatibility problems, and more.

I think it also makes sense from OpenAI's perspective to do this, but also we did find ourselves needing to change models and harnesses quite a bit, which is why I think this needs to be a layer of its own above the labs. It also needs to be a layer above the sandboxes, since many of them are quite brittle.

Overall, I expect a lot of the agent implementations to move in this direction. I think this is a lot saner for engineers to implement and maintain, and it makes it trivial to build agentic stuff into products.

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

Points: 2

# Comments: 0

It seems like a relatively straightforward marketing article. I was pleasantly surprised to learn about Erathos though, nice product!

I am personally not a big fan of CDC in prod. Streaming data movement is generally prone to confusion, and it feeds into bad data patterns like hard deletes without any audit logs, no timestamps on updates or deletes, etc. which are usually the reason why batch loads cannot be utilized. They require a decent operational understanding of the underlying database, and have some gotchas like the Erathos folks mentioned in the article. We offer CDC both in our cloud platform, as well our open-source tools, but if I could, I would always pick an incremental batch load with a cursor value over a CDC connection.

I understand it is sometimes required due to organizational complexity or legacy database reasons, mine is just a personal preference.

If anyone is looking for an open-source CDC tool that runs as a standalone Go CLI, check out ingestr: https://github.com/bruin-data/ingestr

Epho is an API that allows running Claude Code, Codex or Opencode in a sandbox in the cloud. It abstracts away sandboxes, and allows running coding agents with a single HTTP request.

Epho came out of our own struggles with building our own AI analyst: - Sandboxes give you bare machines; you need to configure them for agentic workloads. - Each agent behaves differently, and you need to build integrations with each of them. - Sandbox providers are not very reliable, which means you need to figure out a multi-provider strategy to avoid failures. - Logging, artifacts, input/output, event streaming, and all of the other operational aspects need to be figured out.

We had to go through the pain ourselves. We got to a point where things got quite reliable, and it became more obvious to us that this should be a primitive on its own: send a POST request, get the events streaming back to you.

Epho is an agents-as-an-API product: you send a request, it spins up a sandbox, configures the chosen harness, clones your repos, and kicks off the agent. It takes care of automatic fallbacks across different providers, handles auth stuff, and just streams back the events and outputs.

It supports Claude Code, Codex and Opencode out of the box, and pretty much all the models they support out of the box. It streams the events back, handles attachments and output files, automatically manages the fallbacks on different sandbox providers, retries, and all the auth stuff. You just send a prompt, your repo, MCP servers you want to use with it, and it runs them.

I recorded a demo here to show a real example: https://youtu.be/HGfly1aytPA

I am quite excited for Epho, simply because I think it is a new primitive that would allow building agents into product a lot easier than it is today. We are running our agents on Epho on prod, so we'll keep maintaining it regardless, and we wanted to ship it as an independent product.

Epho is free to get started, and you can run it with Opencode's free models to get started with it.

I am quite curious to hear what you'd think and would love to get your feedback.

Cheers, Burak

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

Points: 5

# Comments: 0

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

Points: 3

# Comments: 1

For context: Bruin is a data platform that does ETL + BI. We do a lot of things open-source, and recently we launched Dashboard-as-Code: https://github.com/bruin-data/dac

The idea behind DaC was that using AI agents would require a more code-driven approach. That turned out to be directionally right, however it fell short in terms of unlocking even more value as people became more ambitious.

That's why we built data apps: - These are React apps that connect to your database / data warehouse - They work with all kinds of databases + external APIs - They can make external requests in a secure way without the credentials being embedded into the app itself.

This allows building all kinds of interesting and capable UIs with them. The dashboards you build become interactive internal apps that works with your data.

I have written a bit more about them here: https://getbruin.com/blog/announcing-data-apps

I would love to hear what you all think about generating more flexible dashboards on top of warehouses and what could be different. I wanted to offer this as a Show HN for folks to try out but it is currently a bit too expensive to run this publicly for us, that's why we are initially enabling access to the feature only to a select set of customers.

Let me know if you have any thoughts or what would you imagine seeing in this space.

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

Points: 1

# Comments: 1

About the staging dump, I haven't tried it but I don't see why it wouldn't work? I'll give it a try.

Yes, we'll create and share a helm chart, although we already publish Docker images so it should be trivial to spin up a chart if you wanted to.

ingestr is a CLI tool that can ingest data from 130+ sources. I have shared it on HN after our Go rewrite as well, which made it the fastest ingestion tool in the space. However, ingestr had always been a batch tool. I am personally a big fan of batch workloads due to their simplicity and have built ingestr around that assumption as well; however, over time, the cracks started to show when we started working with larger orgs.

Turns out there are some scenarios where CDC proves beneficial: - For legacy systems where it is not possible to introduce cursor columns due to technical, but mostly organizational, concerns, it becomes impractical to deploy batch pipelines. - For systems that do not have a way to reliably know the update timestamp, also due to legacy reasons. Think usecases where the columns are updated without the timestamp being updated. - For hard deletes.

Even though I do believe there are ways to solve each of these, it ended up putting us in a disadvantage, and we decided to build the CDC connectors instead.

ingestr CDC works in two modes now: batch (bad name, I know) and stream. The batch mode is reading the changelog entries from the last load until the starting timestamp, and the streaming mode keeps reading and landing them to the destination databases.

ingestr has a few advantages compared to a more traditional debezium + kafka setup: - it's a standalone Go binary and does not require any additional infra. - it has very low resource consumption, ~100MB baseline. - it can run on your own computer during development, and can be converted into a streaming prod deployment when it is ready. - supports 20+ destinations already, primarily analytical platforms like snowflake, databricks, generic iceberg destinations, etc.

i would love to hear any feedback on what we could do to make it easier for cdc workloads!

https://github.com/bruin-data/ingestr

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

Points: 2

# Comments: 2

Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?

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

Points: 3

# Comments: 0

I really like that you did this in Go, and I'll definitely dig a bit more into the source code to see how you tackled the CDC stuff, given that there is not many reliable CDC libraries in Go, and there are quite a few gotchas when it comes to doing CDC right. We also hand-rolled ours in ingestr, or I must say clanker-rolled, and we got quite a few things wrong in the first place.

Curious about the postgres-compatible query option: what's the usecase you have in mind there? My perception is that any org that would use Iceberg also has one or a few query engines in place, is this more for debugging stuff?

Quite cool stuff, keep it up!