One Nice Box, Not Four Meh ones.

The "modern data stack" is at the very least four products duct-taped together with disappointment and solid frustration. Fivetran moves data. Snowflake and Databricks store and compute it. dbt transforms it. Then you need something else to consume it. That's four vendors, four customer relationships meetings, few sets of billing, docs, and stuff that will break anyways at some point outside of your SLA for miraculous reasons.

We built one thing that does most of what we want from those big ones. We are not the best at limiting our ambitions but we did try to reduce ourselves to the essence of what those tools provide, and then built that as to remain as stupidly simple as possible.

Check our stack

Stripe, Postgres, HubSpot, Shopify, ...
              |
    [ rawquery connections ]    ← This where ingestion happens
              |
    [ S3 + Apache Iceberg ]     ←  This where your data live
              |
    [ DuckDB engine ]           ← This what replaces why big boys get big money against your will.
              |
       ┌──────┴──────┐
    REST API     Wire protocol  ← This how you can talk to your data
       |              |
    curl/app     psql/charts    ← This extra fluff because we also have an ego

That's more or less it. Our thing does ingests, stores, computes, and serves. You don't configure integrations between products because there's nothing to integrate.

The imaginary scenario to give you an example;

You add a Stripe connection. You click sync - or ask your favorite claude to do it for your more likely -. Data lands in our tables. You open the SQL editor and query it - or ask your favorite claude ... -. You save that query as a transform - or ask your favorite claude ... -. The transform runs after every sync. You save a chart from the result, publish it, share the link. Done.

At no point did you have to open a second product. At no point did you write a YAML file to tell one tool where to find the output of another. The data flows through one system, and you interact with one interface. That's our hope, and vision.

A - short side quest around the- debugging argument

Something breaks. With a your multi-vendor stack, you start the investigation: is it a Fivetran sync issue? A Snowflake compute problem? A dbt model that failed silently? You open three browser tabs and a claude instance, correlate stuff across three systems, and thirty days later you find out what it was. Maybe.

With our single system, you look in one place. The sync log tells you what landed and when. The failed transform shows up in the run history with the error. One place to look, one story to follow. And as we grow, more logs so that you can do your own debugging like a big person when you screw up your own pipelines.

"But what if I outgrow you?"

Fair question. The data sits in Apache Iceberg, an open table format. If you outgrow rawquery, your data is right there. Walk away. Anytime and take everything with you. Thanks for the fish. We chose open standards so that staying is always your choice.

Our honest insight is that most startups and SMBs will never outgrow us. If you're processing under a terabyte (and the vast majority of companies are) the bottleneck is not gonna be us. It's the time you spend managing your data instead of asking questions to it. But even if you do grow to that scale faster than we can support it - and we gonna support it - well, you can still walk away.

Try us

# Install the CLI
curl -sSL rawquery.dev/install.sh | sh

# Connect Stripe
rq connections create my-stripe --type stripe -p api_key=sk_live_xxx

# Sync your data
rq connections sync my-stripe

# Query it
rq query "SELECT * FROM my_stripe.customers LIMIT 10"

# Install the CLI
curl -sSL rawquery.dev/install.sh | sh

# Connect Stripe
rq connections create my-stripe --type stripe -p api_key=sk_live_xxx

# Sync your data
rq connections sync my-stripe

# Query it
rq query "SELECT * FROM my_stripe.customers LIMIT 10"

One tool. One place to look when things go wrong and complain online about. That's our whole pitch.