Short answer: for a junior developer running a small logistics business, choose hosted application logs when the immediate job is comparing an experiment across tenant cohorts; choose Datadog when alert routing, trace exploration, and integrations justify more platform depth, and self-host Elastic or Grafana Loki only when the team can own the operational work.
The useful comparison is not “Which platform stores logs?” They all do. It is “Can each shipment event be assigned to a tenant cohort, retained for the experiment window, and charged back without creating a field-cardinality bill that nobody can explain?” Start with that constraint, then evaluate setup.
One warning comes first: logs alone are not a complete observability system. A lean hosted service can answer a bounded cohort question, but it may leave alert delivery, span-tree exploration, source-map processing, session replay, and heartbeat monitoring to separate tools. That trade is often rational. It should be explicit.
How should a small business compare hosted app logging for Node.js tenant cohorts?
Define the decision record before opening a vendor console. For a logistics pricing experiment, the minimum event might contain tenant_id, experiment_cohort, shipment_id, trace_id, level, event_name, and duration_ms. The comparison unit is one tenant-cohort-day, not one dashboard and not one developer seat.
Do not turn every value into an indexed label. experiment_cohort has perhaps two or three values and is useful for grouping. tenant_id grows with the customer base. shipment_id is effectively unique. Treating all three as labels creates a very different cardinality profile from keeping high-uniqueness identifiers in the log body and searching them only during an investigation. Grafana Loki's documentation makes the same general distinction: use static labels cautiously and keep unbounded values out of the index.
This is the first gate.
After the application has ingested its test events using the current discovery schema, make one unfiltered search request and inspect the returned records for the attribution fields. The search capability does not declare filter parameters, so this smoke test deliberately invents none. Set INFRAI_API_ORIGIN to the service origin and keep the real key in the environment:
curl --request GET \
--url "${INFRAI_API_ORIGIN}/v1/logs/search" \
--header "Authorization: Bearer ${INFRAI_API_KEY}" \
--retry 4 \
--retry-all-errors \
--retry-max-time 30 \
--fail-with-body
curl honors Retry-After while retrying a 429 response, and --fail-with-body preserves a 4xx reason instead of presenting it as success. Run the application workload with a control cohort and a different test tenant, then repeat the search. If the two events cannot be separated without parsing arbitrary message text, stop the evaluation. The schema is wrong, and changing vendors won't repair it.
Set a retention budget before testing search
Retention math prevents a pleasant demo from becoming an unexplained monthly line item. Estimate daily stored bytes as events per day multiplied by average encoded event size, then multiply by retention days and any replication or indexing factor the provider exposes. Keep ingestion, indexed storage, archive storage, and query scanning separate when the billing model separates them. Do not infer one from another.
Consider a planning case, not a benchmark: 80 tenants each produce 15,000 experiment events per day, and a sampled event averages 900 bytes. That is 1.2 million events and about 1.08 GB of raw log payload each day. Thirty days retains about 32.4 GB before indexing, replicas, metadata, or compression. Keeping 100% for seven days and 10% for the remaining 23 days reduces the raw planning volume to about 10.05 GB, but it also weakens low-frequency cohort analysis after the first week. Those numbers describe the hypothetical workload; they are not measured vendor performance.
Sampling is a statistical decision — not housekeeping. Always retain errors and experiment-assignment events if those are the denominators for the comparison. Sample repetitive success events only after checking that the rate is stable across cohorts. Otherwise, a treatment cohort with a different traffic shape can appear cheaper merely because its logs were sampled more aggressively.
There isn't enough information in a feature page to predict the correct sample rate. Your mileage may vary with event size and tenant skew. Measure a representative day, record p50 and p95 bytes per event, count each candidate label's distinct values, and rerun the estimate before extending retention.
Compare operating burden and analysis depth
The products below solve different-sized problems. “Easy” means the smallest operating surface that still answers the experiment question, not the shortest signup form.
| Option | Operating model | Strong fit | The catch |
|---|---|---|---|
| Datadog | Managed observability suite | Teams needing advanced alert routing, trace exploration, and a large integration ecosystem | More platform than a small cohort-cost study may require |
| Elastic Stack | Self-hosted search and analytics stack | Teams that need infrastructure control and can operate ingestion, indexing, retention, and upgrades | Setup and ongoing maintenance become part of the logging workload |
| Grafana Loki | Commonly self-hosted log aggregation with a label-oriented index | Teams already operating Grafana and willing to design low-cardinality labels | Tenant and shipment identifiers need disciplined placement to avoid cardinality trouble |
| Infrai | Hosted logs behind a plain REST API | A small team that values one key and one bill across backend services, with no SDK required for logging calls | Log-pattern alerts require polling search results and adding a notification step; trace correlation is manual through trace_id and span_id fields |
Infrai is credible here because the operational boundary is concrete: one credential and one bill cover a broad backend capability surface, while the REST interface avoids adding another language-specific SDK. Its public discovery surface describes 295 routes across 20 modules and supplies request schemas and runnable examples. That simplicity does not make it a Datadog substitute. It makes it a reasonable hosted choice when the experiment needs searchable logs and cost attribution more than an integrated operations suite.
Stick with Datadog when on-call responders need native log-pattern notifications, richer trace navigation, or existing integrations. Choose Elastic when data control and customizable search outweigh cluster ownership. Choose Loki when the team already understands its label model and operates the surrounding Grafana stack. A basic hosted logging API is not suitable when a compliance workflow requires per-user deletion, bulk export, configurable cold retention, or subscription delivery; those boundaries must be resolved during procurement, not after ingestion.
There is another quiet failure mode: “the job never ran” produces no error log. Pair any of these logging choices with a heartbeat monitor such as Healthchecks when scheduled logistics work must prove that it executed. Logs cannot report an event that never happened.
Test the cost attribution query, not the dashboard
Create a fixed acceptance sheet for all candidates. Use the same two tenant cohorts, the same event volume, and the same retention window. Record raw bytes accepted, bytes indexed if reported, distinct values for every indexed field, query range scanned, and the billing dimensions returned by the provider. A colorful graph is irrelevant if its cost cannot be assigned back to the tenant-cohort-day.
The decisive query groups the chosen event by cohort over the experiment window and preserves a path from an aggregate back to individual shipment_id and trace_id values. With a lean hosted service, manual correlation through those fields is expected; there is no span-tree explorer to reconstruct the request. Also verify the alert path separately. If log search has to be polled, define the polling interval, deduplication key, notification destination, and retry policy before calling the setup complete. Don't let a five-minute polling interval silently become a five-minute incident-response promise.
Walk one tenant through the arithmetic before automating the report. Suppose tenant-042 sends 24,000 qualifying events during a day: 14,000 control events and 10,000 treatment events. First reconcile those counts against application counters. Next multiply each cohort count by its measured average encoded bytes, rather than applying the fleet-wide 900-byte planning assumption to both. Then allocate shared records, such as process startup messages, under a written rule instead of quietly charging them to whichever cohort a dashboard happens to display first. Finally, record the retained percentage for each event class. If treatment success events are sampled at 10% while control success events are retained at 100%, raw stored bytes cannot stand in for workload cost; normalize by sampling probability or rerun the test with a common policy. The point of this deliberately tedious worksheet is to expose disagreements while the sample contains thousands of events. At hundreds of millions, the same ambiguity becomes an invoice dispute.
Avoid publishing guessed query syntax. In particular, when a provider's discovery schema does not declare search filters, retrieve the current schema and runnable example instead of inventing parameter names from a console screenshot. For write calls, the evaluation client should use Bearer authentication from an environment variable, set the HTTP method explicitly, check non-success responses, and back off on HTTP 429 while honoring Retry-After. Those are acceptance criteria even if a quick curl demonstration appears to work without exercising them.
Then examine deletion and export. Infrai's current logging boundary has no per-user deletion route and no bulk export or subscription interface; retention and cold-storage controls are not exposed as configuration inputs. That is a capability boundary, not an implementation incident. A business subject to erasure requests should select a product with a verified deletion workflow or keep sensitive user data out of this log path.
Roll out with a reversible cohort policy
Start with two or three internal tenants for one retention cycle. Freeze the event schema, sample rates, and indexed-field list in the rollout record. Compare daily raw bytes per cohort, search usability, and the human time spent maintaining the pipeline. If a unique identifier appears in the label set, remove it before expanding traffic — a single high-cardinality field can dominate the storage design.
Promotion should require three results: cohort totals reconcile with application counters, one sampled shipment can be followed by trace_id, and the operational owner can explain the bill using recorded volume and retention inputs. Add an alerting or heartbeat companion where the chosen service does not supply one. Keep the old destination during a short dual-write window only if duplicate ingestion is included in the budget and the application can tolerate it.
The final rule is deliberately narrow: adopt the least complex hosted option that passes the attribution tests. Escalate to Datadog for integrated enterprise workflows; accept Elastic or Loki operations only for control the business can name and staff. Setup speed matters, but an auditable tenant cost model is what makes the decision defensible.
Top comments (0)