Key Takeaways
- A growing online shop can benefit from an analytical database when spreadsheet-based reporting becomes too slow, fragmented, or difficult to maintain.
- Columnar storage and parallel processing allow modern analytical databases such as ClickHouse to process large datasets efficiently on relatively modest infrastructure.
- Defining consistent rules for orders, product identifiers, timestamps, and data refreshes is essential before building an analytics dashboard.
- Node-based database pricing can provide more predictable costs than event-based analytics pricing as a business’s data volume increases.
- Smaller shops with limited data and straightforward reporting needs may be better served by spreadsheets until their analytical questions become more frequent and complex.
For a growing online shop, the warning sign is a spreadsheet that has quietly become a project. Orders arrive from a web store and from two or three marketplaces. The data is scattered: marketing spend sits in one export, stock levels in another and the customer list in a third.
Once those files run into tens of thousands of rows, a question as ordinary as how the weekend promotion performed by region means half a day of matching columns, repairing date formats, and refreshing formulas that break the moment a new channel is added.
Half a day is survivable once. The questions worth asking are weekly questions, and the half day is why most of them go unasked.
The usual next step is to rent an analytics tool that bills by the event, and that price list has a cliff built in. The alternative is to own the database and pay for machines instead of events. Which one is cheaper depends almost entirely on volume.
The database got cheap before the dashboard did
Ten years ago, answering that question across several operational systems meant specialist infrastructure, licenses and at least one person employed to look after them. The analytical database is the part that changed.
The bar analytical databases now aim at is a result in under a second, and the design that gets them there is unglamorous:
- Columnar storage: ClickHouse stores a table as a collection of columns, with each column’s values written sequentially one after the other, so a query touching three columns reads only those three.
- Parallel processing: It then unfolds a query plan into multiple lanes, typically one per CPU core, so a machine with 32 cores does 32 things at once.
Those two ideas are why scanning a few years of order history is now the work of one modest machine rather than a platform, and they are the whole of the technical story a business owner needs.
Assembling the stack is mostly one decision
The parts are ordinary. Sales, website events, stock movements and campaign results land in a managed ClickHouse database, loaded by a connector such as Airbyte or read live from a Kafka topic through ClickHouse’s Kafka table engine. A dashboard tool sits on top and reads from it.
Metabase documents a direct ClickHouse connection, and its pricing page lists the open source edition as free with unlimited users. Looker Studio, Google’s free reporting tool, is the other common choice. Either one will draw the charts, and both are run by the person who asks the questions.
The decision is the part nobody puts on the architecture diagram: what counts as an order. A refunded order, a partially shipped order and a marketplace order that lands two days after the sale all have to mean the same thing in every report.
In practice, this means agreeing on three things before anybody builds a chart: one product key, one timestamp convention, and one refresh schedule. An afternoon on those three things is worth more than a week of reporting design. Skipping them is why so many dashboards end up quietly ignored, with three tiles that disagree about last month’s revenue and nobody willing to say which one is right.
What owning costs, read from the price list
A shop that wants the managed version of that database can rent ovhcloud clickhouse from $212.649 a month per node (excluding VAT). That entry price is the Discovery plan: a single B3-8 node with two vCores, 8 GB of RAM and 100 GiB of included storage, and no SLA. The Production plan, with three nodes and a 99.95% SLA, starts at $194.764 per node, or $584.292 a month for the cluster.
Patching, backups and scaling belong to the provider at that price.
The rest of the price list is worth reading alongside the headline. On the same Discovery plan, a 128 GB node (B3-128) costs $2,478.277 a month and the largest, a 256 GB B3-256, $4,546.002, and storage beyond the included 100 GiB is charged at $0.0003 per GB per hour, which over a 730-hour month works out at roughly 22 cents per GB.
A business that reads “up to 128 GB RAM” and “up to 40 TB storage” and attaches those figures to the entry price will budget for about a fiftieth of what that configuration costs.
The advertised number is the smallest node and the specification ceiling is the largest one, and the useful exercise before signing anything is to find the row in between that matches the data actually being loaded.
Priced by the hour, presented by the month
Multiply $0.2913 by 730 and the answer is $212.649 exactly. The monthly figures on the page are hourly rates shown by the month, which matters for the thing small businesses are usually trying to avoid.
The fear behind most analytics budgets is the invoice that arrives after somebody explores the data too enthusiastically: billing that moves with how many queries were run, how much each one scanned, and who happened to be curious that week.
Event-priced analytics tools make that fear concrete, because the meter is the event itself. Mixpanel’s pricing documentation gives an additional data rate of $.00028 per event on a 1M monthly events plan, and its MTU-based Enterprise plan starts at $20,000 per year. PostHog publishes its whole ladder: the first million events free, then $0.0000500 per event up to 2 million, falling in steps to $0.0000090 beyond 250 million.
The cliff is not the rate, which falls with volume. It is that the bill scales with the traffic the business is trying to grow, until the published price list ends and a sales conversation begins.
A node-priced managed database moves with something else. The bill is a function of two decisions, node size and storage, both published on a price list and both taken in advance, and an analyst asking one more question on a Thursday afternoon leaves it where it was.
Run both models at the same volumes and the crossover appears. The rented columns use the published rates above, before any discount. The owned column is a Production cluster of three B3-8 nodes, assuming about 50 bytes per event after compression, so a year at 100 million events a month (60 GB) fits in the included 100 GiB.
| Monthly events | PostHog (published tiers) | Mixpanel (list overage rate) | Managed ClickHouse (Production, 3 x B3-8) |
| 1M | $0 | $0 | $584.292 |
| 10M | about $324 | about $2,520 | $584.292 |
| 100M | about $2,618 | Enterprise plan, from $20,000 a year | $584.292 |
At a million events a month, owning is the expensive choice by a wide margin. Past 10 million, the rented bill grows with the business while the owned one stays flat until the nodes run out of CPU or disk. What the owned column leaves out is people: someone has to build the ingestion, model the tables and answer for the dashboards.
The honest limit here belongs to the category, and it applies to every provider in it: storage is the variable that grows on its own. Event data accumulates, a retention policy is nobody’s job in a ten-person company, and the only metered line on the bill is the one nobody is watching. A retention rule written in the first month costs an hour. Written in the second year, it costs a migration.
In ClickHouse, that rule is one clause of the table definition. Tables built on the MergeTree engine are usually partitioned by month, and a table-level TTL deletes rows, or moves them to cheaper storage, once they pass a set age, for example twelve months after the event date. Columnar compression keeps storage growing more slowly than the raw event count, but it does not stop it.
Thirty days with one developer
Marketfuel, a Florida eCommerce platform used by promotional marketing agencies to launch branded stores, reached proof of concept on its in-app reporting in under 30 days with a single developer. It uses Metabase to give its own customers insights into inventory levels, stock turnover rates and reorder thresholds, alongside order metrics covering processing times, on-time deliveries and shipment statuses.
Marketfuel is a software vendor embedding reporting for its clients, which is a different business from a shop analyzing its own sales. What transfers is the shape of it: the questions are inventory questions, and one person answered them in a month.
For a shop, the equivalent list is short and familiar:
- Repeat-purchase rate by cohort
- New against returning customer revenue
- Inventory on hand measured against sell-through
- Time between a customer’s first and second order
Those are four queries over the same two tables of orders and products. Each one is currently a week of spreadsheet work, and each one becomes a saved question that reruns itself every morning.
Some businesses should keep the spreadsheet
The threshold is not a row count. It is whether the questions change. What earns a database is a combination: several sales channels, enough transaction volume that a pattern is visible inside a week, and somebody who genuinely wants a different cut on Tuesday than they wanted on Monday.
A single storefront doing a few hundred orders a month, with one export and a monthly report that takes ten minutes to produce, is already being served well. Adding an analytics stack to it buys a maintenance job and a fresh opportunity for two numbers to disagree.
The cost barrier moved, so the question is worth asking again. For the shops on the far side of that threshold, the half day did not disappear either. It moved to the front, spent once on deciding what counts as an order, after which the Monday morning question answers itself.
FAQs
When should an online shop consider moving beyond spreadsheets?
An online shop may benefit from a database when data from multiple sales channels becomes difficult to combine and recurring questions require hours of manual spreadsheet work. Shops with relatively few orders and simple monthly reporting may not gain enough value from adding a dedicated analytics stack.
What makes ClickHouse suitable for eCommerce analytics?
ClickHouse uses columnar storage and parallel processing to analyze large datasets efficiently. These capabilities can allow businesses to query years of order and operational data without necessarily requiring a large or complex infrastructure setup.
Why do businesses need to define what counts as an order?
Different systems may treat refunds, partial shipments, delayed marketplace transactions, and other situations differently, which can cause reports to produce conflicting results. Establishing consistent definitions, product keys, timestamps, and refresh schedules helps ensure that dashboards are working from the same underlying rules.
Is a managed database cheaper than an event-based analytics platform?
The answer depends heavily on data volume, pricing plans, infrastructure requirements, and the people needed to operate the system. Event-based pricing can increase as a business generates more activity, while a node-priced database can offer more predictable infrastructure costs until additional capacity is required.
What should a business consider besides database pricing?
Database ownership or management also involves data ingestion, modeling, dashboard maintenance, storage retention, and technical expertise. A business should consider those people and operational costs alongside infrastructure prices rather than comparing database rates alone.