Artie

Robin Tang and I are both immigrants. For years, our ability to stay in this country depended on a visa. (It still does) So when candidates ask, “Do you sponsor visas?” The answer is simple: Yes. Of course we do. Because we know what it feels like to build your life on a ticking clock. But here's the thing about great people: they're hard to find. High-agency ones are even harder. So you do whatever it takes to help them succeed. We help with visas. We relocate. We obsess over onboarding. We give real ownership. Artie is growing faster than ever. Firecrawl, Substack, Alloy and more trust us with their data infrastructure. We've built a team that is sharp, relentless, and just gets things done. The work is challenging but critical (CDC, replication, distributed systems). Come join us. We're hiring.

A customer messaged us last week: "Artie is the best real-time CDC connector I have used so far" Sometimes success can't be captured by a specific metric.

A 7-figure deal almost died in the first 10 minutes. Not over price, not over the demo. Over one slide. We showed our "after" architecture and it had more boxes than their "before." You could see the room doing silent math: Do I own this? Who's on-call? What breaks at 2am? We weren't selling. We were adding work. So before the next meeting we changed one thing. "After" = one box. The meeting was shorter, sharper, and the deal was back on track. The most dangerous thing in enterprise sales isn't pricing or competition. It's complexity dressed up as innovation. If your "after" is more complex than their "before," you're not selling simplicity. You're selling pain.

At ShipScience, we implemented MotherDuck as our EDW with the original intention to move large analytical queries and agentic workflows off of our production MySQL database. (And using Artie via CDC to do it).  The biggest benefit we’ve realized was somewhat unexpected – this has increased our ability to rapidly QA releases, fix bugs, and improve our products. Claude is connected directly to a copy of our production data via Motherduck, github repos, and Sentry logs. So when something arises that needs research, it has full context to figure out the why and recommend a solution. Bugs that typically would take hours to figure out what changed and how to fix is now a prompt.  Real example – FedEx DIM’d package % (amount of packages that were billed based on dimensional rules instead of actual weight) spiked across most of our customer-base and was flagged by our Transportation Analyst AI Agent. But the average cost per package did not increase, which I would expect to happen with more DIM’d packages. Nothing changed in our code, and no announces were made by FedEx about DIM billing changes (https://lnkd.in/gmJfFw5w). What actually happened was that FedEx stopped populating the “Actual Weight” field in their carrier invoices, and now only populates the “Estimated Weight” field. Our DIM calculation logic relied on the actual weight data, and without it had unintended consequences.  We were able to fix this logic within 48 hours of it being detected. 

A customer told me something eight months in that I haven't stopped thinking about: "It always felt riskier to NOT buy Artie." The lesson wasn't really about us. It was about how we evaluate risk. We default to "the thing I already use is safe." It isn't. It's just familiar. His old pipeline was taking him down for 1-2 days at a stretch. The cost of doing nothing was already on his calendar every week. He just hadn't priced it. Most of us are doing this somewhere right now. Familiar isn't free. It's paid in installments small enough you've stopped noticing. Change feels expensive because it's a single line item. The status quo feels free because it's distributed across every week. Familiar isn't free. You're just being billed somewhere you've stopped looking.

Everyone assumes the CEO of a data infra startup must be technical. I'm not. (Or I wasn’t). And that used to embarrass me. I spent 2.5 years at a hedge fund sitting through technical deep dives, nodding along, furiously taking notes so I could Google everything later. I was fluent in looking technical. Then I started Artie anyway. Early on, a customer described their pipeline failing at 100 million rows. I didn't know why that number was the ceiling. But I knew to ask what they'd built it on, and the answer told me everything about why they were calling us. That's the thing nobody tells you: you don't need to write code to build something technical. You need to understand why systems are built the way they are. The tradeoffs. The constraints. The decisions that paint you into a corner 18 months later. AI is eating the syntax. It can't eat judgment. The founders who win aren't the ones who can code. They're the ones who stop performing competence and start asking the questions nobody else in the room will ask, because they're not trying to pass a test. Be curious. Be rigorous. Never stop learning.

Three years of customer calls. This is how I'd actually describe each one.

Thank you AI Council for having me. We scaled CDC at Artie from a forked Debezium to a custom system handling 20-30B events a day. What breaks at scale isn't what you expect: - Replication slot blowup during backfill - Silent failures that only show up downstream - Multi-region schema drift - Negative-precision numerics What's next: AI agents have the same data freshness problem databases always had. Except the lag tolerance is near-zero, and the sources go way beyond databases. The CDC primitives apply. But the surface area is expanding fast, and the primitives haven't caught up yet. Thank you Sai Krishna Srirampur for putting together an incredible Data Eng & Databases track.

Three months ago I made a promise I wasn't sure we could keep. A customer asked us if Artie could land 4 billion rows/month into Iceberg. Sub-minute freshness. Zero impact on their primary database. Across two regions. I said yes. I wasn't lying. It was a bet on 18 months of work we hadn't talked about publicly: 1. We took over the Iceberg catalog so customers don't have to fight it. 2. We took over the merge compute so they stop burning Snowflake credits keeping their own tables tidy. 3. We rebuilt the writer to land directly in Iceberg - no S3-then-Iceberg dance. 4. We made it so you read the source database ONCE and fan out to as many regions as you want. Last month it shipped. 4 billion rows/month throughput. Sub-minute. Zero load on the source. The best sales calls aren't about what you have today. They're about knowing what your team is about to make real. If you're staring at an Iceberg migration and wondering whether what you've been promised is actually possible - DM me. Happy to share what we learned.

One of our engineers was at a baseball game last week. Guy next to him worked in data. Conversation turned to pipelines. By the third inning he'd explained what Artie does, why AWS DMS is quietly broken, and what CDC actually looks like when it works. He wasn't on the sales team. He was there to watch baseball. Here's the thing nobody tells you about early-stage startups: there is no "sales team" and "everyone else." I wasn't technical when we started. All I could do was sell, so I sold everywhere. Demos on weekends. Pitching in bars. That attitude got into the DNA before we had a sales process, before we had a CRM. They're here because they've been paged at 3AM because DMS dropped DDL silently and nobody upstream told them about the schema change. They lived this problem before they came to work on it. That's why they can't stop talking about it at baseball games. You can't hire for that on a job description. You can only build something worth caring about and hope the right people find it.