Nothing gets pre-generated
Availability, like pricing, resolves at the moment it's asked for, from rules and exceptions. There's no maintenance job creating rows in advance, and nothing to fall behind on.
Speed & Reliability
Fast today. Just as fast at ten times the traffic.
A ten-year calendar costs exactly what querying tomorrow costs. Bulk operations run as single round trips, not one query per row. And the indexes that reporting and pricing depend on already existed before the volume that would need them.
- Zero pre-generation A ten-year calendar costs exactly what querying tomorrow costs
- 1 round trip Bulk operations run as single batched queries, verified by tests that count the real query log
- Queued, not blocking CSV imports and confirmation emails run in the background, in chunks, never holding up the person who triggered them
Four pieces of staying fast.
Each one removes a different way performance usually degrades quietly, until it doesn't.
Batch, never row by row
Loading capacity pools for a calendar, resolving prices across a range of dates, or importing a CSV of stock codes all run as a bounded number of queries, regardless of how many rows are involved.
Indexes exist before they're needed
Reporting, availability and pricing queries are backed by indexes designed alongside the feature itself, not added later once something got slow in production.
Background work stays off the request
Large imports and confirmation emails run through a queue, so uploading ten thousand stock codes or sending a receipt never makes anyone wait on the page.
How it resolves
How speed gets proven, not just claimed
Five practices behind why the platform stays fast as data grows, not just when it launches small.
- 1
A query count gets asserted, not assumed
The sales report is tested with 3 orders and again with 30, asserting the exact same number of queries both times, so "this scales" is something a test actually checks, not just a hope.
- 2
A CSV import runs in bounded chunks
A stock import streams the file 1,000 rows at a time, inserting each chunk as one batched write instead of one row at a time, so a file with tens of thousands of lines never holds one giant transaction open.
- 3
A queued job waits for the transaction to really commit
Jobs tied to something just written, an order confirmation email, a stock import, only start after the database transaction that created their data has actually committed, never before.
- 4
An index gets built for the query shape it serves
A composite index on organization, status and receipt date serves every report filter at once; a separate one on subject and status serves "who reached this status in this range" queries specifically, because those are genuinely different access patterns.
- 5
A duplicate retry never corrupts the data
If a queued import job gets retried, a per-chunk duplicate check plus the database's own unique constraint stop the same stock code from being inserted twice, so retrying is always safe.
The API, as it is
Speed you can verify, not just claim
The same query-count regression test that guards the sales report, run at two different order volumes, asserting an identical query count both times.
TEST BuildsSalesReportTest.php
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
{
"test": "sales report query count",
"orders_in_range": [
3,
30
],
"queries_executed": [
14,
14
]
}Verified by automated test
The detail almost nobody tests for
A report on 3 orders runs exactly as many queries as one on 3 million
The most common way a report silently gets slow is one extra query hiding inside a loop, invisible with a handful of test orders and only visible in production, at scale. Tiqory's test suite pins the exact query count for 3 orders and re-asserts the identical count for 30, catching a stray per-row query the moment it's introduced, not months later when a customer's order history has grown enough to notice.
Frequently asked questions
No. Nothing about availability is pre-generated or stored ahead of time; every date and slot resolves from rules and exceptions at the moment it's asked for, so a query ten years out costs the same as one for tomorrow.
It processes in the background, in chunks of a thousand rows, inserted as batched writes rather than one at a time, and never blocks the person who uploaded it from using the rest of the panel.
A test builds the report with 3 orders, then with 30, and asserts the exact number of database queries stays identical both times. That's a proven property, not an assumption.
No. A per-chunk duplicate check, backed by a unique database constraint as the final backstop, means retrying a failed import job is always safe and never creates the same stock code twice.
Before. Indexes for reporting, availability and pricing queries are designed alongside the feature that needs them, as part of building it, not appended later as a fix once a query starts timing out.
More bookings. More channels. The same calm.
Tiqory keeps availability, pricing, payments and access working together as your operation grows. Tell us where you are headed; we’ll show you how to get there without starting over.