SECURITY & DEPLOYMENT
What counts as a record?
Pricing is by the records you index. A record is one row of a collection - one order, one product, one customer - so the count is a design decision, not a surprise.
- One row in a collection is one record: one order, one product, one customer, one invoice
- A product with three variants, indexed as three rows, is three records
- The same order in two collections counts in each
- Fields, facets and queries are not records
- Rows you choose not to index are not records
- Basicup to 1M records
- Standardup to 2M
- Professionalup to 5M
- Advancedup to 10M
- Enterpriseunlimited
One row, one record
An index server stores collections, and a collection is a flat set of records: one per order, one per product, one per customer, one per invoice. A record is the thing a screen shows as a row and a facet counts as one. When a product is priced by the number of records indexed, this is the unit: not fields, not queries, not facets, not users, but rows in the collections you chose to build. The count is therefore not a surprise that arrives with the first invoice. It is a number you can work out before the first import, from decisions you make about what to index.
The count is a design decision
- Orders table1 row per order
- Orders collection1 record per order
- Products collection1 record per variant
- Your record countsummed across collections
Three choices move it. Which collections. Index what the screens ask about. If no screen asks about invoices, the invoices are not records yet. What grain. A product with three variants can be one record with variant fields or three records, one per variant; the right answer depends on whether the screen filters by variant, and it changes the count threefold. An order with ten lines is usually one record with the lines flattened into it, not ten. How much history. An orders screen that shows the last two years does not need five years indexed. The collections are copies, so the choice can change later, and the count changes with it.
Three choices, worked through
Orders and their lines. If the screens ask "which orders" - by status, region, customer, date - the order is the record and its lines are fields inside it. If a screen asks "which products were sold in which orders", a second collection of order lines may be worth its records. Most businesses start with the first and add the second only when a screen needs it.
Products and variants. A catalog that filters by size and colour wants variants as records, because a facet counts records and the shopper wants to see Polo · M · 234. A catalog that shows one listing per product and lets the shopper pick the size afterwards wants products as records with sizes as a field. Same data, different grain, different count.
History. Two years of orders in the index and five in the database is normal. The database keeps everything; the index keeps what the screens show. If an analysis needs the older years, index them into a separate collection for the time it takes, then drop it.
What is not a record
Fields are not records; a wide record is still one. Facets, searches and dashboard loads are not records; they are reads, and reads are not counted. Users are not records. Rows in your database that you did not index are not records, however many there are. And a record that appears in two collections - an order in the orders collection and, flattened, inside an invoice - counts once in each, because it is stored in each. The count is the number of records the index holds, which is the number you asked it to hold.
Estimating yours
| Collection | What one record is | Estimate from |
|---|---|---|
| Orders | One order (its lines flattened into it) | Orders per month × months you index |
| Products | One product, or one variant if variants are rows | The product master, after choosing the grain |
| Customers | One customer account | The CRM or account table |
| Invoices | One invoice | Invoices per month × months you index |
| Total | The sum of the collections | Add them up, then add a year of growth |
Add a year of growth, because the tier should still fit in twelve months, and round up. A company with a few hundred thousand orders a year, a product master in the tens of thousands and a customer base to match lands comfortably in the first tier; a retailer with many millions of order lines decides the order grain first, because that decision alone moves the tier.
The tiers
Pricing is a one-time setup fee plus a monthly subscription per licence, set by the number of records you index: up to one million, two million, five million, ten million, and unlimited on custom terms. Every deployment includes the index itself; dashboards and the assistant are optional and priced around your use cases. Additional licences are billed at half price. The current figures are on the pricing section of the home page, and the tier is the only part of them that your record count decides.
When the count changes
Counts grow with the business and with ambition. Orders accumulate; a new screen wants a new collection; a pilot that indexed one region is extended to all of them. Because the collections are copies, growth is a configuration change rather than a migration, and the tier moves when the count crosses the line. Going the other way is just as easy: a collection nobody reads can be dropped, and old years can be trimmed from a collection whose screens stopped showing them. The number to watch is on the collections page, and it is the same number the bill is based on.
Why records, and not something else
Records are the honest unit because they are the thing you control and the thing that costs something to hold. Pricing by query would punish the screens the index exists to make fast; pricing by user would punish the dashboards it exists to share. Pricing by what is indexed means the bill follows the decision you made about scope, and you can see the number in the collections themselves. Connecting your database is where that scope gets decided, collection by collection.