Our first offering is OrderProof which records Shopify transaction evidence and generates PDF to help merchants streamline chargeback disputes.

https://turboops.io/products/orderproof

----

more about the problem here:

https://www.linkedin.com/pulse/you-losing-shopify-chargeback...

I feel like many of the AI insights featured on hackernews are from the software engineers Point of View?

There's also the perspective of vibe-coded-to-prod disaster scenarios.

For me, as a software engineer with nearly 20 years experience, AI is already more trustworthy than many contractors I've worked with over the years.

As a founder/product manager, a lot of trust is put into the engineers building the platforms. The Founder <-> Implementer interaction already involves huge amounts of trust. Things happen all the times, and C-suite executives don't have the ability to fix themselves.

My interpretation is that a lot of engineers are just encountering this trust relationship for the first time with AI. We're trusting AI (a ~contractor) to do something to spec. Advanced engineers are able to audit the AI output at a very deep level.

For founders / product managers / executives, this relationship is nothing new, and we already trust other parties to implement our code.

What does everyone think?

Going from contractor to LLM is actually a huge benefit to me, LLM has a much faster feedback loop than human contractors, costs a fraction and has a lower base rate of error (in my experience). Nothing new with the trust model.

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

Points: 2

# Comments: 1

https://turboops.io/platform/public-tracker

Our first offering is a tracker for makers, small businesses and contractors to show job status. Create a real time status page for your products, build trust and reduce customer inquiries.

We’re working on email notification support right now and have evidence (tracking numbers, job pictures, contracts/documents, etc) support coming next week!

Our first offering is a public tracker view, similar to the tracker provided by pizza companies in the US!

The goal is to enable companies to reduce status emails and build brand trust!

TurboOps are built on "workflows" which are just DAGs. We have a lot more plan but are focused on makers right now!

It's free to get started and to try it out, and build public graphs!

I'd really appreciate your thoughts, impressions, and/or criticisms.

Thank you!

danny@turbolytics.io

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

Points: 7

# Comments: 0

The stream is achieved by the continuous flow of data from Kafka.

SQLFlow exposes a variable for batch size. Setting the batch size to 1 will make it so SQLFlow reads a kafka message, applies the processor SQL logic and then ensures it successfully commits the SQL results to the sink, one after another.

SQLFlow provides at least once delivery guarantees. It will only commit the source message once it successfully writes to the pipeline output (sink).

https://sql-flow.com/docs/operations/handling-errors

The batch table is just a convention which allows for seamless batch size configuration. If your throughput is low, or if you require message by message processing, SQLFlow can be toggled to a batch of 1. If you need higher throughput and can tolerate the latency, then the batch can be toggled higher.

Based on the tributary documentation, I understand that tributary embeds kafka consumers into duckdb. This makes duckdb the main process that you run to perform consumption. I think that this makes creating stream processing POCs very accessible. It looks like it is quite easy to start streaming data into duckdb. What I don't see is a full story around Devops, operations, testing, configuration as code etc.

SQLFlow is a service that embeds DuckDB as the storage and processing brains. Because of this, we're able to offer metrics, testing utilities, pipelines as code, and all the other DevOps utilities that are necessary to run a huge number of streaming instances 24x7. SQLFlow was created as a tool that I wish I had to for simple stream processing in production in high availability contexts :)

SQLFlow uses duckdb internally for windowing and stream state storage :), and I'll look at extending it to support stream / stream joins.

Could you describe a bit more about your use case? I'd really appreciate it if you could create an issue in the repo describing your use case and desired functionality a bit!

https://github.com/turbolytics/sql-flow/issues

We were looking at solving some of the simplier use cases first before branching out into these more complicated ones :)

We leverage DuckDB as the stream processing engine, which gives SQLFlow the ability to process 10's of thousands of messages a second using ~250MiB of memory!

DuckDB also supports a rich ecosystem of sinks and connectors!

https://sql-flow.com/docs/category/tutorials/

https://github.com/turbolytics/sql-flow

We were tired of running JVM's for simple stream processing, and also of bespoke one off stream processors

I would love your feedback, criticisms and/or experiences!

Thank you

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

Points: 77

# Comments: 13

  We're excited to share Librarian, an open-source database replicator built for the cloud-native era.

  The Problem We're Solving:

  Traditional CDC solutions like Kafka Connect require JVM runtime, complex connector management, and expose generic infrastructure metrics that
  don't help you debug data pipelines. We built Librarian to change that.

  What Makes Librarian Different:

   Single Binary - No JVM, no external dependencies, no connector management. Just run it.

   Truly Lightweight - Runs on modest hardware with minimal resource overhead

   Pipeline-First Observability - Built-in stats server that shows what matters: events processed, bytes transferred, and error counts—not
  garbage collection metrics

   Native Replication - Uses MongoDB Change Streams and PostgreSQL logical replication for efficient, real-time CDC

   Debezium Compatible - Drop-in replacement for existing Debezium consumers

  Supported Today:
  - Sources: MongoDB, PostgreSQL
  - Targets: Kafka, S3 (Parquet), Local filesystem

  Get Started in Minutes:

  Stream MongoDB changes to Kafka with a single command. No configuration files, no cluster setup—just a simple URL-based connection string and
  you're streaming data.

  Librarian is open source (MIT license). We'd love your feedback as we continue building.

  Check it out: github.com/turbolytics/librarian

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

Points: 3

# Comments: 0

I'm building kafka connect (i.e. Debezium) compatible replication:

https://github.com/turbolytics/librarian/pull/41

-----

I really like the mongo change stream API. I think it elegantly hides a lot of the complexity of replication. As a side-effect of building postres -> kafka replication, I'm also trying to build a nicer replication primitive for postgres, that hides some of the underlying replication protocol complexity!

DuckDB for stream processing:

https://github.com/turbolytics/sql-flow

Lightweight kafka stream processing using DuckDB as the execution engine. 300MiB runtime can easily handle thousands of messages / second.

Working on a Kafka Connect alternative:

https://github.com/turbolytics/librarian

Right now mongo replication (through changestreams) is supported to kafka. Working on Postgres support right now.

The reason I’m wondering is because it’s striking how much more financially challenged my Main Street is compared to Vc texh.

I see so much opportunity for a small medium business consultation in the analytics and process space but these companies are like really strapped for money and largely set in their ways in my experience.

In my experience, people are open to solving their problems. It’s just the money is hard making it financially viable so it’s just the big money is just like an order of magnitude smaller.

Another thing I’ve noticed is that I think the general level of sort of like process thinking and data driven decision making in tech is at just like a higher baseline than on Main Street

A lot of my discussions are challenging how to sort of like present the problem in a way that somebody that doesn’t have decades of experience and operations understands.

Another challenge that I face regularly with Main Street companies is just people seem to be happy like they’re not trying to continuously optimize like I’m used to doing coming for a big tech. Even when it’s easy to present like positive ROI opportunities there’s just like a comfort with the way things are done and a lot of people seem just happy governed by their scaling factors in exchange for that that comfort.

TLDR; challenges are financial and mentality.

https://github.com/turbolytics/sql-flow

Building a company around a tool is hard. There's been some interest but streaming is kind of commoditized.

I'm taking everything I learned building it and working on a customer-facing security product, more to come on that :)

SQLFlow is a stream processing engine that ingests data from kafka, runs sql against that stream and sinks the output.

SQLFlow has a duckdb context available during stream processing. This make it trivial to stream data from Kafka to Ducklake!

https://sql-flow.com/docs/tutorials/ducklake-sink/

https://github.com/turbolytics/sql-flow

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

Points: 2

# Comments: 0

https://github.com/turbolytics/sql-flow

It has some interest, unfortunately building tools as a business strategy is rough.

Beginning to work on first actual product! More soon :)

For my uses it's great that it has both test suite mode and individual invocation mode. I use it to execute a test suite of HTTP requests against a service in CI.

I'm not a super big fan of the configuration language, the blocks are not intuitive and I found some lacking in the documentation assertions that are supported.

Overall the tool has been great, and has been extremely valuable.

I started using interface testing when working on POCs. I found this helps with LLM-assisted development. Tests are written to directly exercise the HTTP methods, it allows for fluidity and evolution of the implementations as the project is evolving.

I also found the separation of testing very helpful, and it further enforces the separation between interface and implementation. Before hurl, the tests I wrote would be written in the test framework of the language the service is written in. The hurl-based tests really help to enforce the "client" perspective. There is no backdoor data access or anything, just strict separation betwen interface, tests and implementation :)

I’d Spend all morning in the dumpster with some friends. Name brand clothes were good finds, also pretty much all the textbooks carried a trade in value. Lots of sealed food snacks as well.

I don’t know if the kids that threw them away were lazy or they just didn’t know about buy back, but the books easily brought me $100 for a couple hours of morning dumpster diving.

https://github.com/turbolytics/sql-flow

I think the industry lacks lightweight fully featured stream processing solutions. I think it’s either heavyweight jvm or bespoke custom solutions

Sqlflow aims to be a middle ground , performant, fully featured, observable and supports sql