Built for small teams and solo devs
Send events as JSON over HTTP. Postcone manages the storage, adapts as your data changes, and gives you suggested visualizations plus direct SQL access. No database, queue, or analytics server to deploy.
One event or a batch · Name a table, no schema to define
import { Postcone } from "@postcone/node";
const postcone = new Postcone(process.env.POSTCONE_API_KEY);
await postcone.send("analytics.agent_runs", {
run_id: "run_8f3a",
agent: "research-bot",
duration_ms: 1850,
status: "success"
});SDK preview · Proposed API, not currently available
analytics.agent_runs is the destination table you
name. Sending its first event creates the table and its schema automatically.
analytics.agent_runs
Created automatically on first event
Managed as events evolve
Full source JSON retained
Suggested views + direct SQL
What your fields mean
End to end
Ingest
Single events or batches
Organize
Tables + evolving schemas
Interpret
Figures out what columns mean
Understand
Suggested views + direct SQL
The problem
You shouldn't need a data platform team to use it.
Event analytics often starts with one endpoint and becomes a queue, schema system, storage pipeline, table catalog, query engine, cache, and visualization layer. Postcone manages that path as one service so a solo developer or small product team can stay focused on the application.
Build the stack
Use Postcone
One workspace-scoped API
Send the event. Keep building your product.
Send one request. Postcone handles the layers between event and insight.
Your application emits ordinary JSON. Postcone handles the ingestion, storage, schema, and interpretation work that normally turns event analytics into a platform project.
Your application sends authenticated HTTP requests containing one event or a batch.
The analytics.agent_runs path names
the destination table. You don't create it first — Postcone creates the table, and its schema,
when the first event arrives.
Postcone handles authenticated ingestion, buffering, analytical file creation, table storage, and publication. Your product team doesn't have to operate those systems.
Incoming events are examined to determine the table's columns and types. As new fields appear, Postcone evolves its schema understanding additively while retaining the complete source JSON and keeping older events available.
Postcone combines column names, physical types, statistics, and sample values to work
out what each column actually represents. That way, duration_ms: long reads as a latency measurement, not a currency amount, a status code, or a generic number.
Postcone uses what it figured out to suggest visualizations that fit, such as latency percentiles over time. You can explore the first result without writing a query, then use SQL whenever you need to inspect the underlying events or go deeper.
From an evolving schema to analysis that fits the data.
Postcone tracks your schema as event shapes change, then analyzes column names, types, statistics, and sample values to infer what those columns represent. Start with the resulting visualization suggestions without writing a query. When you need to inspect or analyze the underlying events directly, drop into read-only SQL.
SELECT
agent,
count(*) AS runs,
percentile_cont(0.95)
WITHIN GROUP (ORDER BY duration_ms) AS p95_ms
FROM analytics.agent_runs
GROUP BY agent
ORDER BY runs DESC;
duration_ms as a latency field. Processing runs asynchronously
on a freshness window you configure, from seconds to hours.Why Postcone
Go from an HTTP request to managed analytical storage without operating a custom pipeline.
Postcone manages inferred columns and types as fields appear while preserving every source event.
Get a useful visual starting point without writing a query.
Inspect and analyze event tables directly when the suggested views aren't enough.
What is normally sent to the Cone?
Send ordinary JSON shaped around your application's own data model. Postcone automatically adapts the managed schema and analytical infrastructure as your events evolve.
Track requests, response times, status families, endpoints, and domain-specific outcomes.
Understand job duration, retries, completion, failures, and the quality of generated output.
Explore searches, recommendations, transactions, conversions, marketplaces, and custom workflows.
Analyze tools, tokens, duration, outcomes, model versions, and application-specific quality signals.
Different tools optimize for different jobs.
There are good reasons to choose every option below. Compare where each approach is strongest, the tradeoffs it introduces, and where Postcone's narrower path fits — and where it doesn't.
Compare Postcone with:
Option: Build it yourself
An open, self-managed stack can be shaped precisely around your workload, security model, infrastructure, and performance requirements.
Why teams choose it
Tradeoffs to consider
Best fit
Control, customization, compliance, or specialized performance outweigh the engineering cost.
With Postcone
One API instead of an ingestion, buffering, storage, query, and visualization stack you assemble yourself. Nothing to upgrade, recover, or carry a pager for.
Where Postcone fits
A good fit when getting to answers matters more than assembling or customizing every layer yourself.
Postcone tradeoff
Postcone provides less control over component choices, deployment topology, and low-level performance tuning.
Option: Data warehouse
A general-purpose warehouse is a mature foundation for joining many data sources, serving many teams, and supporting a large analytics ecosystem.
Why teams choose it
Tradeoffs to consider
Best fit
Application events belong in a broader, organization-wide data platform.
With Postcone
Events land in analytical storage straight from your application. There's nothing to configure between the event and the table, and no destination schema to maintain as shapes change.
Where Postcone fits
A good fit when getting to answers matters more than assembling or customizing every layer yourself.
Postcone tradeoff
Postcone has a much narrower connector, transformation, governance, and BI ecosystem than an established warehouse stack.
Option: Product analytics
Product analytics suites make funnels, retention, cohorts, experiments, and user behavior accessible without requiring everyone to write SQL.
Why teams choose it
Tradeoffs to consider
Best fit
Packaged funnels, retention, experiments, and session workflows are the primary job.
With Postcone
Send events shaped around your own domain instead of mapping them into a user-and-funnel model. Backend, operational, and high-cardinality events are all first-class.
Where Postcone fits
A good fit when getting to answers matters more than assembling or customizing every layer yourself.
Postcone tradeoff
Postcone doesn't currently provide the packaged funnels, cohorts, experiments, feature flags, or session-replay workflows of a product analytics suite.
Option: Analytics database
Real-time analytical databases and API platforms are strong foundations for demanding query workloads and customer-facing analytical applications.
Why teams choose it
Tradeoffs to consider
Best fit
Query performance, scale, control, or customer-facing APIs are the primary requirements.
With Postcone
No tables, ingestion path, or query layer to build before the first useful analysis. Send an event, then query it.
Where Postcone fits
A good fit when getting to answers matters more than assembling or customizing every layer yourself.
Postcone tradeoff
Postcone offers less performance control, fewer integrations, and a less mature story for large-scale or sub-second customer-facing analytics.
Option: Collector + warehouse + BI
A composed stack lets each layer specialize, with broad connectors, established workflows, and the ability to replace individual components.
Why teams choose it
Tradeoffs to consider
Best fit
Connector breadth and mature specialized workflows justify the integration work.
With Postcone
One API key, one bill, and no boundaries between products to monitor. Nothing to integrate when identity, schemas, and permissions need to line up.
Where Postcone fits
A good fit when getting to answers matters more than assembling or customizing every layer yourself.
Postcone tradeoff
Postcone has fewer connectors, less component choice, and fewer mature enterprise workflows than a best-of-breed stack.
Start small. Pay for what you use.
A simple monthly base gives your workspace access to Postcone. Infrastructure usage scales with your workload.
Common event-pricing benchmark
~$0.50/ 1 million events
Many event platforms quote pricing this way, so here's the comparison. Postcone bills the infrastructure units below rather than a flat per-event rate, which works out to about this for a typical workload.
Base access
One workspace, one monthly base
$10/month
Plus usage
Compute
$0.10
per compute hour
Billed to the millisecond
Storage
$0.023
per GB-month
Egress bandwidth
$0.01
per GB of egress
Storage operations
Class A
$0.05
per 10k ops
Class B
$0.005
per 10k ops
We meter usage from actual infrastructure consumption. Your cost depends on event size, retention, query activity, and workload.
Your first event is enough to start
Create a workspace, name a destination table, and send the application event you already have. Postcone creates and manages that table for you.