Order Fulfillment Monitoring
A paid order is still waiting to ship, but no one has followed up
An order has been paid for more than an hour, yet its shipping status has not changed. The fulfillment team needs to find it before the customer asks where it is. The order record alone is not enough. The team also needs the responsible merchant and region so it can act.
What you will build
This tutorial creates that working example. VeloDB synchronizes order and merchant data from an operational database into an analytical warehouse. One SQL query finds paid orders that have remained unshipped for more than one hour and adds the merchant context needed for follow-up. When an order ships in the source database, the synchronized result changes as well.
How the example works
Order and merchant data in the source database
↓
Initial and incremental synchronization into VeloDB
↓
Join orders with merchant information
↓
Identify overdue, unshipped orders
The workflow demonstrates three parts of an operational analytics pattern:
- Bring the current data into VeloDB. A full synchronization copies the existing
ordersandmerchantsrows. - Keep later changes synchronized. Incremental synchronization captures an order-status update from the source.
- Turn fresh records into an operational answer. A SQL join returns overdue orders with the merchant name and region needed for follow-up.
The sample does not attempt to measure throughput or compare database performance. Its purpose is to make the complete workflow easy to reproduce.
Why VeloDB fits this workload
| Requirement | VeloDB capability used in this scenario |
|---|---|
| Avoid running operational reports against the source application | The selected tables are copied into a VeloDB warehouse for analysis. |
| See source updates without repeating a manual export | Full and incremental synchronization captures the initial rows and later changes. |
| Find the orders that require attention | SQL filters identify paid orders that have exceeded the one-hour shipping threshold. |
| Add the context needed to investigate | A SQL join combines each overdue order with its merchant details. |
For larger production datasets, table design and indexes can provide additional optimization. This small tutorial keeps the focus on synchronization, fresh data, and the business query.
The capabilities behind the workflow
- Full and incremental synchronization brings in the existing tables and then captures later changes. Learn how native CDC works for MySQL and PostgreSQL.
- Current-state analytics keeps changing operational records available for SQL queries. Read the real-time update technology deep dive for the engine-level concepts behind update-heavy workloads.
- SQL filters and joins turn fresh records into a business answer by finding overdue orders and adding merchant context.
For a larger production example of frequently updated logistics data, read the ZTO Express customer story. Its workload and reported results are separate from this small synthetic tutorial.
Choose your source database
The tutorials use the same synthetic order data and produce the same business result. Choose the version that matches your source database:
| Source database | Tutorial |
|---|---|
| MySQL | Monitor Order Fulfillment with MySQL and VeloDB |
| PostgreSQL | Monitor Order Fulfillment with PostgreSQL and VeloDB |
In either version, you will:
- Create a small
orderstable and amerchantstable. - Configure full and incremental synchronization into VeloDB.
- Query the current list of overdue orders.
- Mark an order as shipped in the source database.
- Confirm that the synchronized update removes it from the overdue-order result.
All names, IDs, regions, timestamps, and amounts used in these tutorials are synthetic.
Return to the Real-Time Operational Analytics overview to see how this scenario maps to the broader product capabilities.