Artie now runs Apache Kafka for you on AWS. You pay AWS’s price for the infrastructure plus 25% on the brokers, and that’s it. Three r8g.large brokers with 1 MB/s in and 500 GB retained come to $436 a month, compared with $1,110 for the same cluster on Amazon MSK. Once your cluster is up, our engineers are on call for it. Artie Managed Kafka replaces failed brokers, rebalances partitions, grows disks before they fill, moves older data to S3, and rolls out upgrades one broker at a time. Last night a streamer tried running Kafka himself, live. By 3 AM his disks were full, a broker was on fire, and the partition reassignment had four hours left. Someone in chat told him to “just use managed.” Chat was right.

Artie has a new brand. The elephant stayed. The wordmark, palette, illustrations, and website are all new. The old brand described the machinery: pipes, replication, sub-minute latency. The new one shows what that machinery is for. Billing that’s right on the first invoice. A/B test results you can read while the test is still running. Agents answering from data that landed a minute ago, not yesterday. Nothing changes for customers. Same pipelines, same latency, same elephant in the dashboard.

Managed pipelines shouldn’t feel like a black box. Activity Log is now live on Artie. One company-wide timeline for your pipelines: > Config changes, with field-level before and after > Who or what acted: a teammate, an API key, or Artie itself > Deployments confirmed, alerts fired and resolved, webhook deliveries Filter by service, outcome, or actor. Open any event to see which pipeline it touched and what changed. Find it under 'Activity' in the Artie dashboard.

Firecrawl is the API for the web. More than 1.5 million developers build on it. The company is growing fast, and the data is growing with it. With one data engineer, Rahul Singh, @firecrawl uses Artie to move around 4 billion rows a month from Postgres into BigQuery. That data feeds every dashboard, usage report, and spending decision the company makes. Since Firecrawl started on Artie in December 2025, it has raised a $75M Series B, and the pipeline hasn't had to change. When Rahul moved a large share of the data from Supabase to PlanetScale, he used Artie for that too, and the replication side was done within two days. In his words: "It just runs in the background, and I don't have to worry about it."

Aurora PostgreSQL can now query Apache Iceberg tables in S3 directly. You can join live Postgres rows with years of history in your lake in a single query, without a pipeline copying that data back into the database. It uses DuckDB embedded in Aurora, following AWS’s acquisition of DuckLabs (the team that maintains DuckDB). This solves the read side. But something still has to keep those Iceberg tables current, through schema changes, backfills, and high write volume. That’s what we do at @artie_labs – we stream changes from operational databases into Iceberg-backed tables in Amazon S3 Tables, so the history Aurora reads stays fresh.

Artie supports fan-in across Postgres schemas, MySQL databases, and @PlanetScale keyspaces. Consolidate every tenant’s operational data into one continuously updated destination table, without centralizing your application database. Multi-tenant applications often keep each customer, region, store, or business unit in its own database namespace. Instead of managing separate copies of the same data across every tenant, Artie continuously fans in matching tables into one destination table. Use an explicit allow list when the set is stable, or use regex rules to automatically include new tenant databases as they launch, with no manual pipeline updates needed. That means fewer one-off pipelines, less downstream UNION logic, and one canonical dataset for customer-facing applications, automated workflows, AI applications, and analytics.

Great day at Rows & Columns Summit – was awesome seeing two talks mention @artie_labs! 1. Our founding engineer William Haw joined James Sutton, CTO at ShipScience, to share how ShipScience uses Artie’s streaming CDC pipeline to move row-level changes from its production MySQL database to MotherDuck. The pipeline handles roughly 30 tables and 3 billion row updates each month, keeping analytics and agent workloads off the production database. 2. Shalaka Borker, Director of Data Engineering and Analytics at Roofstock, mentioned Artie in a discussion of moving reporting workloads off operational databases and onto a continuously updated analytical layer. Their report-rendering times dropped from minutes to seconds. Big thanks to the @clickhouseDB team for bringing together a room of data practitioners to discuss the evolving world of transactional and analytical systems. We’re already looking forward to next year’s summit.

Artie is at Rows & Columns Summit today at the Contemporary Jewish Museum in San Francisco! At 2 PM, our founding engineer William Haw will join James Sutton, CTO of ShipScience, for a talk on how ShipScience moved 3 billion MySQL row updates per month out of production and into MotherDuck with Artie. If you’re at the summit, come say hi!

Standing up a production CDC pipeline used to mean designing source access, replication, backfills, destination writes, schema-change handling, monitoring, and recovery. Now, it can done with a single prompt: “Create a pipeline from the staging Postgres database to Snowflake.” With Artie MCP available in Claude Code, Cursor, and Codex, an AI agent can use Artie’s tools to configure and manage that workflow. So engineers can start with what they need, instead of spending months assembling and maintaining the pipeline themselves.

Artie now exports pipeline metrics to @Grafana Cloud Metrics. Teams already using Grafana Cloud can monitor database, Kafka, warehouse, application, and now Artie pipeline signals in one place. Artie exports six metrics directly to Grafana Cloud’s Prometheus remote-write endpoint, without needing to deploy Grafana Alloy, Prometheus, or a separate collector yourself: ☑️ Rows processed: pipeline throughput ☑️ Ingestion lag and row lag: whether data is arriving and becoming available on time ☑️ Flush time and flush count: write behavior ☑️ Replication slot size: PostgreSQL replication health Compare Artie ingestion lag with source-database and warehouse signals when you need to investigate a data freshness issue. Or create a Grafana alert when a lag, flush, or replication-slot metric crosses a threshold your team defines. Import the Artie Overview dashboard to get started, then adapt it to the Grafana workflow your team already uses.

We filmed three data engineers in their natural habitat. Not shown in the doc: > Monitoring a pipeline that was 'definitely fine' five minutes ago. > Reading logs like they’re a crime scene. > Doing recovery math while someone asks if the dashboard is up to date yet. Moving data is easy. What’s difficult is keeping data correct and current, and knowing how to recover when pipelines restart, schemas change, or data falls behind. That’s why Artie now has a Free plan: so anyone can run real-time replication without building and operating the infrastructure themselves. Deploy a pipeline and watch your data replicate in real time. Try it:

We benchmarked Artie vs. AWS DMS on real-time CDC from Postgres to Snowflake, under sustained writes of ~22,400 events/sec for 10 minutes. Midway through the test, DMS had already piled up 3.7GB of WAL backlog. By the end, it hit 6.1GB, growing faster in the second half. Meanwhile, Artie barely moved: 381MB to 385MB. A CDC tool that falls behind doesn't just give you stale data. It can fill up disk on your production database and in some cases, take it down entirely. Full breakdown👇