Hi everyone. I’m in the middle of a pretty extensive evaluation process for a new analytics pipeline, and Granola is one of the three finalists on my shortlist. I’ve been tasked with building a comparative proof-of-concept for each vendor, focusing on real-world API resilience, cost predictability, and integration overhead.
I set up my test environment this morning, aiming to simulate a moderate load of batch data ingestion followed by some real-time querying. My plan was to run through a typical workflow: schema definition, posting several thousand records, and then running a series of aggregate queries to see latency and syntax flexibility.
I literally just started—maybe 45 minutes in—and I’ve already been hit with a `429 Too Many Requests` response. I wasn’t doing anything I’d consider aggressive. To be specific, I was:
* Sending small batch posts (100 records per call) to the `/v1/ingest` endpoint, with a 100ms delay between calls.
* Running a few concurrent `SELECT` queries via the SQL endpoint to benchmark response times under light load.
* All of this from a single test runner instance.
I’ve double-checked the plan details on my account page, and I’m on the “Pro” trial tier. The documentation mentions “rate limits apply” but doesn’t publish the actual numbers for each tier on the public pricing page, which is a bit frustrating.
My immediate questions are:
* Is hitting a limit this quickly a common experience during the evaluation phase? It brings up serious concerns about throughput for our actual use case.
* Does Granola typically provide detailed rate limit specs (requests per minute/second, bandwidth caps) during sales conversations or only upon signing a contract? This is a key piece of our TCO and capacity planning.
* I’m now blocked for what the API says is “3600 seconds.” Has anyone found a reliable way to get a limit increase for testing purposes, or is this a hard stop designed to push evaluators toward a higher-tier plan?
The reason I’m so concerned is that if the standard Pro tier has limits this low in production, the jump to an Enterprise plan (which requires a custom quote) might completely change the cost-benefit analysis versus the other platforms we’re looking at. A big part of my RFP process is mapping out predictable scaling costs.
I’d really appreciate any insights from others who’ve stress-tested the API during their own procurement cycles. Did you encounter similar walls? Were sales teams responsive in providing clear, documented limits for scaling?
You're running into a classic issue with tier-based rate limiting. Their "Pro" plan likely has a global request-per-second cap that aggregates calls across all endpoints, not just per endpoint. So your 100ms delay on `/v1/ingest` plus the concurrent SQL queries probably pushed you over the shared limit.
You can test this by checking if the headers in the 429 response include a `Retry-After` value. If they don't, it points to a fixed-window quota, which is less flexible than a token bucket system.
For your PoC, I'd suggest checking the dashboard for a real-time usage graph if they have one, and separating your ingestion and query phases completely. Run all your batch posts first, then do the query benchmarking in a separate block. It's a bit artificial, but it'll help you measure the actual throughput of each function.
connected
The "global request-per-second cap" is a generous interpretation. More likely, it's a poorly implemented per-tenant throttle on their shared infrastructure. I've seen this exact pattern before with other services that label it "Pro".
> If they don't, it points to a fixed-window quota.
Not necessarily. It could just mean they don't bother telling you when to retry, which is worse. You're left guessing. A token bucket system without proper headers is functionally the same as a fixed window for the client.
Separating ingestion and querying might let you pass the PoC, but it papers over the real issue. In production, you'd have both operations happening concurrently. If their rate limit can't handle a simple test workflow, imagine the fun of a real data pipeline with retry logic firing off.