Tradeshift processes millions of B2B payment transactions across 70 countries. Their in-house BI tool hit a wall: 10,000-row query limits, 25 MB report caps, six-month data retention, and 50% of an engineer’s time spent on maintenance. When you operate a two-sided marketplace for buyers and sellers, those constraints kill product velocity.
They migrated to Amazon Quick, AWS’s agentic analytics workspace. The result: 30x faster query response times, 40% lower total cost of ownership, and embedded analytics that now generates revenue instead of consuming engineering hours.
This is not a prototype. This is a production deployment in financial infrastructure with concrete metrics.
The Legacy BI Trap
Tradeshift’s homegrown BI tool worked fine at small scale. As data volumes grew, the constraints compounded:
- Row limits: 10,000 rows per query meant analysts couldn’t see full transaction histories
- Report size caps: 25 MB ceiling forced data slicing and manual aggregation
- Retention windows: Six months of historical data blocked trend analysis
- Maintenance burden: Half an FTE just keeping the tool running
The tool was built for static dashboards. Business users wanted to ask arbitrary questions. The gap between “what can we show” and “what do customers need” widened every quarter.
Amazon Quick’s Agentic Layer
Amazon Quick is not a traditional BI tool. It is an agentic workspace that sits on top of your data sources and exposes three primary interfaces:
- Chat agent: Natural language Q&A over business data
- Flows: Multi-step workflow automation without code
- Research: Long-form analytical reports synthesized from multiple sources
The architecture separates query translation from execution. When a user asks a question in natural language, the agent:
- Parses intent and identifies relevant data sources
- Generates optimized SQL (or equivalent query language)
- Executes against the underlying data warehouse
- Returns results in conversational format
Tradeshift connected Quick to their existing data warehouse. No ETL rewrite. No schema migration. The agent layer sits between users and data, translating requests into optimized queries.
Query Optimization Without Semantic Layers
Traditional semantic layers add latency. You define metrics, relationships, and aggregations in advance. Every query passes through this abstraction, which adds overhead.
Amazon Quick skips the semantic layer. The agent translates natural language directly into SQL, using:
- Schema introspection: The agent reads table structures and relationships at runtime
- Query planning: It generates execution plans optimized for the target database
- Caching: Frequently requested patterns are cached at the result level, not the semantic level
Tradeshift saw 30x speed improvements because the agent generates queries tuned for their specific database (likely Amazon Redshift or Athena, though the post does not specify). No intermediate abstraction. No pre-aggregation overhead.
The trade-off: You lose centralized metric definitions. If “revenue” means different things in different contexts, the agent will not enforce consistency unless you build guardrails into the schema or prompt engineering.
Embedded Analytics as a Product
Tradeshift turned analytics into a revenue stream. Here is what that means architecturally:
They white-labeled the Quick interface and embedded it into their customer-facing platform. Buyers and sellers on the Tradeshift network can now ask questions about their own transaction data without filing support tickets or waiting for custom reports.
The multi-tenant isolation happens at the data layer, not the agent layer. Each customer’s queries are scoped to their own data partition. The agent does not see cross-customer data. This requires:
- Row-level security: Database permissions enforce customer boundaries
- Query rewriting: The agent injects tenant filters into every generated query
- Audit logging: Every query is logged with customer ID for compliance
Tradeshift charges for this capability. Customers pay for advanced analytics access. The cost structure shifted from “engineering time to build custom reports” to “metered usage of agent queries.”
State Management and Caching
Moving from pre-computed dashboards to on-demand queries changes how you handle state.
Pre-computed dashboards run ETL jobs overnight. Users see stale data, but queries are fast because results are materialized.
On-demand agentic queries run against live data. Users see fresh results, but you need caching to avoid hammering the database.
Tradeshift’s approach (inferred from the 30x speed claim):
- Result caching: Identical queries return cached results within a TTL window
- Partial materialization: Common aggregations (daily totals, top customers) are pre-computed
- Query fingerprinting: The agent hashes queries to detect duplicates even when phrased differently
The agent does not maintain conversational state across sessions. Each query is stateless. If a user asks “show me last month’s revenue” and then “break that down by region,” the second query does not reference the first. The agent re-executes with the new filter.
This simplifies orchestration but increases query load. The caching layer absorbs the redundancy.
Failure Modes and Guardrails
When business users can ask arbitrary questions, new failure modes emerge:
| Failure Mode | Risk | Mitigation |
|---|---|---|
| Runaway queries | User asks for unbounded joins or full table scans | Query cost estimation, timeout limits, row caps |
| Ambiguous intent | ”Revenue” could mean gross, net, or recognized | Schema annotations, prompt engineering, clarification loops |
| Data leakage | Agent exposes data the user should not see | Row-level security, query rewriting, audit logs |
| Hallucinated metrics | Agent invents calculations not in the schema | Restrict to schema-defined columns, validate SQL before execution |
| Cost explosion | High query volume drives up database costs | Rate limiting, query quotas, cost alerts |
Tradeshift does not detail their guardrails in the post, but the 40% TCO reduction suggests they implemented cost controls. Likely candidates:
- Query result caching to reduce database load
- Rate limiting per customer to prevent abuse
- Pre-approved query templates for common questions
Deployment Shape
The architecture looks like this:
┌─────────────────┐
│ Customer Portal │
│ (Tradeshift) │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Amazon Quick │
│ (Agent Layer) │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Data Warehouse │
│ (Redshift/ │
│ Athena) │
└─────────────────┘The Quick agent is hosted by AWS. Tradeshift does not run agent infrastructure. They configure:
- Data source connections (warehouse credentials, schema access)
- Tenant isolation rules (row-level security policies)
- UI embedding (iframe or SDK integration into their portal)
The agent handles:
- Natural language parsing
- SQL generation
- Query execution
- Result formatting
Tradeshift’s engineering team focuses on schema design and access control, not agent orchestration.
Cost Structure Shift
The 40% TCO reduction comes from:
- No in-house tool maintenance: Eliminated 50% FTE cost
- Pay-per-query pricing: Amazon Quick charges for usage, not seat licenses
- Reduced support load: Customers self-serve instead of filing report requests
The revenue generation comes from:
- Tiered analytics access: Basic dashboards free, advanced agent queries paid
- Usage-based pricing: Charge customers per query or data volume
- Premium insights: Sell access to cross-network benchmarks (anonymized)
The financial model flips from cost center to profit center.
Technical Verdict
Use Amazon Quick when:
- You have a data warehouse already and need a query interface, not a new data stack
- Your users need ad-hoc analytics, not just static dashboards
- You want to embed analytics into a customer-facing product without building agent infrastructure
- You can enforce multi-tenant isolation at the database level
Avoid it when:
- You need centralized metric definitions and governance (semantic layers still win here)
- Your data is not in AWS or cannot move there
- You require conversational state across multi-turn queries (Quick is stateless)
- Your queries need custom logic beyond SQL (stored procedures, UDFs)
Tradeshift’s migration worked because they had clean schemas, clear tenant boundaries, and a business model that monetizes analytics access. If your data is messy or your customers expect free unlimited queries, the economics break down.
The 30x speed improvement is real, but it depends on your baseline. If your legacy tool was already optimized, the gains will be smaller. If you were running unindexed queries against a monolithic database, the improvement could be even larger.